[mythtv-users] HD live tv stuttering

[Tim Coote]

>
> Date: Thu, 27 May 2010 13:39:31 -0400
> From: "Michael T. Dean" <mtdean at thirdcontact.com>
> Subject: Re: [mythtv-users] HD live tv stuttering
>
> On 05/27/2010 05:33 AM, Tim Coote wrote:
>> The myth specific point: I was having some stutter on bbc hd with the
>> vdpau drivers. Lots of prebuffering pauses on the output, even when I
>> stripped the playback profile to a minimum. However, it turned out
>> that the stutter / prebuffering may be down to running mythfrontend  
>> on
>> the command line and letting it spit its output onto the terminal:
>> merely redirecting the output to capture it stopped the prebuffering.
>>
>> Is this behaviour (mythtv behaviour differing depending on where
>> stdout points) as expected?
>
> You were likely seeing I/O wait and resource issues when using the
> terminal output, and likely coupled with a large number of stream
> errors.  You should not be running at high verbosity levels (using  
> only
> the default for normal operation--which means -v important,general).
>
> As far as the slow response...  Well, I am certain that response will
> vary with system resources.  A different computer with more
> memory/faster CPU will likely respond much more quickly.
>
> Mike
>
>
I don't think that there were many stream errors - I was using the  
same stream interchangably for tests. CPU and memory seem to have  
sufficient headroom (no significant paging and cpu levels around 15%),  
and no -v(erbosity), it seemed like the initial info spat out was  
syncrhronous for some reason and so caused an overrun, which then  
caused a synchronously reported error, which caused more overrun, etc.  
But surely the output isn't synchronous to the terminal and async to  
disk ?
[snip]
> From: Ed W <lists at wildgooses.com>
> Subject: Re: [mythtv-users] HD live tv stuttering
> To: mythtv-users at mythtv.org
> Message-ID: <4BFEF18F.7080804 at wildgooses.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 27/05/2010 18:39, Michael T. Dean wrote:
>>
>> As far as the slow response...  Well, I am certain that response will
>> vary with system resources.  A different computer with more
>> memory/faster CPU will likely respond much more quickly.
>
> If by "response" you mean scrolling through the menus on the system  
> then
> this also does a ton of DB work and it's possible that you could look
> there for the bottleneck also?
>
> Scroll around with the menus while watching top and see if you get  
> more
> clues
>
> Good luck
>
> Ed W
>
That seems a likely source of some slowness. I had hoped that it was  
possible to get mythfrontend to report what was slowing it down. The  
db data is tiny, and largely read only, is there any simple way to  
wind up the sql client cache?

Since my initial post, I got a yum update to 0.23, which seemed to  
solve the problem. But it's now come back, which I find particularly  
annoying as I cannot see what's changed between working/not working.