How To Fix TSID ONID Transponder Problems

[el bandido]

This discussion will mainly apply to ATSC transponders in North America, but the same issues can be found in some satellite transponders.

By default, enigma2 will save channels based on the Transport Stream ID, or TSID. The FCC requires all high powered ATSC television stations to have an unique TSID, but this Does Not apply to Low Power ATSC stations. In Atlanta, Ga., there are several Low Power ATSC stations that have a TSID of 0000.

When an enigma2 receiver scans a transponder with a TSID of 0000, then those channels are saved , and are usable. When the second transponder is scanned that has a TSID of 0000, then the channels that were scanned on the first transponder are unusable, and the channels for the second transponder are usable. This situation may be repeated multiple times during a scan if several transponders have the same TSID. Shown below is the error that will be seen when trying to view the first set of channels after the second set of channels has been scanned.


There are two ways to fix the SID not found in Pat IF the error is due to two or more transponders having the same TSID.
(1) Manually edit the transponders that have the same TSID, making the TSID unique between them. Doing this requires manually editing the transponder in lamedb, and editing all the channels associated with that transponder. Background scanning will probably need to be disabled so your edits are not automatically overwritten. (Manual Edits is what I had to do when this problem was first discovered in ATSC)

(2) Set the receiver to Ignore DVB-x namespace sub network to No in the receiver. Default for these settings is Yes. This setting for DVB-C, DVB-T, and DVB-S may be found in the Customize menu of the receiver in PLi type images. (OE Alliance images may have different menus, but the settings will be the same.)
DVB-C and DVB-T can apply to ATSC channels in North America. DVB-S should apply to all satellite transponders, such as DVB-S, DVB-S2, DVB-S2X.

Here is a screencap that shows all of three of these settings changed to No, which is the way I normally run the enigma2 receiver. These settings have worked in all of my enigma2 receivers for years, but they may cause issues in other parts of the world.


More information about this may be found in the links.
https://forums.openpli.org/topic/56125-service-scan-ignoring-dvb-namespace/
https://en.wikipedia.org/wiki/MPEG_transport_stream

Requiring a TSID for some and not others seems like a dumb thing to do. This gave me headaches a few years ago...


Note: Delete the effected channels and re-scan after changing the settings.

 

[Babadem]

This discussion will mainly apply to ATSC transponders in North America, but the same issues can be found in some satellite transponders.

By default, enigma2 will save channels based on the Transport Stream ID, or TSID. The FCC requires all high powered ATSC television stations to have an unique TSID, but this Does Not apply to Low Power ATSC stations. In Atlanta, Ga., there are several Low Power ATSC stations that have a TSID of 0000.

When an enigma2 receiver scans a transponder with a TSID of 0000, then those channels are saved , and are usable. When the second transponder is scanned that has a TSID of 0000, then the channels that were scanned on the first transponder are unusable, and the channels for the second transponder are usable. This situation may be repeated multiple times during a scan if several transponders have the same TSID. Shown below is the error that will be seen when trying to view the first set of channels after the second set of channels has been scanned.
View attachment 16437

There are two ways to fix the SID not found in Pat IF the error is due to two or more transponders having the same TSID.
(1) Manually edit the transponders that have the same TSID, making the TSID unique between them. Doing this requires manually editing the transponder in lamedb, and editing all the channels associated with that transponder. Background scanning will probably need to be disabled so your edits are not automatically overwritten. (Manual Edits is what I had to do when this problem was first discovered in ATSC)

(2) Set the receiver to Ignore DVB-x namespace sub network to No in the receiver. Default for these settings is Yes. This setting for DVB-C, DVB-T, and DVB-S may be found in the Customize menu of the receiver in PLi type images. (OE Alliance images may have different menus, but the settings will be the same.)
DVB-C and DVB-T can apply to ATSC channels in North America. DVB-S should apply to all satellite transponders, such as DVB-S, DVB-S2, DVB-S2X.

Here is a screencap that shows all of three of these settings changed to No, which is the way I normally run the enigma2 receiver. These settings have worked in all of my enigma2 receivers for years, but they may cause issues in other parts of the world.
View attachment 16438

More information about this may be found in the links.
https://forums.openpli.org/topic/56125-service-scan-ignoring-dvb-namespace/
https://en.wikipedia.org/wiki/MPEG_transport_stream

Requiring a TSID for some and not others seems like a dumb thing to do. This gave me headaches a few years ago...
View attachment 16439

Note: Delete the effected channels and re-scan after changing the settings.

This issue still exits in Enigma 2 Images after all these years!?!? On 103.0°W, When I BlindScan, Channels from 4140 V 30000, are logged into 4120 H 30000, but no Video or Audio. The funny thing is that there's no error message as the earlier Images used to display. Anyway, following Step 2 of the instructions above temporarily fixed the problem until a permanent solution is found.

 

[el bandido]

A lot of effort went into finding a solution for this problem. First, the problem was identified. Second, the problem had to be shown to exist, including an in-depth description as to why and how it exists. Then some sort of solution was found for it. Namespace is entwined in enigma2 and it will most likely take a helluva lot of work to fix it proper.

