Using LCNs for channel numbering in all bouquets

[IanSav]

Hi PeterU,

Progress is already well under way (on fixes and improvements to OpenWeif). A number of fixes are in place for the new 1.1.0 release. I have just answered a couple of developer questions so hopefully a few more fixes will be coming soon.

I will be raising the issue of LCN use with the OpenViX / OE-Alliance developers. I have some suggestions on how the broadcast LCNs can be integrated into the "lamedb" data in a way that works for Australia and is transparent for markets that don't use LCNs. If you or Prl want to work through a coded proposal I would be more than happy to go through the details.

Regards,
Ian.

Edited to add context, in (), now that this post is in a separate thread.

[prl]

... I have some suggestions on how the broadcast LCNs can be integrated into the "lamedb" data in a way that works for Australia and is transparent for markets that don't use LCNs. ...

The mapping between DVB-T servicerefs and LCNs is already in /etc/enigma2/lcndb.

The lcndb file entries look like:
eeee0000:1010:0211:0212:00022:00049806

i.e.
NAMESPACE:ONID:TSID:SID:LCN:SIGNAL

The first 4 fields are hex, the last two are decimal. Signal strength is on the scale 0..65535.

Lcndb is created and updated by lib/dvb/scan.cpp, and is read by lib/python/Plugins/SystemPlugins/IniLCNScanner/plugin.py.

The data itself isn't the biggest obstacle to getting LCNs to work the way most people would expect them to.

[IanSav]

Hi Prl,

... I have some suggestions on how the broadcast LCNs can be integrated into the "lamedb" data in a way that works for Australia and is transparent for markets that don't use LCNs. ...

The mapping between DVB-T servicerefs and LCNs is already in /etc/enigma2/lcndb.

The "lcndb" file is not a core component of Enigma2. It is part of the Beyonwiz modified "lib/dvb/scan.cpp". This code and it's support plugin "IniLSCScanner" is not available on OpenViX. For any larger proposal to work these changes must be part of the core Enigma2 code.

Rather than creating "lcndb" perhaps this data would be better integrated into the existing, and globally used, "lamedb" and "lamedb5" files.

The data itself isn't the biggest obstacle to getting LCNs to work the way most people would expect them to.

What obstacles are you seeing?

My concept is to add two LCN fields and an additional channel name field to each logical line of the "labedb" files. Lets call these "BroadcastLCN", "AssignedLCN", "BroadcastName" and "AssignedName". Thy would work as follows:

• When a scan is performed the LCN as broadcast is placed into "BroadcastLCN" and "AssignedLCN". If no LCN is broadcast then use a sequential number starting at 1. For areas where LCN numbers are created based on different ranges for different genres etc then the local rules for numbering should be followed.
• When the scan is performed the channel name as broadcast is placed into "BroadcastName" and "AssignedName". If no name is broadcast then use a name based on the LCN number like "Channel 1". This should be the same number as used in the LCN logic.
• If, during the scan, a duplicated LCN is encountered then the broadcast LCN is still saved in "BroadcastLCN" and the next available number from the "duplicates" range (350 - 399 in Australia) is used for the "AssignedLCN". It is at the point of finding a duplicate that the signal strengths and qualities should be evaluated and the stronger signal allocated the "BroadcastLCN" and the weaker signal(s) be allocated from the "duplicates" pool.
• This process should continue until all available channels have been scanned and recorded. If there is ever a rescan then the new scan data should follow the above rules and replace any entries where the "BroadcastLCN" and "BroadcastName" match. If the channel has not been seen before then it should be integrated into the existing data. If the new channel does not have an LCN then try to match the channel based on "BroadcastName" and allocate the next available LCN from the appropriate range.
• If the broadcaster changes the name of a channel then the "BroadcastName" should be updated immediately and the "AssignedName" can be flagged by appending an "#" to warn the user that the original name has been changed and that they may like to visit a rename / renumber screen (see below) to review and possibly adopt the new name.
  
  If the "#" logic is seen to be too complicated then I think it would be okay to simply copy the new channel name to both the broadcast and assigned fields. The user should note the change and can use a renumber / rename UI (see below) to set the name back to their preferred value.
