Using LCNs for channel numbering in all bouquets

Moderators: Gully, peteru

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: "spoo

Post by prl » Mon Aug 14, 2017 10:27

Thanks for the detailed response. As I said in my earlier post, I think that what I want to do with LCNs may only be applicable to the Australian situation.

It involves adding tags for LCN and signal strength to services in lamedb, and using them as the source for channel numbering where they are set. It might be possible to drive this from ABM, by having ABM generate lamedb LCN tags instead of using padding (which I consider to be an unwieldy hack).

There are still some issues to be thought through for the Austraian environment before I even make it available for alpha testing, like numbering of non-broadcast sources (like HDMI IN) and how the numbering scheme interacts with Open Webif.

With my changes, LCN numbering that way will be an option; LCN-like numbering will still be possible if people want to use it.

If there's any interest in looking at this direction for channel numbering, I'm happy to try to change hat I do so that it's more amenable to OpenVix use.
Huevos wrote:
Fri Aug 11, 2017 21:22
...
But anyway, for you guys, you only have one provider, so it is pretty simple to incorporate that one provider into enigma code, but here it would be considered a hack. And if you look on some of the European forums there a lot of people very against LCNs because they think it is "spoon feeding" and undermines the intellect of the users.

Australians seem to like channel numbers for some reason. Part of this may go back to the channel allocation practice in the early days of Australian TV broadcasting, where it was only metropolitan and the cities are far enough apart that each network was given the same broadcast channel in each city, and the commercial networks named themselves for their channel allocations: Seven, Nine and Ten. For the nhe national broadcasters, ABC was on channel 2 and SBS was simulcast on 0 and 28 (SBS was the first broadcaster to use UHF in Australia, but at the time there was relatively low market penetration of UHF-capable TV sets).

In the digital world, the broadcasters still advertise their channels by their LCN, for example in this announcement logo for 7flix (yes, still named after the old metropolitan analog broadcast channels!).

Many Beyonwiz users prefer to use the official LCNs for channel changing and would often also like to be able to regroup channels out of strict LCN order: for example ABC uses LCNs 2, 21, 22, .., and SBS uses , 3, 31, 32, ..., so if you use padding to achieve LCN-like numbering, you can't group all the ABC channels together in a bouquet, and then, say, all the SBS channels. Similarly for the other broadcasters.

I personally don't use LCNs: I watch nearly all our TV from recordings and change channel using either the bouquet list or the EPG. I think that memorising LCNs is an effort I can better expend elsewhere. On the Beyonwiz forum, there are both people who tend not to use LCNs and those who seem to want to use nothing else for channel changing. But I don't think I've seen anyone in the Beyonwiz forum who was actually negative about people using them.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Mon Jan 15, 2018 16:32

Hi Prl,

Do you have any updates on the status of this project?

Regards,
Ian.

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Mon Jan 15, 2018 16:57

IanSav wrote:
Mon Jan 15, 2018 16:32
...
Do you have any updates on the status of this project?
...

No, I've been quite busy with other stuff. In particular at the moment I'm having a lot of problems trying to do an OpenViX build for my T3, and without that, I can't test anything in the C++ code on OpenViX. And once it's working, my priorities are on the IMDb Search fixes, then a pending fix to Now/Next updates at startup without a network connection (it's been hanging awaiting acceptance in OpenViX for ages, but I actually want to change the way it's done before it gets merged upstream), then CRIDs . I've got another three git stashes that I'd like to push upstream before I even look at LCNs again.

I'm hoping, though, that the CRIDs work may make me some useful contacts that would help to get the LCN changes accepted upstream in OpenViX.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Mon Jan 15, 2018 18:02

Hi Prl,

There was no pressure or motive behind my enquiry. Another post lead to this thread and I was curious about what was happening. I am sure that lots of people, myself included, will appreciate the fruits of your efforts.

The situation at OpenViX is changing. There is an effort to make OpenViX more inter-operable with OpenPLi. Just as Beyonwiz takes many of its changes from OpenViX so too do OpenViX take many of their changes from OpenPLi. Just as PeterU tries to make merges with OpenViX easier so to OpenViX wish to make their merges with OpenPLi less arduous.

At this stage I do not perceive this to be a problem. To the contrary this could make getting features easier and faster to merge for all the related forks.

