Using LCNs for channel numbering in all bouquets

[IanSav]

Hi Huevos,

By the way people in the UK get a message that their IP is banned when visiting this forum. Is that deliberate?

Yes. We were getting significant SPAM from offshore accounts so a geo-location block was put in place. Please PM your IP address or an address range to Gully or Prl and they will allow you and any of the OpenViX team members in directly.

Regards,
Ian.

[prl]

... Please PM your IP address or an address range to Gully or Prl and they will allow you and any of the OpenViX team members in directly. ...

I'd happily do it if I could, but I don't have the access level to do it.

[Gully]

... Please PM your IP address or an address range to Gully or Prl and they will allow you and any of the OpenViX team members in directly. ...

I'd happily do it if I could, but I don't have the access level to do it.

Happy to do what I can and should have the access.

[IanB]

One thing I have noticed in the wider Enigma2 community is a fairly strong bigotry regarding the term "LCN".

It seems to me that there is a small amount of cutting ones nose off to spite ones face here. If I understand correctly, bouquet usage just inevitably leads to every active entry getting a number, either globally unique or if alternate numbering is enabled, locally unique starting from 1 in each bouquet. And with artificial padding entries we sort of have a way of influencing how those numbers fall. Effectively Logical Channel Numbers, LCNs.

Perhaps finding another term for the concept may help those with an aversion to the concept of LCN to get on board for the greater good. Something like Bouquet Index or Quick/Fast/Direct Select or ....

Australian LCN usage is really only a special use case of the general numbering case and only needs a reliable method to control how entry numbers in bouquets are allocated those numbers.

Any thoughts?

[raymondjpg]

Australian LCN usage is really only a special use case of the general numbering case and only needs a reliable method to control how entry numbers in bouquets are allocated those numbers.

I only have access to Australian TV channels but TSReader delivers what they term "Logical channel numbers". Are you saying that is a "special use case" of the term?

(btw over the years I have become used to the "Australian" use of the term and prefer to see my channel lineup according to these LCNs. I am not buying in to any controversy regarding use of the term by the "Enigma2 community".)

[prl]

... Australian LCN usage is really only a special use case of the general numbering case and only needs a reliable method to control how entry numbers in bouquets are allocated those numbers.

Australian LCN usage is pretty much copied from the UK DVB-T LCN usage (though distributed in a slightly different way, as Huevos has detailed). One of the things that AutoBouquetsMaker does is attach LCNs from a variety of tables in the broadcast stream and attach them to tuples along with the service reference information and the bouquet id. That doesn't seem to be expressing any sort of antipathy to broadcast LCNs.

Any thoughts?

The idea of using LCNs in at least the Australian case is to give the same service the same number in any bouquet it appears in. I don't know, but I suspect that that's a slightly different goal from what AutoBouquetsMaker is used to achieve.

[prl]

...
I only have access to Australian TV channels but TSReader delivers what they term "Logical channel numbers". Are you saying that is a "special use case" of the term?

(btw over the years I have become used to the "Australian" use of the term and prefer to see my channel lineup according to these LCNs. I am not buying in to any controversy regarding use of the term by the "Enigma2 community".)

According to AS4599.1:

4.2.1 Introduction

This Clause contains the Australian modifications to ETSI EN 300 468 [20]. The Australian implementation of the logical channel descriptor is used with approval; copyright is vested in the UK Digital Television Group. Further information on Australian implementation is available in a CTVA operational practice (OP).

I'm fairly sure that CTVA is an earlier name for FreeTV. But the nomenclature "logical channel descriptor" is taken from the UK Digital Television Group.

The dvbsi++ library used by enigma2 has classes for decoding LogicalChannelDescriptor and LogicalChannel entities. The LogicalChannel has a getLogicalChannelNumber() method. They decode Logical Channel information in the form described by UK Digital Television Group.

The source code for the DVB scanner in AutoBouquetsMaker is littered with comments referring to LCNs and variables with "lcn" as part of their name. One of the instances of that is the decoding of the LCN Descriptor defined by the UK Digital Television Group.

I don't see any suggestion in any of those places where the term "Logical Channel Number" is being used in different way from which we use it in Australia.

However, quite early on in this discussion, I mentioned the need to manage bouquets that have both services with LCNs defined in their broadcast streams and services that don't have them. There's probably also a need to manage duplicatLCNs that occur for reasons other than those described in FreeTV's OP-41.

