[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**

 - 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
 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

 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

 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