[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