[mythtv-users] HD live tv stuttering

[Tim Coote]

Hullo
As much as anything, this is an observation, and a plea for some  
pointers on how to unpick some of the complexities of mythtv.

I've just built a system with the frontend on an acer revo 3610, using  
its hdmi interface. Using VDPAU, this has a low cpu usage (~20% on one  
cpu, compared to >120% and stuttering when using software decoding),  
but it can be quite slow to respond. I find it near impossible to  
isolate any cause of slow response - that's a simple example of the  
type complexity that I'd like to unpick: where can I find a high level  
description of the moving parts, how they interact and the resources  
that they use/constraints on performance?

fwiw, I based my build on fedora 12 and spent some time faffing with  
pulseaudio, before throwing it out completely. There were a couple of  
issues here to do with effectively testing the hdmi (as far as I can  
see, the standard is not implemented consistently, and I naively  
assumed that surely my newish tv was working), and then actually  
driving the alsa's tools talking to pulseaudio, which then drives the  
alsa drivers. Even when I ripped out PA, I still had what I consider  
odd behaviour from alsa: speaker-test not only requires root  
privileges, but wouldn't work until I'd run up a gnome destkop (??)

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?

Is there a reference guide for the output from the various components  
to understand what's an issue or not? Mythtv seems to do a lot of  
trying to recover from known environmental problems. Although this can  
get simple configurations up and running faster, it does contravene  
the engineering principle found in high availability systems of 'fail  
fast', and means that underlying problems are masked, making debugging  
more complex set ups much harder to get right.

Tim