[mythtv-commits] Ticket #9777: Channel scanner stores centre freq instead of offset for DVB-T

MythTV noreply at mythtv.org
Sat May 14 07:28:48 UTC 2011


#9777: Channel scanner stores centre freq instead of offset for DVB-T
------------------------------------------------+--------------------------
     Reporter:  david_a <baroque@…>             |      Owner:  danielk
         Type:  Bug Report - General            |     Status:  new
     Priority:  minor                           |  Milestone:  unknown
    Component:  MythTV - Channel Scanner        |    Version:  0.24-fixes
     Severity:  medium                          |   Keywords:  offset
Ticket locked:  0                               |  frequency
------------------------------------------------+--------------------------
--version Output:
mythbackend version: fixes/0.24 [v0.24-243-g9ba3ece] www.mythtv.org

------------------------------------------------+--------------------------
 The channel scanner (DVB-T full scan, in Australia) is storing centre
 frequencies instead of offset frequencies, for stations using the offset.
 Consequently some tuner cards cannot lock during normal operation of
 mythTV, resulting in empty recordings and failure to lock in LiveTV.

 Several of the DVB-T transmitters in Australia use their offset frequency,
 125kHz from the nominal centre frequency (evidently to avoid interference
 between them and adjacent services such as legacy analog).

 The workaround is to manually edit the transports, or re-scan by
 individual frequency if necessary, however until a user is aware of this
 issue, they would be wondering (as I was) why their tuner fails to work
 with some stations.

 I investigated the scanning process using different models of tuner, and
 found the scanner behaviour was the same, i.e. it consistently stores the
 centre frequency even for the stations using the offset. Therefore I
 believe the problem lies in the scanner logic, rather than its interaction
 with the hardware or drivers.

 Since some tuners, with enough timeout, will find the signal while
 scanning either the centre or offset frequency, it can be deduced that
 storing the frequency sent to the tuner (or with strongest signal reading)
 may not be reliable. Instead, the scanner I believe should wait for
 receipt of the Network Information Table, which contains the correct
 transmitter information, as shown below in the following grep output from
 scanner log file (for city of Melbourne).
 {{{
  $ grep -i terrestrialdelivery scanlog
     TerrestrialDeliverySystemDescriptor: Frequency: 177500000
     TerrestrialDeliverySystemDescriptor: Frequency: 191620000
     TerrestrialDeliverySystemDescriptor: Frequency: 219500000
     TerrestrialDeliverySystemDescriptor: Frequency: 226500000
     TerrestrialDeliverySystemDescriptor: Frequency: 536625000
     TerrestrialDeliverySystemDescriptor: Frequency: 557625000
 }}}
 3 of the 6 transmitters use their offset frequency (of which it is
 noticeable that one indicates a 120kHz offset as opposed to nominal
 125kHz, a minor discrepancy).

 Perhaps the scanner code is already *supposed* to be using the information
 from the NIT for each transport, however in practice it is not doing so,
 as evidenced by centre frequencies being stored for all stations as shown
 in following display of dtv_multiplex table:
 {{{
  mysql> select networkid,frequency from dtv_multiplex;
  +-----------+-----------+
  | networkid | frequency |
  +-----------+-----------+
  |      4115 | 177500000 |
  |      4114 | 191500000 |
  |      4116 | 219500000 |
  |      4112 | 226500000 |
  |     12802 | 536500000 |
  |     12832 | 557500000 |
  +-----------+-----------+
 }}}

 Being aware that DVB frequency offsets apply also in other countries
 (where different conventions may apply to the content of the NIT), the use
 of the frequency information from the NIT would of course require a sanity
 check to test whether the information is present, and whether it is within
 reasonable tolerance of a tabulated centre or offset frequency for the
 relevant country.

 In Australia at least, using the NIT information may offer a solution to
 this DVB-T scanning problem.

 I am attaching the scanner log produced with  mythtv-setup -v
 channelscan,siparser,record


 [Also as a footnote I will mention for anyone looking at the channel
 allocation tables published by the national authority at acma.gov.au, that
 for the VHF band below channel 10, there is a difference of one between
 the mythtv scanner channel number and the official channel number, due to
 the presence of channel "9A" in the official allocation. This however only
 affects the channel numbering in logs written by the scanner, and is of no
 consequence to the operation of the scanner, since it has the correct
 frequency table beginning at 177.5 MHz and with 7 MHz spacing.]

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/9777>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center


More information about the mythtv-commits mailing list