[IanSav]

Hi Prl,

However, quite early on in this discussion, I mentioned the need to manage bouquets that have both services with LCNs defined in their broadcast streams and services that don't have them. There's probably also a need to manage duplicatLCNs that occur for reasons other than those described in FreeTV's OP-41.

I thought I covered all this in my proposal outline. If not please explain what I missed.

Regards,
Ian.

[prl]

Hi Prl,

However, quite early on in this discussion, I mentioned the need to manage bouquets that have both services with LCNs defined in their broadcast streams and services that don't have them. There's probably also a need to manage duplicatLCNs that occur for reasons other than those described in FreeTV's OP-41.

I thought I covered all this in my proposal outline. If not please explain what I missed.
...

"For areas where LCN numbers are created based on different ranges for different genres etc then the local rules for numbering should be followed" doesn't describe enough detail to be implemented.

"If no LCN is broadcast then use a sequential number starting at 1" has to make sure that it doesn't collide with broadcast LCNs, and so it can't strictly be sequential.

The present Beyonwiz IniLCNScanner has some rules for remapping Italian LCNs, but I'm not sure why they are needed. They seem to be to group for genres, but it's highly dependent on how the LCNs are assigned to services:

Code: Select all

	<ruleset name="Italia">
		<!-- "renumber" rules are applied sequentially keeping the original order -->
		<rule type="renumber" range="0-99999">value * 10</rule>
		<rule type="renumber" range="1010-1990">value - 995</rule>
		<rule type="renumber" range="2010-2990">value - 1995</rule>
		<rule type="renumber" range="5010-5990">value - 5005</rule>
		<rule type="marker" position="0">Intrattenimento</rule>
		<rule type="marker" position="395">Bambini e ragazzi</rule>
		<rule type="marker" position="475">Informazione e cultura</rule>
		<rule type="marker" position="565">Sport</rule>
		<rule type="marker" position="655">Musica</rule>
		<rule type="marker" position="2995">Pay TV</rule>
		<rule type="marker" position="7995">Servizi On Demand</rule> 
		<rule type="marker" position="166350">Duplicati</rule>
	</ruleset>

I'm intending for numbering based on broadcast LCNs to be an option. If it's disabled, than any existing bouquet generators like IniLCNScanner and AutoBouquetsMaker can still be used to generate numbering using filling.

[IanB]

Australian LCN usage is really only a special use case of the general numbering case and only needs a reliable method to control how entry numbers in bouquets are allocated those numbers.

I only have access to Australian TV channels but TSReader delivers what they term "Logical channel numbers". Are you saying that is a "special use case" of the term?

Not the term, but the logical usage of the numbers.

Australian LCN usage, i.e. the numbering used, is just a special use case of the general bouquet numbering case.

[IanSav]

Hi Prl,

"For areas where LCN numbers are created based on different ranges for different genres etc then the local rules for numbering should be followed" doesn't describe enough detail to be implemented.

If I use AutoBouquetMaker as an example here are the ranges for Freeview UK:

Code: Select all

	<sections>
		<section number="1">Entertainment</section>
		<section number="100">High Definition</section>
		<section number="120">Children</section>
		<section number="130">News</section>		
		<section number="170">Adult</section>
		<section number="601">BBC Interactive</section>
	</sections>

Here are the ranges for Horizon IE:

Code: Select all

	<sections>
	        <section number="100">Entertainment</section>
	        <section number="200">News and Documentaries</section>
	        <section number="300">Movies</section>
	        <section number="400">Sports</section>
	        <section number="500">Lifestyle</section>
	        <section number="600">Kids</section>
	        <section number="700">Music</section>
	        <section number="800">Specialist</section>
	        <section number="858">Adult</section>
	</sections>

Here are the ranges for Virgin (UK):

Code: Select all

	<sections>
		<section number="100">Entertainment</section>
		<section number="245">Factual</section>
		<section number="278">Lifestyle</section>
		<section number="300">Music</section>
		<section number="400">Movies</section>
		<section number="500">Sports</section>
		<section number="601">News</section>
		<section number="700">Kids</section>
		<section number="740">Shopping</section>
		<section number="801">International</section>
		<section number="851">Audio Description</section>
		<section number="861">Local</section>
		<section number="969">Adult</section>
		<section number="990">BBC Interactive</section>
		<section number="997">Information</section>
		<section number="1000">Red button</section>
		<section number="1020">BT Sport Interactive</section>
	</sections>