• The "BroadcastLCN" and "BroadcastName" fields should never be changed by the user and are there to always reflect the broadcast state of this data.
• If a user wishes to renumber or rename a channel they should get a renumber / rename UI that shows both the broadcast and assigned values but only lets them change the "AssignedLCN" or "AssignedName" fields. For convenience colour buttons should be offered to copy each of the broadcast values into the appropriate assigned value.
• All of the Enigma2 code and UI should always use the "AssignedLCN" and "AssignedName" data for LCN and channel name displays. Only the Service Information and editing screens should show both the broadcast and assigned LCNs and names.
• When in the context menu of the FAV screen the "Rename entry" should continue to simply rename the channel in the current bouquet. A new menu item called "Rename / Renumber service" could be added to take the user to the rename / renumber screen to manage the system assigned LCN / name.

How does this proposal sound? Is there anything I haven't covered? Does it address the obstacles?

Regards,
Ian.

[prl]

Peteru is the one who has looked in detail at implementing LCN numbering in the UI. I don't think getting the the serviceref->LCN mapping was the main, or even a significant, issue.

[IanSav]

Hi Prl,

Peteru is the one who has looked in detail at implementing LCN numbering in the UI. I don't think getting the the serviceref->LCN mapping was the main, or even a significant, issue.

Let's see how PeterU weighs in on the proposal.

Regards,
Ian.

[prl]

... What obstacles are you seeing? ...

The main problem I see is working out what to do on systems that have some services that have LCNs and some that don't.

However, I'm not sure whether that's a real problem. If it is, perhaps the way around it is to use numbering outside the range of LCNs for channels without LCNs when LCN numbering is enabled, but that would give the non-LCN channels numbering starting at 1024.

I agree about IanSav's basic outline of how LCNs might be incorporated into lamedb. Perhaps the tag 'l' for broadcast LCNs and 'L' for assigned LCNs, with the 'L' tag not being used if the assigned and broadcast LCNs are the same.

It should be noted that there is already a mechanism for renaming channels in the bouquet editing system. An additional mechanism would need thinking about how it interacts with the existing renaming system.

The exiting Beyonwiz LCN code already examines signal strength when the LCN descriptors are being scanned. At the moment, that's just stored in lcndb and then reallocation of LCNs is done in Plugins.SystemPlugins.IniLCNScanner. That reallocation would need to be moved into the scan.cpp code.

It looks as though LCN numbering can be applied by changing eDVBDB::renumberBouquet() and not a lot more.

[IanSav]

Hi Prl,

For cases where some broadcast channels have an assigned LCN and others don't then simply complete the scan assigning LCNs as specified in the broadcast signal and create a list of all the LCN's allocated. When the scan is complete go through the list of channels and assign LCNs from 1, or the base number for the genre of the channel, skipping any previously assigned LCNs.

Regards,
Ian.

[IanSav]

Hi,

There is one extra refinement that could / should be made to the proposal above. Thanks to IanB for pointing this out.

Rather than copying the scan data to both the Broadcast and Assigned fields simply put the values in the Broadcast field and leave the Assigned field blank. In the display code if the Assigned field is blank simply display the Broadcast field.

With this tweak the user need do nothing to have the UI display track the channel names and numbers directly from the broadcast signal. If the user really wants to change the name or number then they place a value in the Assigned fields and that will stay in place until changed by the user. If they want to go back to tracking the broadcast signal then they simply delete the assigned values.

If the duplicate channel detector forces a channel LCN reassignment then this too will stay in place unless edited by the user.

Regards,
Ian.

[peteru]

Are you aware that there is now not only lamedb, but also lamedb5?

[prl]

I am, because I've been modifying both for the CRID code.

[peteru]

Great.

Where is the code that manipulates lamedb5? I had a quick look and can't see it.

[IanSav]

Hi,

Why do we have a lamedb and lamedb5? They appear to represent the same data.

Regards,
Ian.

[prl]

Great.

Where is the code that manipulates lamedb5? I had a quick look and can't see it.

In dvb.cpp, where the code that writes lamedb is. Much of the code is common or very similar. eDVBDB::parseServiceData() is used by both. eDVBDB::loadServiceList() loads V4, eDVBDB::loadServiceListV5(f) loads V5. saveServicelist() writes both formats.

Although the code writes the two formats to two files, it only reads the V4 lamedb file, not the V5 lamedb5 file.

[prl]

... Why do we have a lamedb and lamedb5? They appear to represent the same data. ...

No idea. The commit logs might tell you.