Regards,
Ian.

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Sat Sep 29, 2018 16:42

[Discussion moved from the topic where IanSav originally posted]
IanSav wrote:
Sat Sep 29, 2018 16:39
I am also trying to get some changes with regards to service naming and numbering. It is very early days yet for our efforts. These changes are being developed for OpenViX and perhaps OpenPLi. It was my hope that these changes would trickle down to Beyonwiz. However, I don't know if that will ever happen.

That sounds interesting. Could you give some more details or a link to the discussion?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Sat Sep 29, 2018 18:12

Hi Prl,

No public discussions as yet, I have been talking to IanB in person and Huevos via Skype. The new terrestrial scanning engine will be based on the existing OE-Alliance TerrestrialScan plugin. (I already have some adapted code, developed by Huevos, to make this plugin work in Australia.)

What I want to do is what I have been proposing for a very long time.

I want to add two LCN (or service numbers for those people scared of LCNs!) and two Service Names to the lamedb and lamedb5 files. The first LCN and Service Name pair is the information as received from the broadcaster. The second LCN and Service Name pair is the version of the LCN and Service Name data that is *ALWAYS* shown to the user and used within the UI. I will explain how these work next.

During the tuning process the first LCN and Service Name will be populated by any data retrievable from the received signal. If the data cannot be obtained or derived then some coded default policies can be applied. If there are any duplicates and the triplet is the same then the strongest signal is used and the duplicate discarded. If there are no duplicated LCNs or Service Names then the data from the first LCN and Service Name is simply copied into the second LCN and Service Name. If there are any duplicated LCNs or Service Names then the first pair retain the value as broadcast but the second fair are adjusted to remove any duplications. (In Australia this would typically mean that a duplicated LCN would have the weaker duplicate moved to the LCN 350 - 399 range. I trust that you will recognise OP-41 coming into play here.)

As mentioned before in all places the UI should be changed such that the second pair of LCN and Service Names should be shown to the user. Thus, for a user in Australia if there is a duplicate of a service for, say Channel 7 in Northern NSW and Southern Queensland, the stronger signal would be displayed as LCN-7 number while the weaker duplicate would display as LCN-350. I think this is enough information for what I mean but please ask if you want more.

Now that the service database has information for both LCNs and Service names we can now delete this information from bouquets. That is, the line number of the bouquet no longer represents the LCN of that service. That data can now be retrieved from the lamedb data. This would allow users to sort the order of any bouquet in *ANY* order yet the LCNs will remain as intended. The order in the file is no longer significant. Further there will no longer be any need for bouquet padding to force service numbering.

Now that bouquets are no longer magical, special line numbers based on position or special bouquets like Terrestrial TV LCN we can now add an options LCN and Service Name. If a bouquet has an LCN or Service Name defined that that LCN or Service Name will override the defaults and be used by that bouquet. This gives all users total control on how the services they place in a bouquet are displayed without needing to tamper with the internal data structures for those services.

At any point in the UI where a user can enter an LCN to select a service the system should be adjusted to check of the LCN is defined in the current bouquet and, if so, the service described by that LCN should be selected. If the LCN in the bouquet duplicates an LCN in the master lamebd database the number coded into the bouquet is the one to be used. If there are no override LCNs in the bouquet then the master lamedb database should be consulted to resolve the LCN, if a resolution is available. If the LCN is defined then jump to the nominated service if not then ignore the LCN selection. This process should not reset the currently selected bouquet. The EPG and CH+/- buttons will continue to select services from the currently selected bouquet.

The current ChannelSelection bouquet manager (MENU from within FAV) has options 8 for "Rename entry" and 9 for "Remove entry" it should gain a new option to "Renumber entry". This should allow complete user control of the order and data of any and every bouquet on their system.

A new UI will need to be created to manage the LCN and Service Names stored in the second pair of LCN and Service Name attributes of the master lamedb databases. The first pair can never be edited by the user as this is the data broadcast or calculated by the scanning algorithms.

One final point is that the LCN display must be selectable by the user. For countries and locations where LCNs are a dirty word the display of LCNs must be suppressed. For example, in Australia we would probably like to have the discovered LCNs displayed in the FAV RED (All) list but elsewhere the LCN display would be a definite no-no. The idea is that LCN data storage should be baked into the core system but be totally hidden for those that don't want the system to appear to have changed. That is, if LCN display setting is set to off then the UI should look exactly as it does now.

