DVB-T radio programs time display and cutlist problems

[John Veness <John.Veness.mythtv@…>]

Playback of UK DVB-T (Freeview) radio programs exhibit two problems which I think are related, hence me putting it into one ticket. These are recordings that contain audio only (and MHEG) but no video.

Problem 1:

If you press the key to skip forward 10 minutes, the OSD will show that you have gone forward 10 minutes, but in actual fact, you will have gone forward 12 minutes (this has been determined by listening to the recording on a straight playthrough and noting what happens at certain times).

So for example, on a 35 minute recording, you can do the following:

• start playback from the start
• press to skip forward 10 minutes, the OSD will say approx 10:00 but I know that this is actually playing something that happens approx 12 minutes into the recording
• press to skip forward another 10 minutes, the OSD will say approx 20:00 but I know that this is actually playing something that happens approx 24 minutes into the recording
• press to skip forward another 10 minutes, the OSD will briefly show approx 29:10 and play a burst of sound which I know actually happens at the end of the recording (i.e. at 35 minutes) before exiting

You'll notice that 29:10 is approximately 50/60ths of 35 minutes.

Problem 2:

On DVB-T recordings that I recorded in 0.24, and edited in 0.24 (that is, I added a cut at the beginning and a cut at the end to trim the recording down to just the actual show), when I play them back in 0.25, without skipping through the recording, the following happens:

• Interestingly, it seems to start in the correct place, i.e. at the start of the actual show a couple of minutes into the recording
• But playback will stop early, several minutes from the end

To work round this, I have to remove the cut point at the end of the recording, and restart playback and try to navigate to the correct place. I don't have timestamps for this issue, but I'm pretty certain that playback is stopping early because Myth "thinks" it is reaching the frame at which the end cut point exists 50/60ths too early.

Some observations:

Firstly, note that if you play back one of these recordings with no cutlist points defined, and without skipping forward or back, everything seems fine - you will hear the entire recording OK and if you bring up the OSD, the time display looks fine from start to finish.

When pressing to skip forward or back 10 minutes, the skip doesn't take effect immediately. There is a few seconds gap before it skips and the OSD pops up. This only happens on DVB-T radio recordings, not DVB-T TV recordings. It "feels" as it Myth is having a problem trying to find the correct place to skip to.

This wasn't a problem in 0.24 or earlier versions. The same recordings that I made in 0.24 played fine in that version, but exhibit the problems mentioned above in 0.25. The problems are observed both on old (0.24 era) and new (0.25 era) recordings.

Without wishing to be too presumptuous, I *think* the problem is that Myth is treating the recordings as if at 60fps, rather than 50fps, although as there is no actual video on these recordings maybe that statement doesn't quite make sense.

I can upload a sample UK DVB-T radio recording and logs if desired.

[John Veness <John.Veness.mythtv@…>]

Another observation that I think is related to this problem. While playing back one of these DVB-T radio recordings, if I stop playback (either pausing or stopping completely and returning to the menu), then resume, playback will resume some time further into the recording than the place I stopped. Interestingly, this doesn't always happen - sometimes it will resume at the same point. I think, but haven't accurately tested, that if you stop or pause for some time (some minutes) then it won't resume in the same place, but if you stop or pause for just a few seconds, then it will resume in the same place.

Needless to say this makes listening to a recording in more than one sitting rather tedious.

[John.Veness.mythtv@…]

I have just noticed that if I bring up the Playback Data info in the OSD while playing back one of these DVB-T audio-only recordings in 0.25, sure enough it says it is 30fps (presumably a default or a faulty autodetection), whereas all my DVB-T video recordings are 25fps. I'm sure this is relevant to my problem with times, seeking and editing.

[Joe Bryant <tenminjoe@…>]

Just to confirm that this isn't some problem specific to John Veness, I'd like to add that I am also having difficulty using the skip buttons on DVB UK radio recordings since 0.25, even though it was working okay before (and TV still works okay now).

[Roger Siddons <dizygotheca@…>]

John's diagnosis is correct. Setting UK frame rate (25) for non-video streams was inadvertently broken by ​https://github.com/MythTV/mythtv/commit/857d804b8 so that the default (29.97) is used instead.

This needs applying to master, 26/fixes and 25/fixes.

[Roger Siddons <dizygotheca@…>]

