[mythtv-users] channel changing speed, is 3 seconds normal?

[Bruce Markey]

Mark Edwards wrote:
> guessing that this relates to the ringbuffer in mythbackend. The channel is
> probably changed instantly, but the front-end doesn't see the new data until
> the ringbuffer gets around to supplying it...

Up to this point, this is a much better guess than most ;-).
The speculation about all the time being attributed to removing
the ringbuffer (or to the filesystem filesystem type) has been
repeated so much that it's taken on a life of it's own. As much
as it's been reiterated, it simply is not the key issue.

Where you're guess is on track is that the frontend can't start
playing until it has new data flowing that it can play.

Think of it like turning the spigot on a hose and waiting for
water to come out the nozzle. What's hosed here (I couldn't
resist ;-) is that the encoder starts and the player sends off
its first RequestBlock. First, the backend starts grabbing frames
from the card. Once it has a few it can start to compress then
and write them to the file. Next, another thread waits until
it can read enough data from the file to send it over a socket
to the frontend. The read ahead thread on the frontend starts
to read data from the socket but doesn't allow the player to get
any data until it meets a minimum amount of buffered data (the
'rebuffering" message means that it is below this minimum).

Once the read ahead thread is satisfied, the data can be decoded
and stuffed into a buffer of decoded frames that the player can
play. The player can't start until it has a minimum number of
frames. If the player runs out of frames to play, it has to stop
and wait for more frames to be decoded. When this happens you see
the 'prebuffering pause' message.

So, for the player to run smoothly, there needs to be about 2sec
or more of data in the pipeline. Even if the first frame was
displayed more quickly, there would need to be some stuttering
until it fell far enough behind for all the steps to have enough
data to work with.

If the ringbuffer was continuous rather than restarting after a
channel change, channel changes still wouldn't be instantaneous.
You would see the last 2 or 3 seconds of the old channel before
the first frame of the new channel is displayed.

Xawtv doesn't record so it can pretty much grab a raw frame and
display it. It only needs to have a couple frames so channel
changes can happen in a fraction of a second. However, it takes
time for myth to grab, encode, write, read, pass to another
process, decode then display.

This is not to say that there aren't ways to trim a tenth of
a second or two off the channel changes or that there might be
problems that could cause channel changes to take more than
3 seconds. What I am saying is that unless there is some magic
new redesign, channel changes will have to have a delay on the
order of 2 seconds or more as a result of recording the data
into a file so that timeshifting is possible.

--  bjm