search

oe-alliance / AutoBouquetsMaker

Automatically build and update bouquets from the DVB stream.
GNU General Public License v3.0
22 stars 59 forks source link

lcn precedence #246

Closed Azureit closed 2 years ago

Azureit commented 2 years ago

So the code you sent is taking LCN from 2 different descriptors at the same time. That is bad. As said above in (0x82, 0x83) is wrong code. The LCN for each provider should come from one descriptor only. That code will need changing.

Originally posted by @Huevos in https://github.com/oe-alliance/AutoBouquetsMaker/issues/244#issuecomment-1253039365

Huevos commented 2 years ago

Needs to be done from the provider file.

Azureit commented 2 years ago

Needs to be done from the provider file.

I'm thinking about setting LCN descriptor at provider file, if you limit LCN to one per provider, if a provider uses more than one descriptor there can be channels not found with one LCN descriptor .

Huevos commented 2 years ago

Then complain to the provider if there SI tables don't follow follow the standard. We are not going to hack our code for broken providers. And anyway 0x83 seems to work fine for that provider as shown by SatScanLcn plugin.

Azureit commented 2 years ago

Then complain to the provider if there SI tables don't follow follow the standard. We are not going to hack our code for broken providers.

There's no standard that limit providers to use only one LCN system, so we can't call a provider broken, they can have there reasons to do it. ABM is working checking all LCN decriptors and it's not causing any problems?

Huevos commented 2 years ago

The LCN nit descriptor is 0x83. It is written in the DVB specification. And obviously should not be making an LCN list from multiple descriptors.