Full Scan for UK DVB-T not picking up all multiplexes

[Nick Morrott <knowledgejunkie (at) gmail (dot) com>]

This is a follow-up to ticket #6205 which was closed before the OP provided the required information.

An earlier DVB-T Full Scan for the UK (Sutton Coldfield) resulted in only 1 of 6 multiplexes being detected (log file dvbt-fullscan-uk-1of6-multiplexes-found.zip)

Subsequent tuned scans for the remaining 5 multiplexes resulted in the remaining channels being successfully imported (log file dvbt-tunedscans-5-missing-multiplexes.zip).

I noticed that the log file during the full scan includes details of all multiplexes, but 5 of these were not tuned to automatically:

TerrestrialDeliverySystemDescriptor: Frequency: 634166670
TerrestrialDeliverySystemDescriptor: Frequency: 658166670
TerrestrialDeliverySystemDescriptor: Frequency: 682166670
TerrestrialDeliverySystemDescriptor: Frequency: 714166670
TerrestrialDeliverySystemDescriptor: Frequency: 722166670
TerrestrialDeliverySystemDescriptor: Frequency: 746000000

MythTV details:

MythTV Version   : 20770
MythTV Branch    : trunk
Library API      : 0.22.20090424-2
Network Protocol : 45
QT Version       : 4.5.2

[Nick Morrott <knowledgejunkie (at) gmail (dot) com>]

Log of Full Scan for UK DVB-T

[Nick Morrott <knowledgejunkie (at) gmail (dot) com>]

Log of Tuned Scans for missing multiplexes

[Nick Morrott <knowledgejunkie (at) gmail (dot) com>]

Updated Full UK DVB-T scan logs and channelscan* tables.

MythTV Version   : 21047
MythTV Branch    : trunk
Library API      : 0.22.20090727-1
Network Protocol : 45
QT Version       : 4.5.1
Options compiled in:
 linux release using_oss using_alsa using_pulse using_backend using_dvb using_frontend using_hdpvr using_iptv using_ivtv using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_live using_mheg

Full UK scan found 1/6 muxes. The channelscan_channel table includes 3 copies of the 22 channels found on the one mux, however when adding the channels to the channel table, only a single copy was added.

Logging was carried out using "--verbose channelscan,channel,record,siparser"

Checking the log, the FrequencyListDescriptor? values seem to be completely wrong the Sutton Coldfield Tx. Many of the lines below only contain a single correct frequency. The first post on the ticket list the correct freqs.

    FrequencyListDescriptor: frequencies:  762000000 562166670 801833340 634000000 786000000 545833330
    FrequencyListDescriptor: frequencies:  474000000 618166670 577833340 850000000 722166670 578166670
    FrequencyListDescriptor: frequencies:  554000000 698000000 545833340 825833340 618000000 537833330
    FrequencyListDescriptor: frequencies:  498166670 642000000 482166670 753833340 682000000 569833330
    FrequencyListDescriptor: frequencies:  522166670 666000000 506166670 777833340 658000000 489833330
    FrequencyListDescriptor: frequencies:  730000000 530166670 834166670 714000000 762000000 513833330
    FrequencyListDescriptor: frequencies:  762000000 562166670 801833340 634000000 786000000 545833330
    FrequencyListDescriptor: frequencies:  474000000 618166670 577833340 850000000 722166670 578166670
    FrequencyListDescriptor: frequencies:  554000000 698000000 545833340 825833340 618000000 537833330
    FrequencyListDescriptor: frequencies:  498166670 642000000 482166670 753833340 682000000 569833330
    FrequencyListDescriptor: frequencies:  522166670 666000000 506166670 777833340 658000000 489833330
    FrequencyListDescriptor: frequencies:  730000000 530166670 834166670 714000000 762000000 513833330
    FrequencyListDescriptor: frequencies:  762000000 562166670 801833340 634000000 786000000 545833330

The other thing to note is that the TerrestrialDeliverySystemDescriptor? info in the log does seem to indicate that the scanner is 'seeing' the channels/services but is not handling them.

[Nick Morrott <knowledgejunkie (at) gmail (dot) com>]

Log and channelscan* tables from full UK scan

[stuarta]

It's correct that only one of the frequencies listed in the FrequencyListDescriptor? is correct.

For each mplex contained in the NIT the primary frequency for that mplex is contained within the TerrestrialDeliverySystemDescriptor? The frequencies listed within the FrequencyListDescriptor? are alternate frequencies that the repeater transmitters use.

So it's valid that your mplex is on only one of those frequencies.

Stuart

[janne]

(In [21463]) less strict the duplicate check when adding transports to the scan list. Refs #6689

Some DVB demods seems to have problems with auto parameters. This adds transports from the NIT unless a SDT for that transport was seen.

[janne]

(In [21552]) add transports from NITscan at the and of the original scan, Fixes #6689

makes check for already scanned transport considerable easier also activates NITscan for full scans from frequency tables

[Nick Morrott <knowledgejunkie (at) gmail (dot) com>]

Testing the channel scanner (DVB-T, UK, decrypt testing enabled) on current head (r21591) has yielded big improvements, with all 6 muxes being found, and all channels seemingly being detected (84 DVB, 1 MPEG) :)

However, after the addition of the NIT mux scanning in r21552, I am seeing the following issues:

i) Channels that are available on the first (and only in this user's case) mux found during the initial channel scan have their freqid set to "55", rather than NULL. All other channels have the freqid set to NULL as expected.

ii) I had to increase the signal timeout to 3000ms in order to get all of the muxes added from the NITscan scanned successfully at the end of the normal channels 22-68 scan. (This was increased to 1000ms in r21551). This may be particular to my card (KWorld DVBT-210).

iii) A duplicate mux is added to dtv_multiplex having a networkid of 0. A single MPEG channel is associated with this mux. This duplicate mux is not present in channelscan_dtv_multiplex.

Full logs and DB tables provided.

[Nick Morrott <knowledgejunkie (at) gmail (dot) com>]

Forgot to add - the following encrypted channels were added with FTA checked and encryption checking enabled (SID in brackets):

ESPN (16096)

G.O.L.D. (15552)

Home (14976)

Television X (15232)

TOPUP Anytime 2 (16256)

TOPUP Anytime 4 (27328)

Not sure if the logs provide enough information to determine whether these channels are misrepresenting their encrypted status or whether they were deemed FTA incorrectly during processing.

[stuarta]

Replying to Nick Morrott <knowledgejunkie (at) gmail (dot) com>:

Forgot to add - the following encrypted channels were added with FTA checked and encryption checking enabled (SID in brackets):

ESPN (16096)

G.O.L.D. (15552)

Home (14976)

These three shouldn't make it in...

Television X (15232)

This isn't marked as encrypted and is thus technically correct.

TOPUP Anytime 2 (16256)

TOPUP Anytime 4 (27328)

These tend to broadcast an MHEG banner when not showing video content. The MHEG isn't encrypted as it tells you how to subscribe :)

These also shouldn't make it into the channel list.

Stuart