Joe's issue (to which John also alludes) is a separate problem; that skipping/jumping in radio is very unresponsive. Single skip/jumps can take 1/3 - 1 sec, but a series of consecutive jumps can take up to 7 secs. Frequently the OSD is not displayed (because the display request times out). This is markedly slower than skipping in a TV programme.

The problem is a consequence of ​http://code.mythtv.org/trac/changeset/d207a0bddddac4cb015746e2a4b4e5f841897c8c/mythtv, which limits the ringbuffer block size for low bitrates.

UK DVB-T Radio is often 192 Kbs (ie. BBC 3/4) with significant DSMCC_B data (reporting a bitrate of 0). The above change limits the ringbuffer to 4 Kb reads, so the decoder thread takes a long time to read a frame (GetFrame) and will not respond to the seek request until it has finished.

I have attached a debug log of 26/fixes (with extra debug code) which demonstrates the issue. The test case is a series of single skips and jumps followed by rapid ones (2 Hz) on a 192 Kbs radio programme (BBC Radio 4). Seek requests are marked by DoPlayer and they are completed by ClearAfterSeek. This is a good proxy for the UI responsiveness.

Sample timings (secs between request/response) for this scenario: each column is a skip/jump attempt; rapid jumps are shown in a single cell.

192 Kbs Radio (4K block)	0.33	0.3	0.43, 3.1	0.82, 0.13, 6.16	0.12, 5.67, 7.57	2.6, 7.5, 7.5
192 Kbs Radio (32K block)	0.3	0.34	0.3, 1.1	0.33, 0.4, 0.44, 0.14, 1.2, 1.6	0.5, 0.46, 0.44	0.3, 0.37, 0.5, 1	0.3, 0.35, 0.34, 1, 0.8
TV (384K block)	0.03	0.26	0.02, 0.09	0.09, 0.17, 0.11, 0.11	0.02, 0.06, 0.09	0.34, 0.68, 1.91

The Radio (32K block) timings were obtained by hacking the optimisation code to use a minimum 32K block.

Apart from the poor 4K figures, note the variability of all the times and the progressive deterioration with multiple skips in all cases. Interestingly, a 64 Kbs radio stream (TalkSport) with a 2K block size performs much better, possibly because it doesn't contain so many data packets.

The issue is not apparent in master because of ​http://code.mythtv.org/trac/changeset/98b1a775cd53aaa9dca1939d4ffa24de7f1add64/mythtv, which overrides the reported bitrate (192 Kbs) with one derived from the filesize (1413 Kbs), resulting in a 32K read block now being used.

The attached patch monitors seek requests whilst reading a frame. It aborts the long read as soon as a seek is detected (the frame will be discarded anyway). All skips/jumps now complete in less than 0.1 secs.

Presumably the latter change will not be back-ported: this patch therefore solves the slow skip issue for 25/fixes & 26/fixes. For master this patch just makes skip/jumps snappier, more uniform and guards against slow reads locking the UI out.

[Roger Siddons <dizygotheca@…>]

Replying to Roger Siddons <dizygotheca@…>:

John's diagnosis is correct. Setting UK frame rate (25) for non-video streams was inadvertently broken by ​https://github.com/MythTV/mythtv/commit/857d804b8 so that the default (29.97) is used instead.

This needs applying to master, 26/fixes and 25/fixes.

I should clarify that this corrects the OSD time readout and audio/OSD synchronisation. I believe it fixes the cutpoint issue as well.

[John.Veness.mythtv@…]

Many thanks for working on this, Roger. I look forward to seeing these patches released in 0.25-fixes.

Just an idle thought - ​https://github.com/MythTV/mythtv/commit/857d804b8 is related to aspect ratio changes, and I'm wondering if something in there caused bug ​http://code.mythtv.org/trac/ticket/10829 ?

[Roger Siddons <dizygotheca@…>]

It took me a while to realise my ​2nd patch breaks the Cut List Editor and so should not used. Sorry for the noise.

Looking afresh, as the problem is the deduced bit rate being too low, the simplest solution is to apply the relevant part of ​ticket 10019 (that fixed this as a side-effect?). I've added a ​3rd patch that does this and fixes the skip/jump response for 0.25/fixes & 0.26/fixes on the assumption that 10019 isn't going to be back-ported.

[Stuart Auchterlonie]

Closing old tickets. Radio streams should work now anyway.