Guide Info Incorrect for OTA stations

PSIP works fine with my old DTV Pal DVR. 3.5-4 days of data from most of the locals. 36hr from a couple of the small ones. Most of them were very accommodating several years ago, when I explained why I needed them to extend it further than a day.
 
Obviously I was replying to the poster's last sentence, but I do agree using PSIP would be useful. I'm not sure how that plays out for the stations that dropped their licenses though, and continue broadcasting as a sub-channel under another licensee.
It would have to play out better than what we have now. The problem with the Dish-delivered guide data for OTA stations that are now sharing, is that the TSID is now the same for both stations. The Dish software appears to be simply looking for that TSID and then mapping down the -01 guide data stream, without any regard for the two digits in front of the -01. In my guide, for example, this results in the guide data for the host station (023-01) appearing on both 023-01 and 017-01.
 
  • Like
Reactions: NYDutch
Just allow the ota channels that DISH also carries on the satellite, to retain the guide data from DISH and allow ALL sub channels to use PSIP data. Very easy solution and I am sure a company like DISH that prides itself on being "cutting edge" could accomplish if they really wanted to.
Dish needs to fix the problem with the mapping of the existing guide data first. The problem with what you suggest is in the example I posted above. The guide data for WVPX (023-01) which Dish carries, is also being mapped to 017-01 (WDLI) which Dish does not carry. If your solution was implemented, this station should have PSIP data, but since it is already incorrectly detecting satellite-delivered guide data, the guide would still be wrong.
 
And DVR technology would be worthless with short PSIP intervals...
Worthless ? No

The software checks and re-checks on some interval and that's how it picks up future airings of a show for recording. As long as the frequency of the checks is shorter than the time a station uploads their guide data, it will work just fine. Want to save some resources ? Only check the changes in the guide data. No need to re-check the entire data set.
 
Sorry folks, didn't mean to start an OTA war, but this to me is a must fix for them. They are doing to well with me right now to have a little guide problem blemish themselves. Dish is the only sat company that seems to give a flip about us RV'ers. I'm very happy with them so far, but being able to know whats coming on my OTA channels, even if its only a few days guide, would be better than nothing. A lot of my OTA channels that are not available on Dishes OTA package show up in the guide as just "Digital Service" or something like that. Not knocking their OTA package for those that like it, but part of having rabbit ears is being able to cut costs for poor folks like me. :)
 
Dish needs to fix the problem with the mapping of the existing guide data first. The problem with what you suggest is in the example I posted above. The guide data for WVPX (023-01) which Dish carries, is also being mapped to 017-01 (WDLI) which Dish does not carry. If your solution was implemented, this station should have PSIP data, but since it is already incorrectly detecting satellite-delivered guide data, the guide would still be wrong.
Ok then why not allow the sub to pick either PSIP data or Internet data from Titan tv for complete guide data for all channels and sub channels. Then at least either one of those suggestions would give you some type of data if you didn't want satellite delivered guide data.
 
Contracts and reliability. PSIP is not standardized, all sorts of incorrect and/or irrelevant junk gets entered by station minions.
 
Contracts and reliability. PSIP is not standardized, all sorts of incorrect and/or irrelevant junk gets entered by station minions.
And where do you think TitanTV, Rovi, TVGuide, etc get their information? PSIP not standardized? Then why can you see it on the $80 TV you can buy at Wal*Mart? PSIP has been around as long as DTV. It's a perfectly acceptable way to send information. The only con is the amount (or lack of) data (only going out x number of hours/days depending on the station).

I don't think there's one thing in your sentence that is factually correct.
 

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 1)

Latest posts