Foxtel in Australia is another example that can be considered with its channels allocated amongst various groupings..

I think that if the LCN is broadcast then it should be checked against a table of LCNs and genres to determine what special bouquets, if any, the channel should be added. If no special bouquet is nominated then use a catch-all called "All Channels" as the target bouquet. If no LCN is supplied then check the genre, if available, and allocate the first free LCN in the appropriate range.

The valid ranges can be held in an XML file. The appropriate table can be selected by using something like the broadcast region or so other appropriate key extracted from the broadcast stream.

For this proposal we could adapt the XML and use a sections entry like:

Code: Select all

	<sections>
		<section number="1" type="All" bouquet="All Channels" />
		<section number="100" type="NoLCN" bouquet="All Channels" />
		<section number="350" type="Duplicated" bouquet="All Channels" />
	</sections>

This would put all channels in the "All Channels" bouquet as per their allocated LCN. Any channels without an LCN (not currently possible) would start at 200. Any duplicated LCNs would be allocated the first number in the "Duplicated" pool. In this example the genre area is not used as Australia doesn't appear to have a reliable way of identifying the genre of a channel, only the programs on the channel.

If no LCN's and no genres are present in the broadcast signal, or there are no specific instructions in the XML file. then the current mechanism of allocating channels an arbitrary number starting with 1 and increasing with each new channel found.

"If no LCN is broadcast then use a sequential number starting at 1" has to make sure that it doesn't collide with broadcast LCNs, and so it can't strictly be sequential.

As a thought I would collect all the channels that don't have an LCN in a list and then wait until the scan is complete. Then go though the completed scan table and slot in all the channels without LCNs. Use the first available slot in the appropriate groupings according to genre (if available) and "All Channels".

The present Beyonwiz IniLCNScanner has some rules for remapping Italian LCNs, but I'm not sure why they are needed. They seem to be to group for genres, but it's highly dependent on how the LCNs are assigned to services:

Code: Select all

	<ruleset name="Italia">
		<!-- "renumber" rules are applied sequentially keeping the original order -->
		<rule type="renumber" range="0-99999">value * 10</rule>
		<rule type="renumber" range="1010-1990">value - 995</rule>
		<rule type="renumber" range="2010-2990">value - 1995</rule>
		<rule type="renumber" range="5010-5990">value - 5005</rule>
		<rule type="marker" position="0">Intrattenimento</rule>
		<rule type="marker" position="395">Bambini e ragazzi</rule>
		<rule type="marker" position="475">Informazione e cultura</rule>
		<rule type="marker" position="565">Sport</rule>
		<rule type="marker" position="655">Musica</rule>
		<rule type="marker" position="2995">Pay TV</rule>
		<rule type="marker" position="7995">Servizi On Demand</rule> 
		<rule type="marker" position="166350">Duplicati</rule>
	</ruleset>

I suspect this works or is intended to work along the lines of AutoBouquetMaker.

I'm intending for numbering based on broadcast LCNs to be an option. If it's disabled, than any existing bouquet generators like IniLCNScanner and AutoBouquetsMaker can still be used to generate numbering using filling.

IniLCNScannel is not part of OpenViX. OpenViX uses AutoBouquetMaker which is very happy to exist and operate together with any other LCN management system.

Regards,
Ian.

[raymondjpg]

Australian LCN usage is really only a special use case of the general numbering case and only needs a reliable method to control how entry numbers in bouquets are allocated those numbers.

I only have access to Australian TV channels but TSReader delivers what they term "Logical channel numbers". Are you saying that is a "special use case" of the term?

Not the term, but the logical usage of the numbers.

Australian LCN usage, i.e. the numbering used, is just a special use case of the general bouquet numbering case.

Thank you for the clarification. It is the LCN numbers that I am used to and would prefer to see in channel lineups and use for channel selection.

[IanSav]

Hi Prl,

The strategies in my previous post are a suggestion only. I haven't fully considered the data available or the code complexity. I wanted to offer some suggestions to feed the thought engine in the hope of finding a workable solution for the proposal.

Regards,
Ian.

[IanB]

Any thoughts?

The idea of using LCNs in at least the Australian case is to give the same service the same number in any bouquet it appears in. I don't know, but I suspect that that's a slightly different goal from what AutoBouquetsMaker is used to achieve.

