Tvheadend

This is not a broadcaster error, broadcasters are explicitly allowed to change the tuning values for transport_stream sections in the NIT, this is intended functionality to allow broadcasters to update tuning values on STBs. The unique identifier for a transport_stream is the transport_stream_id.

There should never be two transponders with the same transport_stream_id on a network, and TVH is in error for allowing that. I know of no DVB networks that allow this, because it would break some basic utility of STBs.

Special logic for detecting "overlapping" transponders isn't actually needed. Use the transport_stream_id as the key identifier for a transponder, not the tuning parameter, and consistency should just happen.

Is there a reason why you can't change the schema for storing transponders to have the key field be network_id and transport_stream_id?

Have you tried to analyze these mux parameters broadcasted in NIT on some big satellites like 19.2E, 13E etc.? There are many inconsistencies (mostly small like different rolloff, but some changes are major). The broadcasters forgot to remove the old info on some transponders for example. You're speaking about an ideal world.

The correct way to handle where there's a broken NIT stream from specific transponders, is to allow the user to blacklist transponders with incorrect NITs. Otherwise there is no way you can actually use NIT streams to properly update transponders, because you need to use the unique ID as a unique ID.

I'm unable to check 19.2 E, because I can only get reception from 28.2 E, which has correct and consistent unique network_id values. I would be surprised that 19.2 E has inconsistent NIT streams when both it and 28.2 E are SES operated. Is this in 0x40 tables, or 0x41 or other descriptors? It's not explicit in the spec, but only 0x40 are 'actual network' authoritative descriptors.

Also, it occurs to me that a Transponder will always be authoritative in identifying it's own tuning values. Tuning values that contradict those provided by the Transponder it's self should be deactivated or discarded?

Some muxes does not have the mux tuning parameters.

For each network_id+transport_stream_id pair, store the last N seen satellite_delivery_system_descriptor entries (unique by origin network_id+transport_stream_id pair). Actual tuning value used for the network_id+transport_stream_id pair is the plurality of common satellite_delivery_system_descriptor entries.

That should maintain consistency as long as N is more than twice the number of common faulty entries. Can you estimate a good value of N based on the number of common faulty entries you've seen on 19.2 E?

While this is a problem, I would not consider it a tvheadend "bug". First due to reality vs theory and second due to tvheadend's concept of "network" is not necessarily the same as yours. With tvheadend, I often use one "network" to include muxes from different providers on the same satellite. It would be terrible to have to create a new network for each mux. Also one would have to create a new network for each "feed" on some satellites if tvheadend was to restrict transport id to be unique. For example, on 4.9E, muxes at 12322 and 12360 both use 94 for network id and 1 for transport id, but are from the same "provider". Yes, it is a set of feeds, but it is not uncommon. Also one cable provider has some duplicate tsids and although not according to "spec", it is not tvheadend's job to enforce a "spec", it is to make it work.

Using TIDs as a unique identifier for a network is a required part of correctly handling MUXs changing their tuning values. If you want fully automatic bouquet management, it's a requirement.

Proper handling of networks that, for what ever reason, have intentional duplicate NID TID pairs for different transponders, would be to flat ignore the network table for transponder updates because it is incorrect, and allow duplicates.

If full tuning update management is implemented, there probably should be an "Allow duplicate TIDs" option that also disables updates for these problematic providers?

J Blanc wrote:

Using TIDs as a unique identifier for a network is a required part of correctly handling MUXs changing their tuning values. If you want fully automatic bouquet management, it's a requirement.

Proper handling of networks that, for what ever reason, have intentional duplicate NID TID pairs for different transponders, would be to flat ignore the network table for transponder updates because it is incorrect, and allow duplicates.

I understand that, but the tricky part (as always) is how to handle bad/inconsistent data??

If full tuning update management is implemented, there probably should be an "Allow duplicate TIDs" option that also disables updates for these problematic providers?

Maybe that is not necessary, you just need to check if the "Network ID (limit scanning)" option is set to 0, then do not try to enforce. And/or one could simply disable network discovery.

see also here:
https://tvheadend.org/issues/4261