[mythtv-commits] Ticket #10833: DVB-T radio programs time display and cutlist problems

[MythTV]

#10833: DVB-T radio programs time display and cutlist problems
------------------------------------------------+--------------------------
 Reporter:  John Veness <John.Veness.mythtv@…>  |          Owner:
     Type:  Bug Report - General                |         Status:  new
 Priority:  minor                               |      Milestone:  unknown
Component:  MythTV - General                    |        Version:
 Severity:  medium                              |  0.25-fixes
 Keywords:                                      |     Resolution:
                                                |  Ticket locked:  0
------------------------------------------------+--------------------------

Comment (by 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.

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/10833#comment:5>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center