Tvheadend

Hi , i experience a high CPU load , but also when just watching encrypted channels (no recording)
Might this be the same issue?
Seems to occur on newer versions of tvheadend.

Could very well be.

Did you compare with opdenkamps repo?
Because thats where the topic started.

Have a look at the discussions over here:

https://github.com/tvheadend/tvheadend/commit/43008575869cef8c49a4b9b967d7d10e66005174

and here:

https://github.com/tvheadend/tvheadend/commit/7cd0a15527855e81c150e6eb564d35408e9a7580

Mind you, it has nothing to do with these commits, that's why addamsutton sugested to take the discussion to here.

Only that did obviously not happan.

Maybe it will result in a fix for the problem, I'm not sure, it's awfully silent right now.

Sorry, my mistake.
Judging from your message, you already took a look at these commits.

Hi Bas,

Thanks for your reply.
Indeed I looked at some of those discussions, but i was a bit confused since those specific commits indeed did not seem to cause the problem.

Does your problem only occur when recording? I seem I have the high loads also when watching (and only on new versions, not on 3.0 release).
(that is why i started a separate discussion on the forum)

I would also like to help debug/check if I could, but right now i didnt know what to check except just compare 'stable 3.0' with the newest version, using TOP while watching an encrypted channel.

Did you compare with opdenkamps repo?

I didn't, but is seems opdenkamps repo is three months old, and if that one shows a low cpuload it is simmilar to the 3.0 release on the tvheadend repo which also shows the lower cpu load (i would guess).

Alex.

bas t wrote:

Could very well be.

Did you compare with opdenkamps repo?
Because thats where the topic started.

Have a look at the discussions over here:

https://github.com/tvheadend/tvheadend/commit/43008575869cef8c49a4b9b967d7d10e66005174

and here:

https://github.com/tvheadend/tvheadend/commit/7cd0a15527855e81c150e6eb564d35408e9a7580

Mind you, it has nothing to do with these commits, that's why addamsutton sugested to take the discussion to here.

Only that did obviously not happan.

Maybe it will result in a fix for the problem, I'm not sure, it's awfully silent right now.

I did not have a look at cpu load during livetv, I just asumed it is a ffdecsa handling problem in the newer versions.

It should not make any difference, livetv or recording, since the problem only exists while decoding an encrypted channel.

If however in your setup it does make a difference, you should contact one of the devs to report your findings.

Come to think of it, do you know which commit marks release 3.0?
I would like to give this a test, just so I can compare with opdenkamp (which is more or less the state in which tvheadend was when amdoma transferred the git repo)

bas t wrote:

Come to think of it, do you know which commit marks release 3.0?
I would like to give this a test, just so I can compare with opdenkamp (which is more or less the state in which tvheadend was when amdoma transferred the git repo)

I compared by installing the 3.0 branch next to the newest one from git:

https://github.com/tvheadend/tvheadend/commits/release/3.0
Commit 5084ca63fd, comitted a month ago.

It is on github as a seperate stable branch.

And is your cpu load 4 times up? Like mine?

bas t wrote:

And is your cpu load 4 times up? Like mine?

A bit more even, like up to 5 to 6 times higher.

Checked using 'top'.
Gives 9 / 10 or 11 % cpu load with 3.0 and something between 55 % and higher (like 60%) with newest tvheadend. (but I didn't check for cpu freq increase; I use dynamic cpu-freq, and I didn't look into how TOP reports/calculates the CPU usage).

That's not good.
Are you on Debian Squeeze?
I was led to believe that it could have something to do with the glibc version shipped with Debian Squeeze.
But then again, it might not.

bas t wrote:

That's not good.
Are you on Debian Squeeze?
I was led to believe that it could have something to do with the glibc version shipped with Debian Squeeze.
But then again, it might not.

Using gentoo; I could try to install a different version of glibc, right now:

• sys-libs/glibc
  Latest version installed: 2.14.1-r3

