The Guide Doesn't Populate OTA Channels Very Well

[bluenerd]

My understanding of the sub-channel guide problem (the possibility that I am wrong is fairly high) is that the metadata used for the primary channel is the same for all the associated sub-channels and that makes it difficult to properly associate guide data for sub-channels correctly with programming. It must be done manually, which is a problem.

My Tivos seem to have no problem correctly assigning guide data with sub-channels. I don't know what is different about the Dish Network method and TiVo's method.

Considering Dish is using TiVo guide data, it just means they are even less competent than TiVo.

 

[sam_gordon]

My understanding of the sub-channel guide problem (the possibility that I am wrong is fairly high) is that the metadata used for the primary channel is the same for all the associated sub-channels and that makes it difficult to properly associate guide data for sub-channels correctly with programming. It must be done manually, which is a problem.

My Tivos seem to have no problem correctly assigning guide data with sub-channels. I don't know what is different about the Dish Network method and TiVo's method.

Or, you know, they could just use PSIP to populate the channels they don't carry on satellite.

"It's too hard to program"?

IF <guide data from satellite> = "True"
THEN use <guide data from satellite>.
ELSE use <PSIP data>
END

 

[pattykay]

My understanding of the sub-channel guide problem (the possibility that I am wrong is fairly high) is that the metadata used for the primary channel is the same for all the associated sub-channels and that makes it difficult to properly associate guide data for sub-channels correctly with programming. It must be done manually, which is a problem.

My Tivos seem to have no problem correctly assigning guide data with sub-channels. I don't know what is different about the Dish Network method and TiVo's method.

There are two different OTA guide problems on Dish, though. The first problem (which is the problem that this thread seems to be about) is where Dish does not carry guide data streams for most subchannels at all. That problem could be fixed by simply uplinking more guide data streams for the additional subchannels, as long as those streams could then be mapped correctly.

