[mythtv] High CPU usage during playback.

[Tako Schotanus]

For me turning of the Preview helped as well to bring down CPU to normal 
levels again.
And I also had the problem with bad recording messing things up.
My speculation though is that they are not related problems though.
Both problems occurred several times on completely separate occasions here.

Cheers,
 -Tako

Carl wrote:

>Sorry to post speculation without doing further testing, but at one point I 
>noticed quite a bit of sql activity from the front end. All my high cpu 
>problems went away when I disabled previews, do I didn't pursue it, but at 
>the same time I had a couple of bad recordings (in the recorded table but 
>no .nuv file, or an empty one). Things definitely seemed to go haywire if I 
>nav'd over the entry in question in the Watch Recorded screen.
>
>PVR-350, Epia 800 (C3). Gentoo.
>
>Hope this helps. If I have time later, I can turn previews back on and try to 
>reproduce this...
>
>
>On Wednesday March 10 2004 17:55, Neil Whelchel wrote:
>  
>
>>Hello again,
>>I tried it with the preview on and off and in both cases it didn't make
>>any difference at all. In both cases there was 100% CPU usage and many
>>interruptions in playback. I already had a look at the other messages
>>about CPU usage and none of them really applied to what I am dealing with
>>here. In my case I am NOT having a problem while watching live TV, it is
>>only a problem while watching something that is pre-recorded. As far as I
>>can tell, the problem is that the mythfrontend main thread is using a huge
>>amount of CPU with calls to processEvents().
>>
>>Clarification:
>>The mythfrontend player thread in both cases uses the same amount of CPU
>>and I think it is within reason as to about what it should be.
>>This has nothing whatsoever to do with mythbackend as it is on a different
>>machine.
>>
>>In myhtfrontend/main.cpp startTV() the code fragment looks something
>>like...
>>        {
>>            qApp->unlock();
>>            qApp->processEvents();
>>            usleep(100000);
>>            qApp->lock();
>>        }
>>
>>And in mythfrontend/playbackbox.cpp PlaybackBox::play() it looks like...
>>        {
>>            qApp->unlock();
>>            qApp->processEvents();
>>            usleep(50);
>>            qApp->lock();
>>        }
>>
>>Changing the latter from 50 to 100000 fixes the problem for me.
>>(The CPU usage is about what it should be both during playback of
>>recordings and live TV.)
>>It doesn't appear to have any side effects that I am able to find, that is
>>why I posted my original question here:
>>Is there a reason that in one case (live TV) the usleep is for 100000 and
>>in the other (playback of a recording) it is for 50?
>>
>>
>>-Neil Whelchel-
>>First Light Internet Services
>>760 366-0145
>>- We don't do Window$, that's what the janitor is for -
>>
>>On Wed, 10 Mar 2004 steve at nexusuk.org wrote:
>>    
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>On Wed, 10 Mar 2004, Neil Whelchel wrote:
>>>      
>>>
>>>>I have been having some issues with my 1Ghz VIA CPU keeping up while
>>>>playing back pre-recorded videos (100% CPU usage with video pausing a
>>>>few tenths of a second every second or two), however it does fine (40%)
>>>>playing live TV.
>>>>        
>>>>
>>>See the previous thread discussed over the past week about high CPU usage
>>>in the CVS version - it seems that (for some people?) the CVS version is
>>>leaving the preview video playing in the background while watching a
>>>recording.  Try turning off the preview video in the config and see if it
>>>fixes your problem.
>>>
>>>- --
>>>
>>> - Steve                                            
>>>http://www.nexusuk.org/
>>>
>>>     Servatis a periculum, servatis a maleficum - Whisper, Evanescence
>>>
>>>-----BEGIN PGP SIGNATURE-----
>>>Version: GnuPG v1.2.3 (GNU/Linux)
>>>Comment: Public key available at http://www.nexusuk.org/pubkey.txt
>>>
>>>iD8DBQFATv/F5zUOsIV3bqERAjYPAJ0RkNnlcdA7xr/g5GCuRLVSnC90vgCglZB4
>>>1O3lRM8OIhuPuQs2UvatMZ8=
>>>=LRtz
>>>-----END PGP SIGNATURE-----
>>>      
>>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20040311/18e3a6fd/attachment-0001.html