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??