Have I provided enough information about what I propose? Have I missed anything? Can I expand or explain anything more?

Thoughts?

Regards,
Ian.
Last edited by IanSav on Sat Sep 29, 2018 18:17, edited 2 times in total.

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Sat Sep 29, 2018 18:23

IanSav wrote:
Sat Sep 29, 2018 18:12
What I want to do is what I have been proposing for a very long time.

I want to add two LCN (or service numbers for those people scared of LCNs!) and two Service Names to the lamedb and lamedb5 files. The first LCN and Service Name pair is the information as received from the broadcaster. The second LCN and Service Name pair is the version of the LCN and Service Name data that is *ALWAYS* shown to the user and used within the UI. I will explain how these work next.

I have already implemented much of the LCN part of that for Australia. I can resurrect the code and get it running again, and put it into a dev branch in my repository clone if that is useful for you, if on;y to look at another way of doing it. The LCN info goes into the lamedb* files in my implementation, too.

Detailed discussion might be better off in the developers area, perhaps in the existing "real LCNs" topic. I can easily detach the last couple of posts on this and move them there if you like.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Sat Sep 29, 2018 18:28

Hi Prl,

Yes, please move these posts as they are good fodder for future discussions.

Regards,
Ian.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Tue Oct 02, 2018 19:06

Hi,

After having some long discussions with Huevos I am thinking about turning this issue on its head and tackling this issue from the UI back.

The situation of using LCNs is more difficult in the context of satellite or cable services. I am not sure I have communicated my ideas well enough to Huevos but so far he is against some of the details of my proposal. To avoid these concerns I propose that a good start to addressing LCN issues would be to tackle how bouquets are handled / managed.

What I am proposing is to extricate the bouquet management code out of the ChannelSelection.py screen code into a function specific tool library. I propose the library be called "Tools/Bouquets.py". This code should support the creating, loading, editing, saving and deleting of bouquets. The library should also offer methods to return data from bouquets. The idea is to abstract the data in a bouquet from the files and structures within those files. For example, I would like to have a methods that can return the name of a service, its LCN, its triplet, the type of service, etc. This separation of format from data can allow the data file structure to change without affecting code that requires access to that data.

While the initial implementation should be to separate the code and offer a fully transparent change this will allow for future improvements. The first improvement could be to simplify the way that services are named and renamed. Rather than having a bouquet entry that has two components for a rename, one entry in the SERVICE line and another copy in a DESCRIPTION line the two elements could be combined into the single version in the SERVICE entry. As it is now, if there is no name provided in the SERVICE line then use the name defined in lamedb. If there is a name defined in the SERVICE line then it should be used in the UI. There should be methods to manage the name lookup and rename functions. A rename with a name of None should remove the custom name and revert to the name in lamedb.

The next improvement could be to add LCNs to the bouquet. This facility could be implemented to look for an LCN field in the SERVICE line and, if an LCN exists, return it as the service LCN. If an entry doesn't exist the the LCN can be derived from the line number in the file as it is now. It may be appropriate to look harvesting the positional LCN data and creating LCN fields as part of a load or migration process. Again methods can be provided to return the bouquet list in any format, padded or not padded, as required by existing code as well as all the expected LCN management requirements.

Once the file formats are separated from the data it should be significantly easier to maintain bouquets and provide further enhancements and/or changes as required in the future.

This proposal may not cover all possibilities but it is an attempt to prompt further ideas and discussions.

Thoughts?

EDIT: Unfortunately the forum security software does not allow me to use the # character in the bouquet line items. They have been removed to make this post acceptable but should remain in the file.

Regards,
Ian.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Tue Oct 02, 2018 19:20

Hi,

Before anyone raises this as an issue, yes I am well aware that changing bouquets will have an impact on OpenWebif. ;) I suggest that these changes could also be incorporated into OpenWebif. More to the point OpenWebif can be taught to use the new methods that would become avalable in the proposed bouquets.py tool.

Regards,
Ian.

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Wed Oct 03, 2018 09:53

