Problems with time offset on some tv listings

[dinki]

Not sure if this is daylight saving time related or not, but yesterday I noticed that some of my recordings were off by an hour (starting an hour too early) but not all. I emptied my EPG and then repopulated the EPG. I'm seeing scheduled recordings that are out of whack.

For example:

American Idol
Tuesday, March 13, 2007
6:00 PM - 8:00 PM
but should be
7:00 PM - 9:00 PM

and even stranger I have:

The Amazing Race: All-Stars
Sunday, March 18, 2007
6:00 PM - 7:00 PM

AND

The Amazing Race: All-Stars
Sunday, March 18, 2007
7:00 PM - 8:00 PM

This shows an extra earlier showing of the same broadcast (same description) at 6:00PM when in reality '60 minutes' plays in this timeslot.

I checked the 'regular' zap2it web listings for all of the above problem listings and they all appear in the right time slots.

Any ideas? BTW, my computer clock did advance one hour for DST.

[dinki]

I've fixed the problem. I had to empty the epg on each of the three capture sources I had and then repopulate the epg.

[jetgraphics]

I've fixed the problem. I had to empty the epg on each of the three capture sources I had and then repopulate the epg.

I tried that and it didn't fix the skewed listings. *(Config / Capture Sources / Edit / Empty EPG / Update EPG)

Did I miss something?

To compound the problem, the automatic internet time synchronizer set my clock back one hour!

HELP!

(...expletive deleted Congress and its confounded useless meddling)

P.S. - how does one delete all scheduled programs from EPG?

[pwtenny]

I've been having the same problem with EPG data being an hour off. Verified that the Data Direct service is providing correct data, so that's definitely not the problem.

sqlite> SELECT start_time FROM PROGRAMME WHERE name = "Star Trek: Deep Space Nine";
2007-03-07 10:00:00.0000000
2007-03-12 09:00:00.0000000
2007-03-13 09:00:00.0000000
2007-03-14 09:00:00.0000000
2007-03-15 09:00:00.0000000

The 7th was before DST changes and has the correct time for that airing. I'm not even sure why that date has been retained given how old it is. Anyway, you can see every instance thereafter is wrong by an hour. This show does *not* air at 9AM (EST). It just doesn't.

From a DD dump I got:

<schedule program='EP0561580182' station='11163' time='2007-03-13T14:00:00Z' duration='PT01H00M' tvRating='TV-PG' stereo='true' closeCaptioned='true'>

This is the DD XML data on the episode airing the 13th (today). 14:00:00Z is 10AM, EST.

The system clock was correct, and multiple EPG reloads (including an 'empty epg' followed by a restart and reload) failed to correct the problem. Giving the machine the XP patch for this DST issue applied fine, which I did AFTER I tried those EPG reloads. A subsequent EPG reload resulted in incorrect data again.

I decided to upgrade GBPVR and do a fresh install since I was a couple of versions out of date away, and *that* fixed the issue.

Now, since I made a backup of my database, I just need to do a very quick dump of the recording schedule table from the old database and import it into the new one, and I should be good to go.

FYI, a fresh install after patching is probably what you'll end up stuck doing. If you go that route, make sure you also get the updates for the latest version, there is a link in the main post. I needed three of them.

...

Couple of minutes later: This version of the database table has two more columns than the one I was using. It's never easy, is it..

[pwtenny]

FYI so many things changed that most of my saved recording data is going to have to be edited by hand. Channel numbers are different, all the names are screwed up, it even appears the status column numbers have changed meanings.

What a mess.

[jetgraphics]

I've been having the same problem with EPG data being an hour off. Verified that the Data Direct service is providing correct data, so that's definitely not the problem.

Newbie question : how does one access Data Direct service and verify data?

From a DD dump I got:

<schedule program='EP0561580182' station='11163' time='2007-03-13T14:00:00Z' duration='PT01H00M' tvRating='TV-PG' stereo='true' closeCaptioned='true'>

This is the DD XML data on the episode airing the 13th (today). 14:00:00Z is 10AM, EST.

Newbie question: Where is this DD XML data?

I decided to upgrade GBPVR and do a fresh install since I was a couple of versions out of date away, and *that* fixed the issue.

Now, since I made a backup of my database, I just need to do a very quick dump of the recording schedule table from the old database and import it into the new one, and I should be good to go.

FYI, a fresh install after patching is probably what you'll end up stuck doing. If you go that route, make sure you also get the updates for the latest version, there is a link in the main post. I needed three of them.

Newbie question: Which "database" should one backup? How does one restore backup?

TIA

[pwtenny]

how does one access Data Direct service and verify data?

Zap2it labs provides forums and sample applications for learning how to acquire the guide data. I use a PERL script named datadirect-parse.pl. You need SOAP or this script will not run. Get the zip I have linked to, and edit xtvd.xml with your password and username. Depending on how many days worth of data you tell it to get in that file, it will run for a few seconds or longer downloading the data. When it's done, it will tell you the name of the downloaded XML.

You won't gain anything from this though. I did it to make sure Tribune wasn't generating bogus data, and they aren't. The problem is entirely on the client side.

Where is this DD XML data?

Once run, the PERL script from above will leave you with a decently large XML file containing the entire EPG data for X days. 4MB for three days with my setup, but these can get pretty big.

Which "database" should one backup? How does one restore backup?

If you installed GBPVR in the default location: C:\Program Files\devnz\gbpvr\gbpvr.db3

Copy this file into a safe location where it won't get lost or modified. If things go south, copy it back into the GBPVR directory (with the recording service OFF) so that it overwrites the one already there. If you don't know exactly what you are doing, I suggest you try something else, such as continuing to ask for support for Sub with this problem. He may have a fix that doesn't require the drastic measures I've taken.

What I ended up having to do was install a fresh copy of GBPVR, and then merge some of my old database records into the new database by hand. I merged back my reoccuring stuff as well as old program guide data for old recordings so they'd have proper descriptions and what not.

All said it took me about four hours. I do not recommend it.

[sub]

I dont think any of this should have been required.

I'm sure, like other north american users, that if you had the Microsoft daylight savings patch applied, had the correct timezone set on your PC and set to automatically adjust for daylight savings, then most you'd have to do (if anything), was an empty EPG followed by an update EPG.

[pwtenny]

I dont think any of this should have been required.

I'm sure, like other north american users, that if you had the Microsoft daylight savings patch applied, had the correct timezone set on your PC and set to automatically adjust for daylight savings, then most you'd have to do (if anything), was an empty EPG followed by an update EPG.

You're right, it should never have been required, but it was. I applied the patch, it updated my cock, and no amount of EPG dumps fixed it. It took me a long time and a lot of effort to fix the mess.

Blew away an entire morning.

[rcrockett]

For those that don't have the patch, or want to mess with DST,
I just set the time zone to the next one, and the offset bug went away.
sigh....

This bug happens when you apply the Daylight Savings patch AFTER daylight savings has passed. I fixed the bug in the manner that this poster did. I just moved the time zone forward to the next one by 1 hour, then simply moved it back. It was fixed.