The second problem is a little bit more complicated to solve though, since it was created by the way that Dish chose to implement OTA guide data mapping. This is the problem where the wrong guide data (for a completely different station) appears on each primary station and subchannel (if Dish is providing subchannel guide data) of a station that is now sharing the same frequency as that other station. The guide data for the host station (and the host station's subchannels) gets mapped to both stations. Dish's guide data mapping is able to recognize the TSID (the master ID that the station is broadcasting, which is the only part of the PSIP data that the Dish receiver uses). The Dish receiver also recognizes the subchannel number for each station (-01, -02, etc.). The problem is that Dish did not provide any way for the receiver to distinguish between two different primary channel numbers (19-01 and 43-01, for example) that are now using the same TSID due to frequency sharing. The guide data for 43 and its subchannels (in my example above) is still being uplinked, but the receiver is still looking for 43's old TSID, to be able to map that data. Since the receiver is now finding 19's TSID instead, that causes 19's guide data to incorrectly appear on 43 in the guide.

The lack of requiring a specific primary channel number (using only TSID and subchannel number) came in handy on the old ViP receivers. Often, if there was weak signal at the time of the scan, the OTA channels would get mapped to their actual frequency (15-01, for example) labeled DTV instead of being labeled with the station's call letters. Another scan (when there is stronger signal) would map this station to 05-01, correctly labeled as WEWS, for example. Since the ViP receivers would allow you to add channels with additional scans (rather than removing any stations not found by the new scan) this would result in the same station appearing both places in the guide. The guide data mapping didn't care. It would correctly put this station's guide data on both "versions" of the channel, and it worked well.

Now, with the way the Hopper OTA scan works, there is much less need for the "map the guide to the TSID regardless of which primary channel number is displayed" feature. Additionally, the frequency-sharing arrangements make this implementation a complete mess, as explained above. So, this is why Dish's OTA guide data mapping needs a complete overhaul.

Or, you know, they could just use PSIP to populate the channels they don't carry on satellite.

"It's too hard to program"?

IF <guide data from satellite> = "True"
THEN use <guide data from satellite>.
ELSE use <PSIP data>
END

That still doesn't fix the issue with wrong guide data from the satellite, though. How would the receiver know that the data is wrong, so it could use PSIP instead?

 

[edisonprime]

There are two different OTA guide problems on Dish, though. The first problem (which is the problem that this thread seems to be about) is where Dish does not carry guide data streams for most subchannels at all. That problem could be fixed by simply uplinking more guide data streams for the additional subchannels, as long as those streams could then be mapped correctly.

The second problem is a little bit more complicated to solve though, since it was created by the way that Dish chose to implement OTA guide data mapping. This is the problem where the wrong guide data (for a completely different station) appears on each primary station and subchannel (if Dish is providing subchannel guide data) of a station that is now sharing the same frequency as that other station. The guide data for the host station (and the host station's subchannels) gets mapped to both stations. Dish's guide data mapping is able to recognize the TSID (the master ID that the station is broadcasting, which is the only part of the PSIP data that the Dish receiver uses). The Dish receiver also recognizes the subchannel number for each station (-01, -02, etc.). The problem is that Dish did not provide any way for the receiver to distinguish between two different primary channel numbers (19-01 and 43-01, for example) that are now using the same TSID due to frequency sharing. The guide data for 43 and its subchannels (in my example above) is still being uplinked, but the receiver is still looking for 43's old TSID, to be able to map that data. Since the receiver is now finding 19's TSID instead, that causes 19's guide data to incorrectly appear on 43 in the guide.

The lack of requiring a specific primary channel number (using only TSID and subchannel number) came in handy on the old ViP receivers. Often, if there was weak signal at the time of the scan, the OTA channels would get mapped to their actual frequency (15-01, for example) labeled DTV instead of being labeled with the station's call letters. Another scan (when there is stronger signal) would map this station to 05-01, correctly labeled as WEWS, for example. Since the ViP receivers would allow you to add channels with additional scans (rather than removing any stations not found by the new scan) this would result in the same station appearing both places in the guide. The guide data mapping didn't care. It would correctly put this station's guide data on both "versions" of the channel, and it worked well.

Now, with the way the Hopper OTA scan works, there is much less need for the "map the guide to the TSID regardless of which primary channel number is displayed" feature. Additionally, the frequency-sharing arrangements make this implementation a complete mess, as explained above. So, this is why Dish's OTA guide data mapping needs a complete overhaul.


That still doesn't fix the issue with wrong guide data from the satellite, though. How would the receiver know that the data is wrong, so it could use PSIP instead?

I think I should elaborate on my previous post, the two major satellite companies don’t consider OTA as a priority, but they should.

 

[primestar31]

My understanding of the sub-channel guide problem (the possibility that I am wrong is fairly high) is that the metadata used for the primary channel is the same for all the associated sub-channels and that makes it difficult to properly associate guide data for sub-channels correctly with programming. It must be done manually, which is a problem.

My Tivos seem to have no problem correctly assigning guide data with sub-channels. I don't know what is different about the Dish Network method and TiVo's method.

I have a Tivo Roamio (that I bought with money from winning a PS4 from Dish and selling it, lol). I've submitted at least 10 or more "Lineup Changes" over the years, and they fix the guide up nicely, usually within a week or less.

I believe it's ALL done manually, but once it's done, it's done until a station makes a change.

 

[MrDRC]

Since I dropped locals and went with the dual tuner antenna I've been using no cable.org for the sub channel guide. It goes out seven days and it's just plain nonsense that Dish can't integrate the data regardless of the hurdles. I had my company scraping web data a while back and it's a no brainer. One machine can gather gigs of data, text, links, tables, images, etc daily. No reason dish can't do something similar.

 

[pattykay]

Since I dropped locals and went with the dual tuner antenna I've been using no cable.org for the sub channel guide. It goes out seven days and it's just plain nonsense that Dish can't integrate the data regardless of the hurdles. I had my company scraping web data a while back and it's a no brainer. One machine can gather gigs of data, text, links, tables, images, etc daily. No reason dish can't do something similar.

I agree. Dish goes to all of the trouble of adding an app that we don't really need (Draft Kings) yet they can't figure out how to add an app for OTA guide data and setting OTA timers? Granted, that would not be as convenient as having the data integrated into the Dish EPG. However, I imagine that an app's guide listings would be easier to keep updated. This is especially true if the company providing that app is already in the business of providing OTA guide data for other platforms. So, let's get it done, Dish!

 

[MikeD-C05]

My Tablo has all my ota channels and sub channels with complete guide information for 2 weeks out. Is is so nice to be able to record the HD signal from Comet channel and be able to select movies I want to record. On DISH I just deleted all the sub channels that don't have guide information since I can't record off of them with out setting manual timers.