IanSav wrote:
Tue Oct 02, 2018 19:06
The next improvement could be to add LCNs to the bouquet. This facility could be implemented to look for an LCN field in the SERVICE line and, if an LCN exists, return it as the service LCN. If an entry doesn't exist the the LCN can be derived from the line number in the file as it is now. It may be appropriate to look harvesting the positional LCN data and creating LCN fields as part of a load or migration process. Again methods can be provided to return the bouquet list in any format, padded or not padded, as required by existing code as well as all the expected LCN management requirements.

Changing the number of fields in a serviceref would require lots of code to be examined for potential problems.

My implementation of "real" LCNs puts both the original and remapped LCNs for a service in lamedb, with fallback to bouquet file SERVICE line number (but as a user switchable option).

I haven't looked in detail at the AutoBouquetsMaker code that constructs padded bouquets for satellite services (and I haven't looked at all for quite some time), but my impression is that LCNs from different satellites can overlap, so without some sort of remapping for that, you can get the same LCNs for completely different services in that environment.

I'm not convinced that user-editable LCNs are a great idea, anyway.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
adoxa
Wizard
Posts: 1490
Joined: Thu Feb 23, 2017 22:58
Location: CQ
Contact:

Re: Using LCNs for channel numbering in all bouquets

Post by adoxa » Wed Oct 03, 2018 15:42

I didn't want to mess with existing files, so my approach was to use the same name as the bouquet, appending .numbers. That file contains lines mapping a number to a service.

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Wed Oct 03, 2018 16:30

I really don't think that LCNs belong in bouquets. Is there any reason why it might be useful for the same service to have different LCNs in different bouquets?

I thought that inconsistencies like that were one reason for using "real" LCNs.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
adoxa
Wizard
Posts: 1490
Joined: Thu Feb 23, 2017 22:58
Location: CQ
Contact:

Re: Using LCNs for channel numbering in all bouquets

Post by adoxa » Wed Oct 03, 2018 16:41

prl wrote:
Wed Oct 03, 2018 16:30
I really don't think that LCNs belong in bouquets. Is there any reason why it might be useful for the same service to have different LCNs in different bouquets?
Not really, it just seemed the easiest way to get a custom number. Besides, it was only ever supposed to be temporary, until you released yours. Only you never did...

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Wed Oct 03, 2018 17:12

adoxa wrote:
Wed Oct 03, 2018 16:41
prl wrote:
Wed Oct 03, 2018 16:30
I really don't think that LCNs belong in bouquets. Is there any reason why it might be useful for the same service to have different LCNs in different bouquets?
Not really, it just seemed the easiest way to get a custom number. ...

My comment also applies to what IanSav is suggesting, though I think the way he's suggested implementing it is more problematic than what you implemented, since it appears that would change the text format of a serviceref.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Wed Oct 03, 2018 17:19

adoxa wrote:
Wed Oct 03, 2018 16:41
... it was only ever supposed to be temporary, until you released yours. Only you never did...

I have offered to update it and make it available on my repository clone if IanSav is interested. So far he hasn't indicated that he is.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Wed Oct 03, 2018 23:42

Hi Prl,
prl wrote:
Wed Oct 03, 2018 09:53
Changing the number of fields in a serviceref would require lots of code to be examined for potential problems.
Agreed. This is the benefit I seen in extracting this sort of code into a helper module that abstracts the physical data layout from the logical data.
prl wrote:
Wed Oct 03, 2018 09:53
My implementation of "real" LCNs puts both the original and remapped LCNs for a service in lamedb, with fallback to bouquet file SERVICE line number (but as a user switchable option).
This is what I proposed but there are complications when satellite or cable services are considered. The issue, as I understand it, is that satellite and cable services can have common services where a service with a single triplet is shared between different providers. Each provider can provide a list / index / bouquet of various services that can be made up with any number of these shared services. Each provider is free to bundle or repackage any of these shared services in any way they please. That can include assigning different LCNs to the same source service.
prl wrote:
Wed Oct 03, 2018 09:53
I haven't looked in detail at the AutoBouquetsMaker code that constructs padded bouquets for satellite services (and I haven't looked at all for quite some time), but my impression is that LCNs from different satellites can overlap, so without some sort of remapping for that, you can get the same LCNs for completely different services in that environment.
As I tried to explain above this is absolutely correct. This, I believe, is the primary reason for objection to saving LCNs in the lamedb files. One thought I had was that perhaps the original and remapped LCNs could be an ordered list.

