Well, I have to eat my words before the ink is even dry.
Right after posting the above, I found another document. Actually it's the document that the 2nd document I was referencing above used as a source. It is
http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.05.01_40/en_300468v010501o.pdf
Well THIS document had pretty much the same data format charts as the other one, HOWEVER, in addition it had a definition of the Service ID in the SDT description. It said the following:
"service_id: This is a 16-bit field which serves as a label to identify this service from any other service within the TS.
The service_id is the same as the program_number in the corresponding program_map_section."
So from this, it seems to indicate pretty clearly that Service ID=Program Number, which is the same as Channel number.
This all now tells me that the receivers that used SID and channel number as the same thing were correct. However TSREADER and other stream analyzers are also correct, because they were identifying the number in the SDT as being the Service ID, and the number in the PAT/PMT as being the Program Number. What this tells me, is that the receivers and analyzers are correct, and the error is with the satellite uplinkers such as Dishnet, and a couple other muxes that used Service ID parameters in the SDT. Ie Dishnet and others are putting a number in there which is NOT the same as the Program Number.
I've run into several muxes that have an SID entry. So far, I don't think I've seen one where it is the same as the Program Number, but I will look on G19, and see what the entries look like there. I have seen a few where they are just a zero or one though, but still different from the channel numbers.
Bottom line is that the sat uplinkers apparently don't follow the spec.
Right after posting the above, I found another document. Actually it's the document that the 2nd document I was referencing above used as a source. It is
http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.05.01_40/en_300468v010501o.pdf
Well THIS document had pretty much the same data format charts as the other one, HOWEVER, in addition it had a definition of the Service ID in the SDT description. It said the following:
"service_id: This is a 16-bit field which serves as a label to identify this service from any other service within the TS.
The service_id is the same as the program_number in the corresponding program_map_section."
So from this, it seems to indicate pretty clearly that Service ID=Program Number, which is the same as Channel number.
This all now tells me that the receivers that used SID and channel number as the same thing were correct. However TSREADER and other stream analyzers are also correct, because they were identifying the number in the SDT as being the Service ID, and the number in the PAT/PMT as being the Program Number. What this tells me, is that the receivers and analyzers are correct, and the error is with the satellite uplinkers such as Dishnet, and a couple other muxes that used Service ID parameters in the SDT. Ie Dishnet and others are putting a number in there which is NOT the same as the Program Number.
I've run into several muxes that have an SID entry. So far, I don't think I've seen one where it is the same as the Program Number, but I will look on G19, and see what the entries look like there. I have seen a few where they are just a zero or one though, but still different from the channel numbers.
Bottom line is that the sat uplinkers apparently don't follow the spec.