Enabling decryption check increases number of FTA muxes/channels found

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

Using the same configuration as reported in #8726.

Scan details: full UK DVB-T scan using Sutton Coldfield transmitter with 6 available muxes. Default signal/tuning timeouts of 1000/3000ms. ALL services (DVB+MPEG) scanned.

Irrespective of whether channel decrytpion testing is enabled in the scanner, a single mux is found during a full scan. The NIT contains details of the 5 missing missing muxes, which the scanner tries to tune to. See #8731 for more details of this.

However, if decryption testing is disabled (default), only 4 of the 5 muxes found in the NIT are tuneable. When decryption testing is enabled, all 5 of the muxes seen in the NIT are tuneable, and all DVB channels are successfully configured.

I have repeated this test more than once at different times of the day, and have observed the same results. The logs (attached) do suggest that the signal acquisition time is borderline for this particular card (taking of the order of 900ms with a signal timeout of 1000ms) but I do not understand how the decryption testing is influencing this (which surely only occurs once a lock is obtained on a mux?).

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

DVB-T channel scan output with decryption checking enabled

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

DVB-T channel scan output with decryption checking disabled

[Github]

Channel Scanner: Reset decryption check status when the timer elapses.

The channel scanner has timeouts for tuning, signal lock, and decryption. A single timer variable is used, and a single method is used to check if the timer has run out. The first thing that method did was check if we were testing decryption. However, when that timer would elapse, the variable was not reset until after the *next* tune of a multiplex. In essence, every timeout (tune, lock, and decryption) after the first decryption test became the hardcoded decryption timeout of 4500ms.

Nick Morrott reported that with the default timeouts, on a card with slow tuning, he found many more muxes with decryption testing enabled than without. Because of this bug, it stands to reason that the extra 2.5-4x tuning time allowed for him to find additional muxes. The channels found *should* match regardless of the test decryption option at this point. In the case of cards/drivers with poor tuning performance, the right solution to find all the muxes is to increase the tuning and signal timeouts.

The above is my troubleshooting and fixing with only the code to work with (and no DVB equipment, programming, or country). Hopefully it's right. ;)

Fixes #8734.

Branch: master Changeset: e7f430a9ae112307745dd4ee5a33648a1d460609

[robertm]

Nick, if you want to confirm that the scanning behavior is now the same with and without decryption testing enabled, I will backport to .24-fixes.