[mythtv-users] LiveTV: stutter at program start/change resolved by short pause..?

[Mark Kendall]

As a dev who doesn't 'detest' live tv, I thought you might appreciate
a developers observations on the state of live tv program changing.

At the moment I'm broadly aware of 4 different symptoms/issues, with
different levels of impact (and when I say aware, I generally mean
issues that I've been able to replicate):-

1. After a channel change, there will often be a brief, one off video
hickup a second or two after playback has (re)started. This appears to
be caused by high load on the backend machine caused by expiring older
live tv segments and/or generating a preview for the segment that has
just finished.

2. As per the OP, live tv will stutter on and off continuously until
given some sort of a poke (usually a pause). I used to see this on my
remote frontend, spent a large amount of time trying to debug it
(without success) and finally fixed it by ensuring that the setting
'Always stream from the backend'(?) was enabled. That setting has been
removed in trunk (and hence 0.24) and it is now the default. That
said, I think whatever causes this problem is a pretty subtle issue
and what worked for me probably won't work for everyone. I may just
have changed some timing enough somewhere to avoid the problem. Given
the amount of code that has changed since 0.23, it may also be fixed
in trunk.

3. Temporary picture break up/frame loss when the program changes
(N.B. not a channel change). This is a symptom of how live tv is
implemented as a series of recordings rather than as one single
stream. When the frontend is watching livetv and comes to the end of
the current 'recording', it will ask for the next recording and switch
over to that. As currently implemented, this involves tearing down and
recreating various items and in most situations this just doesn't
happen fast enough to avoid some dropped frames. There may also be
some unrecoverable frame loss happening in the backend itself as the
recorder switches from one program to the next (i.e. the two recording
files don't join seamlessly). Improving this is something I'd like to
try and tackle for 0.25.

4. Complete playback failure:) Clearly this is a big issue for some
people and I've experienced it in recent times -  though for some
reason not at the moment. The main problem here is that there are
probably different causes for different systems. For some, it's using
VDPAU on a card with only 256mb - which will fail intermittently. For
most however, I believe it is a combination of circumstances on the
backend. As noted above, the backend will be finishing one recording
as it starts another. This may coincide with multiple preview
generations, perhaps some commercial flagging and probably most
importantly with the expiry of some older files. All of this will lead
to high cpu and disk io load - and under the right conditions may mean
the frontend just doesn't get access to the new file in time; and
playback fails. This may be aggravated by socket errors that seem to
be an issue in trunk at the moment (or indeed may be causing them) and
by frontend setups that are less tolerant of interruptions to the
stream (e.g. slow network connection, poorly configured audio).

Clearly I'd like to fix 4 asap - and there are a number of tickets
that are directly relevant.

regards

Mark

(p.s. I'm not sure whether it is entirely relevant, and don't want to
give anyone false hope, but I did seem to minimise the video failures
(4) by ensuring network time protocol (ntp) was installed on one
frontend. YMMV)