Disregard my remarks on glibc, according to the discussion at the forementioned commits, this actually has something to do with these commits.
So it may not apply to this problem.
I'll ask the devs to drop in here, I don't think this is going anywhere without their input.

I'll ask the devs to drop in here, I don't think this is going anywhere without their input.

Indeed that would be good, thanks so far.

Alex.

Hey guys,

I am following the discussion, I'm just not sure that I have much useful input at this stage. I don't use any encrypted channels and this seems to be related primarily to encrypted channels?

Have any of you tried git bisect'ing this to try and see where the problem lies? Might be worth checking a revision from a few weeks back, just to see.

I'll keep my eye on things, but I'm not sure I can offer much at this stage.

Adam

Do you mean compiling each and every commit after release 3.0 so we could determine the couse of the problem?

Not quite, git bisect will help you do a binary search through all the commits between A and B.

But first of all I'd start with a point just after the new EPG code was added (since that's a massive amount of the post 3.0 commits). If that works ok, then start a git bisect from there. If that fails then shout at me all you like

But you could also do a bit of a random spot check over the past few weeks. Just to get a rough feel for where things might have started to go wrong.

Adam

Adam Sutton wrote:

Not quite, git bisect will help you do a binary search through all the commits between A and B.

But first of all I'd start with a point just after the new EPG code was added (since that's a massive amount of the post 3.0 commits). If that works ok, then start a git bisect from there. If that fails then shout at me all you like

But you could also do a bit of a random spot check over the past few weeks. Just to get a rough feel for where things might have started to go wrong.

Adam

Ok, thanks for the advice,
I'll try do some checks as you propose, starting with the moment the EPG code was added (but not tonight, ill try to do some tomorrow, and never used git bisect before).
I will keep you informed !

Alex.

I'm not familiar with git bisect, I'll have to google on that first.

Hi,

I tried to pinpoint the problem by compiling versions from some time back with some random iterations.
It seems to me that the high-load problem first occurs somewhere between Commit b350d44c4d (16 august), and b2b15cb60a (30 august).

So: Branching with b2b15cb60a gives a high load when playing, branching b350d44c4d does not.
To make sure it is the right version running: The about-tab shows "HTS Tvheadend 3.1.556.gb350d" in this last case.

I can try to do some more itterations, however, I am not sure I checked in the right way.
So I will probably have to check if I did the git/branch/commit stuf right.What I did :I branched various versions of git using "git checkout 741612ccf9", and then recompiled for some version and checked the version indicated in the "about" tab in tvheadend itself. However, this last check does not seem to be consistent all the time, which makes it confusing to be sure what is actually running.

Alex
.

PS:
So basically , for various commit numbers, I did the following, and than (re)configure, make and make install:

• 741612ccf9
  78cfe1b3ed
  9cf3b81fb9
  ec3bb46252
  master
  new_branch_name@

and then again, for b350d44c4d:

• b350d44c4d
  ec3bb46252
  fab1f902bb
  master
  new_branch_name
  @

commit 11f713dd85 (20 aug) is not good, so it has to be somewere between 20 aug and 16 aug

9a58b7ab76 (17 aug) is not good either

afbaf935d6 as well, almost there...

Looks like 16 aug is the last one working, but I'll surch some more.

bas t wrote:

9a58b7ab76 (17 aug) is not good either.

Ok, closing in ;-)

How is the information in the "about" tab ? Can you relate it back to the commit-number? ( or should I just ignore the number in "about? )

The one thing you have to be careful of, and git bisect will not help in this case, is there will be some known bad builds in there somewhere as a result of errors added during various commits and then corrected shortly afterwards.

So its always worth reviewing the logs either side of a commit to check whether there is mentioning shortly after of a fix for a previous problem.

Adam

I pull in a fresh one before I build

so
git checkout <some commit>
git reset --hard HEAD
make

And then manually copy the new binary to /usr/bin

so I am absolutely sure that I am running the correct version

No don't do that, it'll almost certainly fail at some point! It won't necessarily have access to all the right support files etc...

If you're trying to debug and test etc.. You're much safer simply running the binary in place.

Adam