To further complicate things, this is mostly a North American problem, but I have seen exactly one instance of the problem apparently existing in Europe. This means there is really no desire or interest to do anything to fix it. Settings in enigma2 menus are provided as a solution and that is probably as good as it is going to get today, tomorrow, and another 5 years! You are welcome to post about this problem on OpenPLi forum or any of the other development forums. I say "Good Luck" on getting anyone to look at this issue because it will most likely take a major bit of effort to fix it properly. You have no idea of what it took to get it this far...

 

[Babadem]

A lot of effort went into finding a solution for this problem. First, the problem was identified. Second, the problem had to be shown to exist, including an in-depth description as to why and how it exists. Then some sort of solution was found for it. Namespace is entwined in enigma2 and it will most likely take a helluva lot of work to fix it proper.

To further complicate things, this is mostly a North American problem, but I have seen exactly one instance of the problem apparently existing in Europe. This means there is really no desire or interest to do anything to fix it. Settings in enigma2 menus are provided as a solution and that is probably as good as it is going to get today, tomorrow, and another 5 years! You are welcome to post about this problem on OpenPLi forum or any of the other development forums. I say "Good Luck" on getting anyone to look at this issue because it will most likely take a major bit of effort to fix it properly. You have no idea of what it took to get it this far...

I'm extremely grateful for all the efforts you put in to proffer a working around to the existing problem. I'm just surprised that the real stakeholders of the project didn't make further efforts to find a permanent solution to the problem. Thanks, Again.

 

[el bandido]

It's pretty much a Dead-End without doing a lot of work -- I would guess at least a hundred files or more to edit and several hundred to look through probably. No one wants to do that much work to satisfy a small problem that basically exists only in North America. That;s why it hasn't been messed with. Unfortunately, it is what it is.....

 

[majortom]

I have had pretty good luck communicating with the local broadcasters here, whenever I notice one of them slipping in terms of
ATSC compliance. Which three callsigns aren't having a TSID value populated down there in Atlanta Area??

 

[cyberham]

I have this same symptom on 133W but the TSID is not 0000 for the transponders. The TSID for each is 0002. The affected transponders are 4168 H 16303 and 4180 V 31245. Whichever is scanned last is the satellite that all channels are saved in. It has no negative effect for me since 4180 is encrypted anyway (and 4168 is religious...). So I don't need either transponder. It's just a curiosity.

Signal finder identifies the correct channels for each transponder according to its Service list.

Added: I forgot to mention that my GT Media receiver doesn't have an issue with these two tps. Each scans in correctly.

 

[el bandido]

I have had pretty good luck communicating with the local broadcasters here, whenever I notice one of them slipping in terms of
ATSC compliance. Which three callsigns aren't having a TSID value populated down there in Atlanta Area??

I will attach a recent scan. The low power stations are not in that scan as some antenna work is needed to get them. Maybe time for that later this year.

I have this same symptom on 133W but the TSID is not 0000 for the transponders. The TSID for each is 0002. The affected transponders are 4168 H 16303 and 4180 V 31245. Whichever is scanned last is the satellite that all channels are saved in. It has no negative effect for me since 4180 is encrypted anyway (and 4168 is religious...). So I don't need either transponder. It's just a curiosity.

Signal finder identifies the correct channels for each transponder according to its Service list.

Added: I forgot to mention that my GT Media receiver doesn't have an issue with these two tps. Each scans in correctly.

The correct fix for enigma2 will probably be complex, and is something I am not interested in doing. The solution was described in post#1 of this thread. I can probably come up with some sort of "fix" for it, but really that was done by Athoik years ago. My "fix" might break something else, and the solution we currently have is proven to work. It is what it is....

As for the GT Media working properly, well...that is great! And it is also nice to know. That particular receiver has its own set of problems. At least they coded this particular part correctly.

On some of the Closed Sourced receivers, tricks will be done to make you think something works when it really does not. One of the Octagon receivers was coded to appear that multi-stream was being found in blindscan, when in reality, the receiver was simply reading from a list and would apply what was needed. No multi-stream blindscan actually existed, and if your multi-stream transponder was not in the list, then you did not get the correct transponder information.

TNAP also has something similar to that in recent versions. You can for example blindscan 101w ku band and get the hidden radio channels, provided the blindscan of the proper transponder was fairly close in frequency to what it should be. The hidden channels do not show on the blindscan screen, but indeed they are there if you look in the radio channels after the scan completes. All I had to do to complete an illusion would be to have the channels appear in the scan list. Then we could pretend TNAP was blindscanning hidden channels!

So on the Closed Source stuff, it is nice to know about, but some of it is smoke in mirrors. The supposed 4:2:2 GT Media reception is a great deception example. Anyway, for the GT Media, on this particular channel problem, they most likely have correct coding where enigma2 does not.

Here are the correct parameters that should work well in North America, and solve the TSID ONID problems. See also post #1 of this thread.

 

[EnoSat]

If Ignore DVB-S/T/C is set to ON, enigma creates a namespace in the form XXXX0000, but if TSID is missing in TS, a namespace in the form XXXX1234 is written. Only the last transponder with the same TSID/ONID is stored in the lamedb (in Europe, this problem occurs on 16E and on some feeds).
If Ignore DVB-S/T/C is set to OFF, enigma creates a namespace in the form XXXX1234 and transponders with the same TSID/ONID are not overwritten.
XXXX = position
1234 = transponder frequency