Hand generating bouquets has always been able to mostly achieve that goal. However the tools and addon's for enigma2 are pretty weak when it comes to preserving the desired numbering and/or even achieving it in the first place. I guess you would say they they are padding entry hostile (or ignorant).

I say mostly because to achieve the same number range in each bouquet you need to enable "alternate numbering". And with that you can only enter numbers that actually exist in the current bouquet. e.g I run a hand edited stripped copy of the Terrestrial Bouquet without the shopping and racing dross. With that bouquet current you can never enter 78 and get to Racing.com. Entering 78 only works when the full Terrestrial bouquet is current.

And without "alternate numbering" the default Terrestrial bouquet owns the 1 to ~200/350+ number range. So all other bouquets end up with non ideal numbering. So I guess ultimately we are going to need an "alternate alternate numbering" mode where numbers can be made to map through to a master bouquet or some sort of implied bouquet hierarchy.

And yes Huevos is one of the good guys and his recent developments in AutoBouquetsMaker are becoming quite Australian LCN friendly.

[prl]

Australian LCN usage is really only a special use case of the general numbering case and only needs a reliable method to control how entry numbers in bouquets are allocated those numbers.

I only have access to Australian TV channels but TSReader delivers what they term "Logical channel numbers". Are you saying that is a "special use case" of the term?

Not the term, but the logical usage of the numbers.

Australian LCN usage, i.e. the numbering used, is just a special use case of the general bouquet numbering case.

Not at all. In bouquet numbering, the same service can have different numberings in different bouquets. In fact, if "Alternative numbering mode" is off, each occurrence of the same service in a bouquet must have a different number. That isn't so for LCNs in Australia after duplicates have been removed as in OP-41.

LCN numbering is per service (per service entry in the lamedb file, and per service entry in eDVBDB, and per service in the lcndb file), while bouquet numbering is per service reference in bouquets.

[prl]

...
And without "alternate numbering" the default Terrestrial bouquet owns the 1 to ~200/350+ number range. So all other bouquets end up with non ideal numbering. So I guess ultimately we are going to need an "alternate alternate numbering" mode where numbers can be made to map through to a master bouquet or some sort of implied bouquet hierarchy. ...

That is true only if the Terrestrial TV LCN bouquet is the first bouquet in the bouquets list. The list order can be changed in the UI by using the "move" function in the BLUE Favourites screen in the Channel Selection screens.

The greatest weakness of padding-based attempts to emulate LCNs is that the bouquets necessarily have to be in LCN order to have LCN numbering. See the example of how that can be freed up using real LCN numbering in my next post, where services are grouped by broadcaster, and LCNs preserved.

[prl]

Here's an example of true LCN numbering applied to a Favourites bouquet. The bouquet is grouped by broadcaster, SD services first, then HD. The broadcast LCN numbering is preserved, which isn't possible with padding-based "LCN"s.

This is an implementation, not a mockup, though the current implementation is Australian-only, doesn't yet handle duplicates OP-41 style and doesn't assign a fake LCN to the HDMI IN. However, none of those things is difficult to do from the current code state.

The lamedb entries look like:

Code: Select all

0211:eeee0000:0211:1010:1:0:0
ABC
p:ABC,c:000200,c:01028a,c:020240,c:030080,c:090000,l:2

The "l:2" is the service's broadcast LCN. If it had been reassigned because it was a duplicate, it would look like:

Code: Select all

0211:eeee0000:0211:1010:1:0:0
ABC
p:ABC,c:000200,c:01028a,c:020240,c:030080,c:090000,l:2,L:350

[IanB]

LCN numbering is per service (per service entry in the lamedb file, and per service entry in eDVBDB, and per service in the lcndb file), while bouquet numbering is per service reference in bouquets.

Yes, and that is a foreign concept for enigma2 and the those developers that suffer from the LCM bigotry.

Sure it's a surprisingly trivial code change to make number entry work the Australian LCN way, but for sure you would end up with that work on an orphaned fork.

[prl]

... Sure it's a surprisingly trivial code change to make number entry work the Australian LCN way, but for sure you would end up with that work on an orphaned fork.

That's why it's always been intended at a option. And currently works that way.

[IanSav]

Hi Prl,

Your current progress is looking good.

I hope that your efforts will not be isolated to Australia only. This may well find use in the UK and a few other places.

Mind you, those areas that don't use or want LCNs really won't care if LCNs are assigned during a scan. They would probably run with LCNs hidden in the UI anyway.

