Option to use LCNs for numbering services in Favourites & other bouquets

[prl]

Currently, only the Terrestrial LCNs bouquet uses LCNs to number its entries (and does that in a fairly clumsy manner by padding the table).

It would be more in line with user expectations that LCNs are used for numbering services in the UI, so that the LCNs replace the current index numbering everywhere it appears, in particular, the channel list, info bar and in selection of services by number from the remote.

Numbering should be added to bouquets that currently are not numbered - All (FAV, RED), the bouquets under Satellite (FAV, GREEN) and the bouquets under Provider (FAV, YELLOW).

[prl]

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

• This issue's description has been changed

[IanSav]

To maximise the functionality of this request the code change should allow for the storage of 2 LCN definitions as well as the storage of 2 channel names.

The first LCN should be the LCN as assigned by the broadcaster if such an LCN is assigned. (A value should not be required to maintain compatibility with European broadcasts where LCNs are not favoured.) The second LCN should be the LCN as assigned or renumbered by the user. The second LCN may also be automatically assigned if the broadcaster doesn not provide LCN data or by the OP41 processing where a duplicated LCN is discovered during a scan. In this case the as broadcast LCN is saved in the first LCN location (as before) but the second LCN would be the scanning assigned number or the first available free LCN in the 350 to 400 range as prescribed by the Australian standard (as appropriate).

The first LCN is only ever used during scanning and for dynamic channel updates. If a change in LCN is detected in the broadcast stream such that there is a difference between the stream and the stored LCN value then the user can be alerted to the change. They can then nominate to accept the new LCN as the displayed LCN or reject the change. If the change is accepted the new LCN is stored in both the first and second LCN buffers. If the change is rejected then the new LCN is stored in the first buffer (so that future changes can be detected) but the current LCN stored in the second buffer is left unchanged.

The second LCN buffer is the LCN that is to be used and displayed in ALL UI contexts as described above by Peter.

Just as there should be two buffers for the LCN so should there be two buffers for the channel name. The channel name should be managed ssing exactly the same logic as for the LCN. The first buffer tracks the name as broadcast. The second buffer is used for ALL UI displays.

To fully realise the benefits of this enhancement there should be UI setting facilities that allow for the LCN to be renumbered and the channel to be renamed. These edits are to only be applied to the second occurrence of either item. That is, the user is free to renumber or rename any channel to suit their needs but the as broadcast data remains available for automated update detection.

If this comment is not clear then please ask for more information.

[IanSav]

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

• The status has been updated, from New to Confirmed.