Opened 10 years ago

Closed 15 months ago

#9777 closed Bug Report - General (Abandoned)

Channel scanner stores centre freq instead of offset for DVB-T

Reported by: david_a <baroque@…> Owned by: danielk
Priority: minor Milestone: unknown
Component: MythTV - Channel Scanner Version: 0.24-fixes
Severity: medium Keywords: offset frequency
Cc: Stuart Auchterlonie Ticket locked: no


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, 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.]

Attachments (1) (9.4 KB) - added by david_a <baroque@…> 10 years ago.
scanner log

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by david_a <baroque@…>

Attachment: added

scanner log

comment:1 Changed 10 years ago by aklinbail@…

Hi ,

I can confirm that I have also been suffering from this problem for quite some time. This was masked by the fact that one of my tuners didn't suffer from the problem so I thought it was an issue with the individual tuner card.. However this problem has existed since at least version 0.21. There has been much much discussion on the mythtv-users list and also the shepherd list (Australian grabber).. However this may not be apparent to new users or users who do not participate in mailing lists.

Running dvbscan produced a channels.conf that was useable for both of my tuner cards and displays the correct offset frequencies. (as described above)



comment:2 Changed 10 years ago by aklinbail@…

actually the correct channel 9 (nine go and gem) frequency is 191625000 125 KHz offset. Please advise if you would like me to upload the results of w_scan or dvbscan

comment:3 Changed 10 years ago by david_a <baroque@…>

Indeed, this problem has existed in prior versions. I should explain that I decided to submit this particular ticket because as far as I could tell, no-one had yet documented the exact nature of the problem or provided scan logs needed by the developers. There was one related ticket (#9167) which had become dormant (waiting some months for additional information from the submitter).

Another purpose of writing the bug ticket was to propose a possible solution, namely that the scanner code could perhaps (for a full scan, untuned) use information from the NIT, which it appears to be ignoring at the current time. (Incidentally I don't think the tuner would notice the difference of 120 vs 125kHz for Nine. In my view the goal would be simply to make the scanning process automatic without the user having to concern themselves with any of the frequency detail, and it appears this goal could be achieved by using the NIT information.)

I did have a look at the code myself with a view to proposing a patch, but alas there wasn't enough commenting in the code for me to be able to figure out how it is currently working, so I wasn't able to pursue that line any further. In the meantime of course we can keep susceptible tuners happy using the workaround of manually updating the transport frequencies, but that does become a bit tedious if you're doing several installations of myth, for test purposes, or upgrading, etc.

rgds David

comment:4 Changed 10 years ago by aklinbail@…

If I get some time... I'll write up a wiki page for the troubleshooting section with the other workaround I posted to the mythtv-users list... (using dvbscan)

comment:5 Changed 10 years ago by david_a <baroque@…>

Yes any additional info on a workaround (esp. if it may be quicker than manually adjusting and re-scanning the relevant transports) would be worth recording in the wiki.

Another comment worth noting in this discussion (given this particular detail may not be obvious unless a person has RF receiver experience) is that broadcast tuners use their own automatic fine tuning to lock onto a signal once they've been commanded to a frequency which is 'close enough' to the real one. The design of the tuner determines how close is close enough, and is the reason why some tuners don't care if the commanded frequency might be 125kHz away from the real transmitter frequency, but others do. It also follows from this that the value stored in the dtv_multiplex table does not have to match exactly the transmitter frequency, but needs to be close enough that all models of tuner will lock.

But ultimately the reason for documenting this bug was to provide enough detail to allow the code to be modified so that, in any country such as Australia which employs DVB-T offsets, the scan would provide a working result automatically without requiring the user to resort to external utilities or manual adjustments.

comment:6 Changed 10 years ago by david_a <baroque@…>

From the frequency table (in mythtv source called frequencytables.cpp), there currently appear to be 2 systems of offsets used by 4 countries: UK,FR: +ve and -ve offsets of 167kHz ES,AU: +ve offset only of 125kHz

Noticing that AU uses only a +ve offset, I tried a bit of creative thinking and bumped the frequency table up by half the offset, to see if the scanner would then automatically produce a working result for centre and offset transmitters (and for any tuner hardware). The scanner found all stations easily, but since the scanner is storing the tabulated base frequency which in this test was about 60kHz away from any of the real transmissions, that 60kHz was still a challenge for some tuner cards when it came to tuning to the multiplex for watching/recording. Even if it had worked, it is (a) not a technically correct solution, and (b) not a solution for countries which have both +ve and -ve offsets! ... but still an interesting experiment.

comment:7 Changed 9 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie added

comment:8 Changed 9 years ago by prologic@…

Interested in seeing this resolved as I have the same problem. Rather than a workaround (many such exist on forums) I'd like to see this fixed in the scanner logic. Time permitting I may try to fix this in the 0.24.1 source my backend/frontend currently uses.


comment:9 Changed 9 years ago by prologic@…

Has there been any work to fix this?

comment:10 Changed 5 years ago by lyricnz@…

I ran into this again this week. Quite annoying.

comment:11 Changed 17 months ago by Klaas de Waal

Status: newinfoneeded_new

Is this problem still present in today's master? If it is then it should be fixed but for this I need a debug log plus someone willing to test the fixes as my local signals do not have offsets.

A log with the options as below created with the latest master would probably have enough information:

"mythtv-setup -v chanscan,channel,record --loglevel=debug 2>&1 | tee ms-20191201.log"

comment:12 Changed 15 months ago by paul-h

Resolution: Abandoned
Status: infoneeded_newclosed

No reply with requested information in 3 years.

Please reopen if you can supply the requested info.

Note: See TracTickets for help on using tickets.