Regards,
Ian.

[Huevos]

Don't think about changing name from LCN. LCN is what they are called in the SI tables. Just ignore the snobbery about this. Some people don't want their bouquets arranged according to the broadcaster's numbering scheme and others do. Most resistence comes from people whose broadcasters don't offer LCN at all. And from people who are too "intellectual" to allow their channels to be auto sorted.

BTW, Ian, did you test the 6 xml files I sent you for Melbourne?

[IanSav]

Hi Huevos,

BTW, Ian, did you test the 6 xml files I sent you for Melbourne?

The xml files worked but I couldn't get the changed code for AutoBouquetMaker to run. It crashed. Without the change RACING.COM was still flagged as a HD channel.

I have become a little side tracked preparing, testing and submitting the OpenViX version of my date / time formatting code. I will look at the error in AutoBouquetMaker and get back to you ASAP.

Regards,
Ian.

[Huevos]

Those files are testing and working across several OpenViX builds. I'll update your image.

[IanSav]

Hi Huevos,

I have made a small error in my feedback report. Not only was LCN-78 "RACING.COM" classed as a HD channel when it isn't, LCN-30 "SBS HD" was not classed as HD when it is.

On the good news front our newest HD channel LCN-20 "ABC HD" that started today was correctly detected as a HD channel.

I also found why your code change did not work. I missed one of the new files from the commit you asked my to implement.

Regards,
Ian.

[IanSav]

Hi Huevos,

Okay, I have now correctly implemented the commit you referenced in you PM and AutoBouquetMaker works without crashing. Sorry for getting the patch wrong.

With the new code in place "RACING.COM" is no longer listed as a HD channel though "SBS HD" is still not detected as HD. Would you like a new SI capture of SBS?

I have attached a modified version of the Australian master terrestrial XML file. This is based on the normal version maintained by Prl but modified by IanB to reflect the 7 groups or regions of channels that cover all of Australia with minimal scanning of channels that aren't used in the region. IanB's data is at the end of the file. IanB may want to explain this a little better.

I thought this file may be helpful for you to see as it shows all the transmitter sites and the areas that they cover across all of Australia. The data I sent you was only for what I can receive from my location in Melbourne using the Mt Dandenong transmitter.

I was trying to create ABM provider files such that you can select "Australia" for the ABM scan and then nominate the area you are in to run a scan of only the channels in your area. Perhaps with this terrestrial data you can better complete the provider files for Australia.

Regards,
Ian.

[IanSav]

Hi Huevos,

To save time I have created a new SI PIDs recording of SBS in case there is a problem with the previous copy.

You can download the new version from http://users.tpg.com.au/iansav/MelbAusSBSDVB-SI-TS.zip.

Please let me know when you have all the recordings from my website so I can delete all these recordings and recover my website quota.

Regards,
Ian.

[Huevos]

Website quota? What's that? File is only 1 MB anyway.

My websites are on my NAS, and connected to the internet over my 300 Gb domestic connection.

[Huevos]

SBS HD is listed wrong in the SI tables. So it is a broadcaster error.

[prl]

SBS HD is listed wrong in the SI tables. So it is a broadcaster error.

Service type 1 is used for all Australian DVB-T services that use MPEG2 encoding, whether SD or HD. SBS isn't the only broadcaster to do this.

[prl]

Don't think about changing name from LCN.

I had no intention of changing it

LCN is what they are called in the SI tables. Just ignore the snobbery about this. Some people don't want their bouquets arranged according to the broadcaster's numbering scheme and others do. Most resistence comes from people whose broadcasters don't offer LCN at all. And from people who are too "intellectual" to allow their channels to be auto sorted. ...

If someone wants LCN numbering in bouquets, but has bouquets where some services have LCNs and some don't, how do you think the services without LCNs should be numbered? They could be left with LCN 0, which then won't be displayed, or they could start numbering from above the highest LCN used (the highest one used in the bouquet when Alternative numbering mode is enabled, or the highest LCN in eDVBDB where Alternative numbering mode is disabled).

Or do you have any other suggestions?

[IanSav]

Hi,

While analysing the SBS signal I noted a few other anomalies. SBS HD has lost "SBS" as its broadcaster and a few channel have lost their "eng" language flag.

I have contacted the SBS Broadcast department to report the problem. The recording message service indicated that I would receive a call back regarding my report. I will update the thread if/when I learn more.

Regards,
Ian.

[IanSav]