The current mechanism of scanning is for every provider package to trigger the creation of a bouquet with the services positions in that provider's LCN order (assuming that that provider is offering LCN data for their package). Every such package can get its own bouquet and the services, even if they are common, can be allocated the LCNs appropriate for that provider.
prl wrote:
Wed Oct 03, 2018 09:53
I'm not convinced that user-editable LCNs are a great idea, anyway.
I would like to see this feature added so that any user can be free to curate their own bouquets with any numbers they want for ANY services or types of services (services could be terrestrial, cable, satellite or IP streams) they want and order those services in any order they like without regard to the order dictating the LCN. Then while the bouquet is active they can enter their assigned number directly into the live TV interface to select the service of their choice.

Regards,
Ian.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Wed Oct 03, 2018 23:52

Hi Adoxa,
adoxa wrote:
Wed Oct 03, 2018 15:42
I didn't want to mess with existing files, so my approach was to use the same name as the bouquet, appending .numbers. That file contains lines mapping a number to a service.
This is the problem with the efforts of the past. The lamedb5 file was created by an attempt to clean up lamedb that didn't get completed. The lcndb is a Beyonwiz hack / patch trying to address missing information from the lamedb file. We need to stop hacking at the problem and start crafting a considered and sustainable solution that can properly integrate the needs of all the service types for now and into the future.

For example, the signal strength data from lcndb should have been added to the transponder section of the lamedb files. Similarly allowances for LCNs could / should be added to the services data of the lamedb files. The data structure used for LCNs needs to account for the possible replications in the cable and satellite scenarios.

Regards,
Ian.
Last edited by IanSav on Thu Oct 04, 2018 00:13, edited 1 time in total.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Wed Oct 03, 2018 23:55

Hi Prl,
prl wrote:
Wed Oct 03, 2018 16:30
I really don't think that LCNs belong in bouquets. Is there any reason why it might be useful for the same service to have different LCNs in different bouquets?
I hope that I gave enough of an explanation above. If mot them please ask. I, or hopefully Huevos, can offer further explanation.
prl wrote:
Wed Oct 03, 2018 16:30
I thought that inconsistencies like that were one reason for using "real" LCNs.
So did I. Then Huevos explained how cable and satellite services worked and the simple solution I envisioned became insufficient. To get any changes accepted globally we need to find solutions for all the scenarios.

Regards,
Ian.
Last edited by IanSav on Thu Oct 04, 2018 00:14, edited 1 time in total.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: Using LCNs for channel numbering in all bouquets

Post by IanSav » Thu Oct 04, 2018 00:09

Hi Prl,

I am definitely interested in your efforts but with the new information from Huevos we need to expand on, and improve, the proposal.

I also need to point out that this is an area of the code with which I am not at all familiar. While I am happy to contribute ideas, effort this really needs someone with a better handle of the issues and the coding involved to design and coordinate the efforts. (I also have the issue that my config / ConfigList / Setup / etc refactor efforts are not progressing due to all the disruptions to that development process.)

I don't think Huevos is particularly keen to develop the proposals or code as all the situations he needs to support are already supported in the existing code. The Australian requirements do not match the European requirements so this will require an Australian effort with coordination with Huevos and any other interested parties. If this is done well then there could be improvements and enhancements available to all users.

Regards,
Ian.

IanB
Wizard
Posts: 1550
Joined: Sat Jan 24, 2009 14:04
Location: Melbourne

Re: Using LCNs for channel numbering in all bouquets

Post by IanB » Thu Oct 04, 2018 09:36

I'm not convinced that user-editable LCNs are a great idea, anyway.
You need at least an API for editable LCNs to do the 350 quick step shuffle dance, whether or how you expose it to the user GUI is a different matter.

As for IanSavs'/PRL's idea for just storing 2 LCN's, broadcast and active, is a somewhat limited view of the world.

First up stop trying to sell LCN to the rest of the Enigma world, they are strongly biased/bigoted against the term "LCN". Sell it as some generic term like "Quick/Fast/Immediate Access/Select Number/Favourite" or whatever.

