[mythtv-users] small mythtv freezes ?

[Bruce Markey]

Jelle Kalf wrote:
> Hi,

Hello,

> Once every few seconds (especially when I run mythfrontend in the background) I
> get small freezes every few seconds:
> 
> 2003-11-24 18:13:00 prebuffering pause
> 2003-11-24 18:13:05 prebuffering pause
> 2003-11-24 18:13:22 prebuffering pause
> 2003-11-24 18:13:23 prebuffering pause
> 2003-11-24 18:13:27 prebuffering pause
> 2003-11-24 18:13:29 prebuffering pause
> 
> dmesg output:
> saa7115[0]: decoder disable output
> saa7115[0]: decoder enable output
> saa7115[0]: decoder set picture bright=127 contrast=63 saturation=63 hue=0
> saa7115[0]: decoder set picture bright=127 contrast=63 saturation=63 hue=0
> saa7115[0]: decoder set picture bright=127 contrast=63 saturation=63 hue=0
> saa7115[0]: decoder set picture bright=127 contrast=63 saturation=63 hue=0
> 
> I'm running on a Athlon XP2100+ with 1gb memory and hd's running in UDMA66.
> 
> 
> Note: when I run Mythfrontend in the front and not zapping etc, I don't have the
> problem. I do have the problem when zapping channels.. it flikkers once or
> twice.

There was a bug in 0.11 and earlier that would cause these
after a channel change until you paused or rewound for ~30scec.
If you are using 0.12 or later this doesn't happen but there
often can be one or two pauses after a channel change (I'll
tell you exactly why this happens then there will be a series
of replies saying I'm full of 'it because it doesn't match
what they imagine or assume ;-).

After a channel change, data needs to work its way from grab,
encode, file, socket, network, buffer, decode, playback. Each
step needs some amount of data to do its job before it can move
blocks of data to the next step. The final step is when the
there are a few decoded frames ready the player can play. But
there is a trade off here. If the player tries to play as soon
as there are just one or two frames ready but then no more
arrive in time, it has to stop and wait for more (prebuffering
pause). There would be lots of stuttering after every channel
change. If instead it waits until there are plenty of frames
buffered so it can be sure that it won't need to stop, then
there would be a few tenths of a second longer delay before
playback starts after the channel change. 

Therefore, the one or two pauses you see are the result of a
compromise. By starting a little prematurely, there will be a
few of theses pauses but every channel change is one or two
tenths of a second faster.

Now, I'm not sure about the differences between foreground and
background. However, if your system "nice"s background processes,
the frontend process may be less likely to get the CPU in time
when it really needs it. Other than that I don't know why it
would make a difference.

--  bjm