Hi,

SBS is working on some nice improvements but as a result a few things broke. I have provided information about the errors I noted and they are now being addressed.

Regards,
Ian.

[Huevos]

Service type 1 is used for all Australian DVB-T services that use MPEG2 encoding, whether SD or HD. SBS isn't the only broadcaster to do this.

But it is wrong though. Type 1 should only be used for MPEG2, SD services. MPEG2 HD services are type 17 (0x11) according to the standard.

[IanSav]

Hi Huevos,

Service type 1 is used for all Australian DVB-T services that use MPEG2 encoding, whether SD or HD. SBS isn't the only broadcaster to do this.

But it is wrong though. Type 1 should only be used for MPEG2, SD services. MPEG2 HD services are type 17 (0x11) according to the standard.

Thank you for this information. I will run it by my SBS contact and seek his advice.

Regards,
Ian.

[Huevos]

In other providers we work around things like this with hacks. For example:
https://github.com/oe-alliance/AutoBouq ... t.xml#L106

[Huevos]

If someone wants LCN numbering in bouquets, but has bouquets where some services have LCNs and some don't, how do you think the services without LCNs should be numbered?

Our scans are different because the majority only come from one transport stream.

Anyway, for example, in the case of Sky UK we add them to the end of the list and put these channels in alphabetical order.

But that is just a standard built in option. There are plenty of ways to customize too.

[IanSav]

Hi All,

I have had an update from SBS Technical department. The errors I reported have been acknowledged but not classed as mission critical. The corrections will need to be implemented by the SBS subcontractor and will be slipped in as time and resources present themselves.

This should mean that the fixes will be delivered when SBS moves to dynamic bandwidth allocation early next year or when they move SBS HD to H.264 and Full HD as planned between March and June 2017.

Regards,
Ian.

[Grumpy_Geoff]

... or when they move SBS HD to H.264 and Full HD as planned between March and June 2017.

Hi Ian,

SBS HD changed to 1920x1080i in the last few weeks.
http://www20.sbs.com.au/transmissions/index.php

Cheers
Geoff

[MrQuade]

SBS HD changed to 1920x1080i in the last few weeks.
http://www20.sbs.com.au/transmissions/index.php

Still MPEG2 for now though :-/. The quality has been awful trying to stuff the extra resolution down the same size pipe .

[IanSav]

Hi Geoff,

That is interesting. I got the impression that wouldn't happen until they had the dynamic compression sorted out. The new head end gear is installed so perhaps they are starting the new changes earlier.

From what MrQuade posted it sounds like the fixed compression is still in place. Hopefully they will get things sorted out soon.

Regards,
Ian.

[IanSav]

Hi,

Apologies for neglecting to update this thread in a timely manner.

SBS has completed its migration to its new broadcast line up and parameters.

