MUXs allowed with duplicated transport_stream_id on the same network
|Found in version:||4.2.3-19~g490b6f213||Affected Versions:|
transport_stream_id (Reported within TVH as TransponderID) is a unique identifier within a network, but TVH allows there to be multiple MUX definitions on the same network with the same transport_stream_id .
This can be reproduced by tuning twice on the same transponder, by setting slight changes in the original tuning value. For instance 11777H and 11778H will tune to the same transponder. The same transponder will be tuned to by initial tuning values close enough within the seeking range of the hardware tuner. The original tuning value is not the actual tuning to which the hardware device settles, because that changes every tuning as the device seeks the best signal, and it should not be used as a unique identifier.
This can occur naturally, when transponders are reorganised at the source, or more commonly when the NIT is updated with slightly changed tuning values to reduce STB tuning seek times. Because it appears the TVH does not use transport_stream_id as unique identifiers, this means these updates can create duplicates of the same transponder.
This may be the root cause of a lot of bugs, most obvious is the "duplicate Bouquet channels" issue that can occur with duplicate transponders present.
#1 Updated by Jaroslav Kysela 6 months ago
- Target version set to 4.4
At the time, the user intervention is required - the invalid muxes (incorrect parameters) should be set to 'Ignore' (enable field). Unfortunately, the mentioned inconsistency is from the broadcaster(s). I plan to add more logic to have enabled only one mux for the 'overlapped' parameters and migrate services to this mux, but I have not time to implement this yet.
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?
#3 Updated by Jaroslav Kysela 6 months ago
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.
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?