Scan doesn't handle duplicate services on different frequencies correctly

Issue #60 resolved
prl created an issue

When duplicate services are available on more than one frequency, the T3 will save the services from the first frequency that has usable signal even if a later duplicate of the services is found on a frequency with stronger signal. This is different from the behaviour of more recent DP series firmware.

It also fails to comply with section 3.2 of Free TV Australia Operational Practice OP - 41 Logical Channel Descriptor and Allocation of Logical Channel Numbers.

This will mean that the location-based scanning in the current scan tables (terrestrial.xml) will not work as intended, and neither will it allow the correct representation of Digital Retune simulcasts.

For the Digital Retune simulcasts to be handled correctly, when the signal strength/quality of the duplicate services is approximately the same, it should consistently select either the first or the last frequency scanned at that strength.

This problem can also cause inappropriate frequencies to be used when All Other Locations (or Full Scan, in more recent firmware) is selected for the scan location.

Reproduction steps

Jai/Wiz HQ has encountered incorrect scanning when the digital retune (new) frequencies are at the start of the Sydney scan list. This causes him to have Seven and Ten services from a weaker transmitter (Kings Cross or North Head) than he should be receiving from (North Sydney).

I have marked Reproducability as Always, because it will almost always happen if you are in an area with the right set of frequencies/signal strengths to cause the problem.

Comments (10)

  1. prl reporter
    • removed issue_update

    The issue was updated with the following change(s):

    • This issue's description has been changed
  2. Peter Urbanec

    A file was uploaded. reference to attachment Free_TV_OP_41_LCN_Descriptor_Issue_7_February_2013.pdf (OP-41 Logical Channel Descriptor and Allocation of Logical Channel Numbers) This comment was attached:

    Free TV Australia Operational Practice OP-41 Logical Channel Descriptor and Allocation of Logical Channel Numbers

  3. Peter Urbanec
    • removed issue_status

    The issue was updated with the following change(s):

    • The status has been updated, from New to Delegated.
  4. Peter Urbanec
    • removed issue_priority

    The issue was updated with the following change(s):

    • The priority has been updated, from High to Critical.
  5. Peter Urbanec
    • removed issue_update

    The issue was updated with the following change(s):

    • This issue's description has been changed
  6. Peter Urbanec

    A file was uploaded. <strike>enigma2 test binary</strike> This comment was attached:

    Support for Australian 125kHz offsets and partial support for OP-41 overlap case 1.

    Need to test behaviour in areas with translators.

  7. Ian Brabham

    A file was uploaded. reference to attachment tuner.tgz (tarball of 3 scan logs and etc enigma2) This comment was attached:

    Three logs of tuner scans with default Melbourne, custom UHF first and custom VHF first terrestrial.xml tables.

    The /etc/enigma2 is after the custom VHF first scan. It has preferred the weaker GTV44, HSV41 and SBS50 which have usable but occasionally broken signals. ABC47 and ATV54 appear not to have made the grade they are considerably weaker signals.

  8. Peter Urbanec

    A file was uploaded. reference to attachment enigma2 (enigma2 test binary) This comment was attached:

    This version should improve the way channel signal strength is compared to hopefully consistently pick channels with better reception.

    It will also significantly speed up scans. A full scan goes from about 4:35 to 1:50, Sydney scan is done in about 25 seconds.

  9. Peter Urbanec
    • removed issue_status

    The issue was updated with the following change(s):

    • The status has been updated, from Delegated to Testing.
  10. Peter Urbanec
    • removed issue_resolution
    • removed issue_percent
    • removed issue_close
    • removed issue_status

    The issue was updated with the following change(s):

    • The status has been updated, from Testing to Closed.
    • This issue has been closed
    • This issue's progression has been updated to 100 percent completed.
    • The resolution has been updated, from Not determined to Fixed.
  11. Log in to comment