Each LCN now correctly identifies the signal on that LCN. SBS now has two MPEG4 HD channels (Service Type (0x19), four MPEG2 SD channels (Service Type 0x01) and four MPEG2 radio channels (Service Type 0x02).

I hope this update might inspire further discussion and action on the topic of this thread.

Regards,
Ian.

[adoxa]

I came up with two methods to use LCNs.

The first relies on multiple bouquets and "Terrestrial TV LCN" being first. If the number isn't found in the current bouquet, but is found in the first bouquet (i.e. the LCN), map that back to the number in the current bouquet (if it exists, otherwise it will switch bouquets as usual). This means the low-numbered LCNs will probably not be available, due to being in the current bouquet (being regional, that only affects 7 for me, but I guess metropolitan viewers will have a problem with Network 10). It also still displays the bouquet number, not the LCN. Note this is for 16.1; I think it'll work in 17.5, you'll just miss prl's fixed recording marks.

lcn1.zip

(56.76 KiB) Downloaded 89 times

bouquet-num.txt

(1.56 KiB) Downloaded 85 times

The second uses entirely customisable numbers (albeit with no interface, requiring a file to be manually edited), with a plugin (source) to convert Favourites to LCN. This solves all the problems of the first method. (It also means that "Terrestrial TV LCN" can be done without padding.) Unfortunately, it needs to be done in the binary; I've only supplied 16.1 T2.

lcn2.zip

(1000.04 KiB) Downloaded 83 times

numbers.txt

(1.84 KiB) Downloaded 84 times

To install: browse to the directory and run "setup.sh" (this will backup the existing file, then replace it).
To remove: run "setup.sh" again (this will restore the backup).
To make permanent: browse to the directory, delete "testing" and run "setup.sh" (this will delete the backup).

[prl]

I have already coded almost everything that's needed to do LCN numbering "right" (IMO). That is, being able to optionally have LCN numbering in all bouquets and not requiring any particular order in the bouquet to make it work. Editing the LCNs would probably also be possible, but I'm not sure there's much of a requirement for it.

It's just been on ice for a while. I was hoping to be able to submit it upstream to OpenViX, but I don't think that what would work in Australia would work all that well in European areas that use LCNs (like the UK).

[IanSav]

Hi Adoxa,

While I applaud the ideas and the effort, I don't think a partial / conditional installation will be worth the effort. It is most unlikely to ever be accepted into any of the official builds.

I would like to see Prl's implementation to see how it works and what we can suggest to get it over the line for adoption in the OpenViX and the wider Enigma2 community.

The good thing is that many markets don't use or care about LCNs at all. For those people it doesn't matter how LCNs are changed as they don't use them or see them. Those few places that do use LCNs need to be at least as functional as they are currently. Hopefully they will see LCNs as improved and we can get acceptance.

By the way, if LCNs become stable and more predictable I can envision some users who don't / won't use LCNs may considering to use them. If you have access to hundred or thousands of channels you may find the unwieldy range of poorly assigned LCNs unhelpful. If you can assign selected LCNs to all your favourite channels you may well find that direct channel selection by a LCN may be a much more interesting proposition.

As soon as Prl commits his code and/or provides functional information we can see what is provided and what may be needed to get this more widely accepted.

Regards,
Ian.

[prl]

UK services carry LCN data in ways that I can't test on Australian broadcasts.

If what I've done is accepted by OpenViX, it will need to be adapted by the OpenViX devs for their conditions.

[IanSav]

Hi Prl,

Hopefully Huevos can and will offer his expertise and support to make the localised corrections for us so that the change will work for OpenViX and our Beyonwiz derivative.

Regards,
Ian.

[prl]

...
Hopefully Huevos can and will offer his expertise and support to make the localised corrections for us so that the change will work for OpenViX and our Beyonwiz derivative.
...

That can only be done by incorporating my changes into an OpenViX branch (probably not even the Dev branch) and then adapting them to work for European users.

One major difference is that in Australian DVB-T, LCN data is carried in logical_channel_descriptor descriptors in the second descriptor loop of the Network Information Table (NIT).

If you look in AutoBouquetsMaker dvbreader.c, you'll see LCN information being gathered from the bouquet descriptors and transport descriptors in the Bouquet Association Table (BAT) and in the descriptors loop of the Service Description Table (SDT) as well as in the second descriptor loop in the NIT (as it is in Australia).

Beyond that, there appears to be a bunch of code in AutoBouquetsMaker to deal with conflicting LCNs from different sources.

I'm not able to test any of that, and I haven't even looked at how the conflicting LCNs are dealt with in AutoBouquetsMaker.

I'm happy for the OpenViX folk to make use of what I've done, but it's only a relatively small part of what's needed for OpenViX, even if they want to take my approach at all.

[Huevos]

In ABM there are currently about 50 providers. Out of those only UK terrestrial and Netherlands cable use the same system as Aus terrestrial (and Netherlands terrestrial uses something similar). All UK terrestrial multiplexes are "home" transponders so it is only necessary to scan one transponder to get a complete channel lineup (unlike Aus which requires all transponders to be scanned). This system only allows one LCN list (i.e. not region aware).

All the other providers use different, user defined, systems. I.e. LCN in BAT, (allows multiple LCN lists for different areas), in SDT in user defined descriptors, or in user defined PIDs, that mimic the SDT, BAT, and NIT. There are others too. Lots of work to figure out and not helped by a lot of providers having crappy, broken SI table generators.

And then we need a system for when people scan multiple providers. We round to the nearest 1000 and start the next provider there. I.e. the first channel of the second provider could be 1101 instead of 101.

Or use "alternative numbering" and then each bouquet gets numbered from 1 irrespective of the number of providers there are.

And also ABM has CustomMix which allows providers to be combined into a user created list, mixing the channels based on LCN.

There is no LCN db and bouquet files created by ABM work on all e2 versions.

We did a test for Aus TV and that worked fine. Just needed someone to create the providers files for all areas.

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.

[prl]

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.

...
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.