Opened 16 years ago
Closed 15 years ago
#4350 closed defect (fixed)
Mythweb makes Backend go 100% CPU
Reported by: | anonymous | Owned by: | Janne Grunau |
---|---|---|---|
Priority: | major | Milestone: | 0.22 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
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.
Attachments (1)
Change History (26)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
Component: | mythweb → mythtv |
---|---|
Owner: | changed from xris to danielk |
Status: | new → assigned |
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.
comment:3 follow-up: 4 Changed 16 years ago by
Milestone: | unknown → 0.21 |
---|---|
Owner: | changed from danielk to Janne Grunau |
Status: | assigned → accepted |
Version: | unknown → head |
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.
comment:4 Changed 16 years ago by
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.?
comment:5 Changed 16 years ago by
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)
comment:6 Changed 16 years ago by
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 ;-)
comment:7 Changed 16 years ago by
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 :)
comment:8 follow-up: 9 Changed 16 years ago by
Just wondering how the patch is coming along for this one?
comment:9 Changed 16 years ago by
In SVN 15515 the backend still gets funky after generating a preview from mythweb.
comment:10 Changed 16 years ago by
Priority: | minor → blocker |
---|
comment:11 Changed 16 years ago by
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.
comment:12 Changed 16 years ago by
The BufferedSocketDevice::WaitForMore?() fix breaks autodiscovery. The backend is still found but shows up as <Unknown> and you cannot connect.
Changed 16 years ago by
Attachment: | mythxml_poss_fix.diff added |
---|
comment:15 Changed 16 years ago by
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.
comment:16 Changed 16 years ago by
I can't confirm that this bug is fixed. Delete all png previews and then go to mythweb. Makes mythbackend go to 100%
comment:17 Changed 16 years ago by
Ticket locked: | set |
---|
It isn't fixed, no fix has been committed .....
comment:18 Changed 16 years ago by
Ticket locked: | unset |
---|
comment:19 Changed 16 years ago by
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.
comment:20 Changed 16 years ago by
Delete all the cached images in mythweb (data/something) then try again.
comment:21 Changed 16 years ago by
Priority: | blocker → major |
---|
This appears fixed, based on a number of reports (including mine). Reducing priority.
comment:22 Changed 16 years ago by
Priority: | major → minor |
---|
comment:23 Changed 16 years ago by
Priority: | minor → major |
---|
This has resurfaced again sometime before r16394...
comment:24 Changed 16 years ago by
Milestone: | 0.21 → 0.22 |
---|
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...
comment:25 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Possibly fixed by multiple changes in Mythbackend communication. No recent reports of this issue.
I can confirm this, too. It consumes 3 cpus on a quad-cpu system (300%).