[IanSav]

Hi,

The version 5 data looks cleaner and has a little extra information. The most comforting thing is that the version 5 data does not end with "Have a lot of bugs!".

If "Huevos" (from the OpenViX team) comes in here he may be able and willing to explain, It would be cleaner if we could all agree to move on to the newer format. (I like the one entry per line rather than one entry over three lines format.)

Regards,
Ian.

[peteru]

Oh, I see. It's actually in dvb/db.cpp, which is where I was looking for it. I just didn't spot the implementation buried inside the old code because I was scanning through the code too fast.

Thanks. Off to git blame to learn more about it...

[IanSav]

Hi,

Apart from the naming and LCN display benefits of my proposal above I should also document the desire from some users to be able to enter the digits for their favourite channels. Enter the channel number (LCN) and go directly to the channel without needing to open the EPG screen, FAV screen or pressing CH+/- multiple times. What ever bouquet is current users will be able to directly enter a number and jump to a channel with a minimal number of button presses.

Regards,
Ian.

[peteru]

Why do we have a lamedb and lamedb5? They appear to represent the same data.

If you read the git commits and then follow the references to github, you'll find this:

This is about adding a new version of lamedb to make it much more readable and easier to process. (so far it just creates a second lamedb files so channel editors will not break. but it may be a start...)

In other words, right now we are in a transition period where the new v5 format is being generated so that third party tools can start using it. At this stage, the old v4 format is being used, but in due course the default will become the new v5 format.

[IanSav]

Hi PeterU,

I would have thought that in this environment it is naughty to play with the data and state files directly. All access should be via the APIs.

Regards,
Ian.

[peteru]

Enter the channel number (LCN) and go directly to the channel without needing to open the EPG screen, FAV screen or pressing CH+/- multiple times. What ever bouquet is current users will be able to directly enter a number and jump to a channel with a minimal number of button presses.

That is already there. The minimal number of button presses for single digit LCN is either two buttons (2, OK) or one button (2) and a wait. Similarly for two digit LCNs you need an extra button press and for three digit LCNs, two extra button presses over the single digit LCN scenario.

[peteru]

I would have thought that in this environment it is naughty to play with the data and state files directly. All access should be via the APIs.

You need to be pragmatic about it. It is what it is. Making the transition less painful for end user, maintainers and developers is a good idea if you want to move forward.

[IanSav]

Hi PeterU,

Agreed, but it is not so easy to get the "published" channel numbers to operate in all bouquets.

Hopefully the efforts of the OpenWebif team will make this easier for users to achieve using OpenWebif 1.0. Local UI editing will still be broken. If we get the LCN proposal over the line then all the filler tricks can just go away and things will "just work" (TM) everywhere.

Regards,
Ian.

[IanSav]

Hi PeterU,

You need to be pragmatic about it. It is what it is. Making the transition less painful for end user, maintainers and developers is a good idea if you want to move forward.

Looking at it simplistically I feel that if the APIs are used then the format of the files underneath would make no difference and could change on a weekly basis.

All developers moving forward should be strongly encouraged to use the APIs so that file formats will *never* be a problem again.

Regards,
Ian.

[peteru]

All developers moving forward should be strongly encouraged to use the APIs so that file formats will *never* be a problem again.

Go ahead. Good luck tracking them down or convincing them.

[IanSav]

Hi PeterU,

All developers moving forward should be strongly encouraged to use the APIs so that file formats will *never* be a problem again.

Go ahead. Good luck tracking them down or convincing them.

I have been talking to people in OpenViX and OpenATV and the OpenWebif team. If I / we spread the word then who knows how far this could go. I know I am being optimistic but I can live in hope.

Regards,
Ian.

[Huevos]

Your main problem is that although the DVB standard for LCN is NIT descriptor 0x83, most providers do not use this. So the chance of other teams making this native in enigma2 is not very likely. And to make things worse, many teams don't believe LCNs are important.

[prl]

Enter the channel number (LCN) and go directly to the channel without needing to open the EPG screen, FAV screen or pressing CH+/- multiple times. What ever bouquet is current users will be able to directly enter a number and jump to a channel with a minimal number of button presses.

That is already there. The minimal number of button presses for single digit LCN is either two buttons (2, OK) or one button (2) and a wait. Similarly for two digit LCNs you need an extra button press and for three digit LCNs, two extra button presses over the single digit LCN scenario.