Work on getting the "Quick Access Number" or numbers (plural) attached to the service information so you have a default number(s) to service association (For AU we get our LCN's). Bouquets number can (optionally) override.

So if the user types 20 they optionally get the 20th entry service of the current bouquet (or whatever bouquet in alternate numbering mode), if there is none, then they optionally get the service with the global "Quick Access Number", if there is none then do nothing.

Above is the what you have as the active LCN element.

As for the broadcast LCN element, again insular thinking. Think global! Aim to get all the information available in the NIT, BAT, whatever tables available in real time. This information should of course get saved to a lamedb.

Once available it's just python code to utilise and manipulate or ignore that information.

Choose your battles strategically! Get the number select, get the information made available, do AU lcn's.

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Thu Oct 04, 2018 11:11

IanB wrote:
Thu Oct 04, 2018 09:36
I'm not convinced that user-editable LCNs are a great idea, anyway.
You need at least an API for editable LCNs to do the 350 quick step shuffle dance, whether or how you expose it to the user GUI is a different matter.

The code I wrote does the automatic re-assignment of duplicate LCNs up to the 350+ range, but has no UI for changing either the original or remapped LCN, but it would be possible to add one without modifying the lower-level LCN support that I wrote.
IanB wrote:
Thu Oct 04, 2018 09:36
First up stop trying to sell LCN to the rest of the Enigma world, they are strongly biased/bigoted against the term "LCN". Sell it as some generic term like "Quick/Fast/Immediate Access/Select Number/Favourite" or whatever.

My understanding is that the term LCN and the ways it's implemented in Australian DVB-T is lifted from European standards: "The Australian specification, while based on the original development of the Logical Channel Descriptor by the UK DTG, has variations and extensions in its implementation similar to its use in Europe, such as the NorDig specification". [FreeTV OP 41 - LCN Descriptor]

And "The UK Digital TV Group has claimed copyright of the use of the Logical Channel Descriptor and has granted approval for its use in Australia." [ibid]

It's odd that the Europeans should object to nomenclature that they invented.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Thu Oct 04, 2018 11:16

IanSav wrote:
Thu Oct 04, 2018 00:09
I am definitely interested in your efforts but with the new information from Huevos we need to expand on, and improve, the proposal.

I'll make my LCN code available sometime over the next few days.
IanSav wrote:
Thu Oct 04, 2018 00:09
I also need to point out that this is an area of the code with which I am not at all familiar. While I am happy to contribute ideas, effort this really needs someone with a better handle of the issues and the coding involved to design and coordinate the efforts. (I also have the issue that my config / ConfigList / Setup / etc refactor efforts are not progressing due to all the disruptions to that development process.)

I don't think Huevos is particularly keen to develop the proposals or code as all the situations he needs to support are already supported in the existing code. The Australian requirements do not match the European requirements so this will require an Australian effort with coordination with Huevos and any other interested parties. If this is done well then there could be improvements and enhancements available to all users.

Because I'm not a party to the discussions, I really don't know what that means in any practical sense.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32709
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: Using LCNs for channel numbering in all bouquets

Post by prl » Mon Oct 08, 2018 10:23

I've commited an Lcns-dev development/experimental branch to my clone of the enigma2 repository.

From the commit notes:
  • Saves broadcast LCN, (re)assigned LCN and signal strength for a service in the services table of eDVBDB, and in the "l", "L" and "s" tags for each service in lamedb & lamedb5.
  • No longer uses lcndb (and deletes it on service scan).
  • Is switchable between using padding or 'real' LCNs to control the display of channel numbers (MENU>Setup>TV>Channel selection>LCN numbering mode).
  • Switching between the two methods does not change the padding in the bouquets, but there is commented-out code that can remove padding from Terrestrial TV LCN when it is not needed and restore it when it is.
  • The code as-is is intended for use in Australian DVB-T. It may work in other circumstances. In particular, it doesn't deal with LCNs that are duplicated in different namespaces (e.g. LCNs from two different satellites).
  • When in "real LCNs" mode, the LCN for HDMI IN on devices that have it is set to 0 ("no LCN" I haven't yet worked how best to generate an "LCN" for HDMI IN.
If people would like to try the code and can't do a build themselves, I can post patches for any required architecture.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

Post Reply

Return to “Developers Community”