[mythtv-commits] Ticket #13156: radio channels: mythfrontend hang (endless loop) when exiting 'LiveTV' and delays on switching channels
MythTV
noreply at mythtv.org
Tue May 28 21:05:07 UTC 2019
#13156: radio channels: mythfrontend hang (endless loop) when exiting 'LiveTV' and
delays on switching channels
----------------------------------------+-------------------------------
Reporter: Stephan Suerken <absurd@…> | Owner: Klaas de Waal
Type: Bug Report - Hang/Deadlock | Status: assigned
Priority: minor | Milestone: needs_triage
Component: MythTV - General | Version: Master Head
Severity: medium | Resolution:
Keywords: radio audio dvb-s | Ticket locked: 0
----------------------------------------+-------------------------------
Comment (by Klaas de Waal):
I've been looking into this but Live TV is a complicated piece of code and
I have not found a quick fix. This definitely needs more eyeballs than
just mine.
Below are my notes on the various issues.
**1. Startup delay of about 20 seconds for audio channel**
Sequence:
- Select menu Program Guide
- Select radio channel
- Enter gives popup menu
- Select "Watch this channel" (done here on 22:08:06)
It takes now more than 20 seconds
{{{
2019-05-28 22:08:15.350882 W
RingBuf(/mnt/ava/recordings/10101_20190528200808.ts): Taking too long to
be allowed to read..
2019-05-28 22:08:21.529038 W
RingBuf(/mnt/ava/recordings/10101_20190528200808.ts): Taking too long to
be allowed to read..
}}}
Playing starts at 22:08:27, 21 seconds after the start.
As I understand it, the Live TV code sets up a ringbuffer and it expects a
stream with a rate of 8000kbit/second:
{{{
2019-05-28 22:08:08.106298 I
RingBuf(/mnt/ava/recordings/10101_20190528200806.ts):
CalcReadAheadThresh(8000 Kb)
-> threshhold(3584 KB) min read(320 KB) blk
size(128 KB)
}}}
It waits until it has read at least 320kByte before it starts to play.
This corresponds to about 20 seconds of music.
The way forward is to make the expected bitrate and the associated buffer
sizes dependent on the type of stream that is going to be received. This
information is not yet present in the database but it can be when ticket
#8774 is implemented.
**2. Endless loop/hang on "jump forward" in live audio**
It is not necessary to switch to another audio channel to get into the
"endless loop/hang" state from which no recovery is possible. A "jump
forward" (right arrow) which is in my setup about 45 second has the same
effect.
If you start audio then it starts to play after 20 seconds. The "Info"
(press "i" key) bar shows that the audio is then about 20 seconds delayed,
which is consistent.
A "jump forward" tries to make this gap as close as possible. The state is
now the same as when a channel switch has been made.
This is consistent; when a channel switch is made the audio starts to play
quite soon, albeit with stuttering; it does NOT wait for 20 seconds/320kB
now but it plays immediately.
**3. What goes wrong (tentative analysis)**
Crucial is the call to "decoder->GetFrame" in mythplayer.cpp:3876
{{{
if (ffrew_skip == 1 || decodeOneFrame)
ret = decoder->GetFrame(decodetype);
}}}
When the system is working OK then this function is called for every video
frame, about every 40 milliseconds. It goes wrong when this function does
never return. That is what happens after an audio "jump forward" or
channel change.
When the decoder->GetFrame does not return then the code surrounding it,
which tries to kill the decoder when e.g. Escape is pressed, is never
executed anymore. This is essentially the "endless loop/hang" condition.
It did confuse me for a while that there are actually video frames
processed when playing an audio-only channel. Apparently, what happens is
that it is detected somewhere that there is no video and hence dummy video
frames are generated so that the existing TV (video + audio) playback
mechanism can be used also for audio-only channels.
It looks as if the generation of the dummy video frames is halted when
there is not enough data in the ringbuffer. If you pause (press "p") for
while and then continue again there is enough data in the ringbuffer, the
decode->getFrame() gets video frames again and everything works OK.
However, if you do not pause then the ringbuffer will never fill again,
because the audio playback consumes data as fast as it is received.
**4. Playback of data-only channel**
Live playback of the "GDS Service" channel, as noted by me in comment:6,
results in the same "endless loop/hang" condition. Here also the
decoder->getFrame() function does never return.
In this case however it is somehow logical, as the "GDS Service" channel
does contain only data (software download etc) and no video or audio.
It is most likely a bug that this channel is in the channel list when only
TV or TV+Audio channels are selected in the channel scan. To be
investigated.
When playing back a recording of "GDS Service" the recording is read to
the end and no error is given.
It does make sense to give an error message when trying to play back a
data-only channel, either live or recorded. For this it would be useful to
have information about the channel in the database, as is the subject of
ticket #8774.
Note that it can make sense to record data-only channels, one might be
interested in the data for other purposes than playback.
--
Ticket URL: <https://code.mythtv.org/trac/ticket/13156#comment:7>
MythTV <http://www.mythtv.org>
MythTV Media Center
More information about the mythtv-commits
mailing list