Yes. This is one of the reasons why the LCN numbering needs to be applied in eDVBDB::renumberBouquet(), because channel number zap is a bouquet function.

[prl]

...
For cases where some broadcast channels have an assigned LCN and others don't then simply complete the scan assigning LCNs as specified in the broadcast signal and create a list of all the LCN's allocated. When the scan is complete go through the list of channels and assign LCNs from 1, or the base number for the genre of the channel, skipping any previously assigned LCNs.
...

Is that numbering of channels without broadcast LCNs to be applied only if LCN-based (or in this case service-based) channel numbering is enabled, or in all cases? If the latter, that would change channel numbering quite dramatically for users who don't want to use service-based numbering.

[prl]

Your main problem is that although the DVB standard for LCN is NIT descriptor 0x83, most providers do not use this. So the chance of other teams making this native in enigma2 is not very likely. And to make things worse, many teams don't believe LCNs are important.

Hi, Huevos, welcome to the forum.

I thought the Australian DBV-T LCN scheme had been copied from the UK DVB-T one (perhaps from the Digital Television Group's "D-Book"). That's what AS 4599 says. Are there significant differences?

Australian LCN use is described in AS 4599 Digital television—Terrestrial broadcasting Part 1: Characteristics of digital terrestrial television transmissions and in the FreeTV (Australian TV industry consortium) OP-41 Logical Channel Descriptor and Allocation of Logical Channel Numbers.

[IanSav]

Hi Prl,

...
For cases where some broadcast channels have an assigned LCN and others don't then simply complete the scan assigning LCNs as specified in the broadcast signal and create a list of all the LCN's allocated. When the scan is complete go through the list of channels and assign LCNs from 1, or the base number for the genre of the channel, skipping any previously assigned LCNs.
...

Is that numbering of channels without broadcast LCNs to be applied only if LCN-based (or in this case service-based) channel numbering is enabled, or in all cases? If the latter, that would change channel numbering quite dramatically for users who don't want to use service-based numbering.

I would welcome Huevos' insight from his experience with various world markets but my thought was that if LCN's are not broadcast and/or most countries don't care about LCNs then whatever LCN number gets assigned won't matter. It is very likely that in such a case all the the LCNs would never be displayed in the UI anyway so who would care what LCN was assigned. At the moment, without proper LCN processing, the assigned LCNs are effectively random anyway.

Regards,
Ian.

[peteru]

There are two approaches:

1. Use the existing channel number infrastructure and populate it from LCN data.

2. Add a completely separate LCN infrastructure.

Both have the same problem if related code is worked on by developers who don't care and don't see LCNs. It will lead to code rot. It may even be removed because some developers may consider it dead code.

[prl]

I was contemplating using method 1. That would appear to give the functionality in a way that requires the minimum code changes and upkeep.

But it's beginning to look as though LCN-based service numbering may be a hard sell into the enigma2 upstream repositories anyway.

[IanSav]

Hi Prl,

I was contemplating using method 1. That would appear to give the functionality in a way that requires the minimum code changes and upkeep.

I agree. It is also likely to be the path of least resistance.

But it's beginning to look as though LCN-based service numbering may be a hard sell into the enigma2 upstream repositories anyway.

I am not so sure about that. The OpenWebif people took no convincing at all to support and maintain the spacing data. I suspect they would love to support LCNs if it meant that they could do away with all the special padding to maintain adjusted LCN number management code.

In the OpenWebif got discussions there are people from OpenViX, OpenATV and other builds. I am not seeing objection to the changes as long as they don't break or interfere with users selected mode of operation.

If the code is clean, well written, well behaved and documented I would hope that there wouldn't be much objection to it.

Regards,
Ian.

[prl]

...

But it's beginning to look as though LCN-based service numbering may be a hard sell into the enigma2 upstream repositories anyway.

I am not so sure about that. The OpenWebif people took no convincing at all to support and maintain the spacing data. I suspect they would love to support LCNs if it meant that they could do away with all the special padding to maintain adjusted LCN number management code.
...

But is there much demand for LCNs?

OpenViX seems pretty satellite-focussed, and I'm not sure that LCNs are used in DVB-S much (or at all). Satellite-based systems are interestingly different. The changes in viewpoint between having 40-odd services in Australia vs 10000+ in many satellite setups was sometimes a bit surprising to me.

LCNs aren't even part of the ETSI DVB-T standard. The current OpenViX scan.cpp code doesn't look at them.

[IanSav]

Hi Prl,

That is why they wrote and maintain AutoBouquetMaker.

Regards,
Ian.

[IanB]

A question Huevos may be able to answer that might give us some perspective with LCN numbering.

How do satellite users interact with channel selection?

I guess a little similar is we have a pay tv provider, Foxtel. They provide a few hundred services. They have a fixed selection ui scheme to provide a more or less arbitrary number between 100 and 999 to each service, the numbers are grouped by the 100's digit, i.e. 1xx for general channels, 2xx for high def general channels, 4xx movies, 5xx sport, etc.

So to watch a given program you either press the 3 digits if you know it or you scroll through a long list.

To my thinking if I was presented with 1000's of satellite channels I would want to be able to assign the good number to my popular channels, maybe making use of repeated digits, i.e. 1111, 1122, 1133, 1144, 2222, 2233. The default enigma technology I have seen so far seems to stack lots of bouquets either with 100 or 1000 spacing and fill from the bottom up, i.e. 1, 2, 3, 4, 5, 6, 10, 11, 12, 13, 100, 101, 102, 103, 104, 200, 201, 202, 203, 1000, 1001, 1002, 1500, 1501, 1502, 2000, 2001, etc

[prl]

The service numbering in both the Beyonwiz and the OpenViX either numbers the services in each bouquet starting at 1, or numbers the services through all bouquets starting at 1 and using consecutive numbering straight through, without gaps, apart from invisible numbered markers (serviceref flags 832/0x340) as in the padding entries in the Beyonwiz Terrestrial TV LCN bouquet (ignoring any alternative services lists).

This behaviour is controlled in both the Beyonwiz and OpenViX images by config.usage.alternative_number_mode (MENU>Setup>TV>Channel selection>Alternative numbering mode in the Beyonwiz image).

So, for example, three bouquets, A, B & C, each with 3 services, and no invisible padding would number either:
A[1, 2, 3], B[4, 5, 6], C[7, 8, 9] (Alternative numbering mode disabled)
or
A[1, 2, 3], B[1, 2, 3], C[1, 2, 3] (Alternative numbering mode enabled)

This also means that on the Beyonwiz, if Terrestrial TV LCN isn't the first bouquet in the list of bouquets, and Alternative numbering mode is disabled, it won't have the expected LCN-like numbering if any of the bouquets before it in the list of bouquets have any services in them. Yet another reason (if you needed any more) why Terrestrial TV LCN isn't a great idea.

Its possible other images may do the numbering differently.

[IanB]

Its possible other images may do the numbering differently.

I haven't seen any divergence from the behavior you describe, but there may well be. But I have seen huge variance in the usage. There are a whole raft of plugins and PC programs dedicated to building and managing vast sets of bouquets, nearly all make use of the bouquet padding feature, most only at the end of each bouquet.

[prl]

That may well be what's rounding up the numbers. It all seems a bit primitive, really.

[Huevos]

I thought the Australian DBV-T LCN scheme had been copied from the UK DVB-T one (perhaps from the Digital Television Group's "D-Book"). That's what AS 4599 says. Are there significant differences?

Not exactly. The big difference is in the UK it is only necessary to scan one transponder. i.e. UK terrestrial multiplexes are "network aware", Whereas, Aussie multiplexes are only "self aware".

In the attached grabs of SI tables from UK and AU TV you can see Aussie only has 1 transport stream in the NIT and no SDT other table.

Anyway my point was descriptor 0x83 in the NIT table is just one way of doing LCN. In AutoBouquetsMaker we cover around 50 broadcasters, of which only 4 uses this method to send their LCN data.

[IanB]

A question Huevos may be able to answer that might give us some perspective with LCN numbering.

How do satellite users interact with channel selection?

I.e. How does a typical satellite enigma user organise, manage and use their 100's of channels?

[prl]

I had a look at the AutoBouquetsMaker code and extracting all the LCN data that's there doesn't look particularly daunting. There are 9 descriptor values and 7 different descriptor formats.

The descriptors appear (I think) as follows:
0x81: BAT2
0x83: BAT1, BAT2, NIT2
0x86: BAT2
0x93: BAT2
0xe2: BAT2
0x87: NIT2
0x88: NIT2
0x81: SDT
0xca: SDT
where 1 indicates the first descriptor loop and 2 indicates the transport stream loop.

The Australian LCN data is in the transport stream loop of the NIT, and I think the extraction code would work for the UK case. I even thaing the creation of the current lcndb file would work in the UK case, though I'm not sure that's the best way to go.

I'm also not sure how duplicate LCNs should be handled outside the Australian DVB-T rules.

The main problem I have is the inability to test most of that additional LCN extraction code if I was to add it.

[IanSav]

Hi Prl,

The main problem I have is the inability to test most of that additional LCN extraction code if I was to add it.

Perhaps Huevos could test the code for you. He may also be able to access other markets for further testing.

Regards,
Ian.

[IanSav]

Hi Prl,

I had a look at the AutoBouquetsMaker code and extracting all the LCN data that's there doesn't look particularly daunting. There are 9 descriptor values and 7 different descriptor formats.

Have you seen or worked out the way to define the Australian terrestrial data in a way that would allow AutoBouquetMaker to correctly and efficiently build an equivalent of the "Terrestrial LCN TV" bouquet?

I have been able to make a top level category called "Australia" and then use the "Providers" menu to select "Australia" but then I can't get to select the appropriate area to force a scan of only the frequencies appropriate to that area. I can guess the use of some of the tags but I haven't worked out how all the various tags and their values interact.

Regards,
Ian.

[prl]

...

I had a look at the AutoBouquetsMaker code and extracting all the LCN data that's there doesn't look particularly daunting. There are 9 descriptor values and 7 different descriptor formats.

Have you seen or worked out the way to define the Australian terrestrial data in a way that would allow AutoBouquetMaker to correctly and efficiently build an equivalent of the "Terrestrial LCN TV" bouquet? ...

I wasn't looking at the code to answer that question, so I don't know. But I don't know why I'd want change the way "Terrestrial LCN TV" is built, other than to make use of real LCN numbering in bouquets and get rid of the padding in "Terrestrial LCN TV".

What's incorrect or inefficient about the way "Terrestrial LCN TV" is built now?

[prl]

Hi Prl,

The main problem I have is the inability to test most of that additional LCN extraction code if I was to add it.

Perhaps Huevos could test the code for you. He may also be able to access other markets for further testing.
...

Someone would need to. But then they'd also need to think that it was worth the effort.

[IanSav]

Hi Prl,

What's incorrect or inefficient about the way "Terrestrial LCN TV" is built now?

Nothing. It is simply that IniLCNScanner and the changes behind it are specific to the Beyonwiz build. It would be good if we can find ways to get closer to our Enigma2 siblings.

Regards,
Ian.

[prl]

Hi Prl,

What's incorrect or inefficient about the way "Terrestrial LCN TV" is built now?

Nothing. It is simply that IniLCNScanner and the changes behind it are specific to the Beyonwiz build. It would be good if we can find ways to get closer to our Enigma2 siblings.
...

Apart from the IniLCNScanner plugin itself, the total amount of code in the UI to support it is a single 5-line block in Screens.ServiceScan and two blocks of code, one 6 lines and one 2 lines, in Screens.GeneralMenu that code for a disabled main menu entry.

IniLCNScanner doesn't appear to have originated from Beyonwiz (its default renumbering rules file has some Italy-specific stuff). It may have originated from LCNScanner in openatv. It's similar.

[prl]

Hi Prl,

I had a look at the AutoBouquetsMaker code and extracting all the LCN data that's there doesn't look particularly daunting. There are 9 descriptor values and 7 different descriptor formats.

Have you seen or worked out the way to define the Australian terrestrial data in a way that would allow AutoBouquetMaker to correctly and efficiently build an equivalent of the "Terrestrial LCN TV" bouquet?

I have been able to make a top level category called "Australia" and then use the "Providers" menu to select "Australia" but then I can't get to select the appropriate area to force a scan of only the frequencies appropriate to that area. I can guess the use of some of the tags but I haven't worked out how all the various tags and their values interact.
...

AutoBouquetsMaker appears to build bouquets from the contents of the Bouquet Association Table. Other tables are also used to get information like LCN, but the bouquets are defined by the BAT. Australian broadcasters don't appear to have one in the broadcast stream, or at least the scan on the broadcast channel times out before one is found.