Mythweb makes Backend go 100% CPU

[anonymous]

I have about 150 recordings, if i go in to "Recorded Programs" in Mythweb and chose Show all the Backend get stuck at 100% CPU and no results are shown. This is with latest SVN. If list something with 20 entries it's ok.

[rainecc@…]

I can confirm this, too. It consumes 3 cpus on a quad-cpu system (300%).

[xris]

This is a problem in the genpixmap code. I thought that Daniel had fixed it, but apparently not because I'm still seeing it in [15199] trunk, too.

[janne]

I have a preliminary path for this. The problem is the execution of a new mythbackend process. Forking just the preview generating thread is has the same advantage of generating previews in a different process and is much faster.

It needs some work but I think I can commit it tomorrow.

[elkin@…]

Replying to janne:

I have a preliminary path for this. The problem is the execution of a new mythbackend process. Forking just the preview generating thread is has the same advantage of generating previews in a different process and is much faster.

It needs some work but I think I can commit it tomorrow.

Hi, I have svn 15240 installed and it shows exactly the same behaviour. Does someone know if it is hard to code a feature to "paginate" the shows list. I mean that only the first 10 shows get printed, then you go to the next 10 etc.?

[xris]

Once the backend hits 100% cpu usage, it won't drop again until the backend is killed/restarted, so paginating mythweb won't help. (and just in case more people ask, I do not intend to do pagination within mythweb -- there are better ways to deal with the reasons people want it, and I *will* do something about that eventually)

[elkin@…]

without knowing how the backend actually ends up locking itself at 100%, factual is that if I only have less than about 20 recordings the backend never gets crazy. Paginating might be a solution to this problem, but as you wrote there might be nicer solutions to it. Right now I have over 100 recordings and not having a nice way of telling mythweb how many to show makes the whole experience less rounded. I am looking forward to xris solution ;-)

[quigleymd@…]

If you need to use mythweb's recorded programs page, just comment out the line of code that calls the preview generation function. I'm using svn 15239, and the relevant code is in mythweb/modules/tv/includes/objects/Program.php on line 487.

Just change
$this->generate_preview_pixmap($width, $height, $secs_in);
to be
$this->generate_preview_pixmap($width, $height, $secs_in);

This should get you by til the patch is committed :)

[anonymous]

Just wondering how the patch is coming along for this one?

[elkin@…]

In SVN 15515 the backend still gets funky after generating a preview from mythweb.

[stuartm]

Uncommenting the fix in BufferedSocketDevice::WaitForMore?() fixes the 100% CPU problem and the spinning threads. I'm not convinced it is a proper fix, neither was dblain from the comments in the code but it works.

[stuartm]

The BufferedSocketDevice::WaitForMore?() fix breaks autodiscovery. The backend is still found but shows up as <Unknown> and you cannot connect.

[elkin@…]

as of 16114.svn trunk still having the same behaviour

[stuartm]

elkin, no fix has been committed yet, please wait.

[pansyg@…]

i don't know what changed, but on my last build from trunk (16116) the issue is gone for me. preview generator is working again and there is no 100% cpu usage.

[elkin@…]

I can't confirm that this bug is fixed. Delete all png previews and then go to mythweb. Makes mythbackend go to 100%

[stuartm]

It isn't fixed, no fix has been committed .....

[stanley]

I also don't know what happened, but sometime last week the problem disappeared. This was approx. around SVN 16120...

The only thing I did different than any other upgrade: this time I did a make clean before doing a make. No particular reason for doing this, just that I hadn't done a make clean for quite a while.

I've been using it for a few days now (and updated to 16268 yesterday) and no more CPU-eating by mythbackend after looking at recorded programs from mythweb.

[anonymous]

Delete all the cached images in mythweb (data/something) then try again.

[ijr]

This appears fixed, based on a number of reports (including mine). Reducing priority.

[xris]

This has resurfaced again sometime before r16394...

[danielk]

seems to be a lot less prevalent if this still exists from a quick poll in IRC, no one there who used to see it still sees it now...

[Dibblah]

Possibly fixed by multiple changes in Mythbackend communication. No recent reports of this issue.