Thanks for the wonderful program. I just installed GB-PVR 1.08 yesterday, and was wondering what I was going to do for a program guide. It is elegant and easy to use.
But I have the same problem as Carlito with the time offset. That is, a program that should start at 5 PM shows up in the guide as 10 PM. I also tried changing the offset in GB-PVR with no luck. And why it is a 3 hour difference is something of a mystery, since we are 4 hours behind GMT here in the eastern U.S. (eastern daylight time).
3.0 GHz Core 2 Duo E8400, Intel P45 chipset, Nvidia GeForce GT240, HDHomeRun, Win7 64-bit, NPVR 2.2.6
Jim, thanks for the kind words. Could you PM me your zipcode and whether or not your area observes daylight savings? The daylight savings handling needs further refinement, it may be the reason for the 1 hour offset (3 vs 4).
As for the large time offset, it might be a matter of time representation in the XMLOut file. The time displayed is the local time, and the +/- offset is displayed next to it. I don't know, but GBPVR may be expecting central time displayed, with the offset necessary after it. Someone here cna probably clarify this, as I don't use GBPVR...
Here is a snip from my XMLOut
The start time 20070804033500 is actually the UTC start time of that program. It should read:Code:<programme channel="28456298" start="20070804033500 -0300"> <title>The Tonight Show With Jay Leno</title>
Code:<programme channel="28456298" start="20070804033500 +0000"> <title>The Tonight Show With Jay Leno</title>
Hmm, the ISO 8601 which is referenced in the DTD
Also, from the DTD:This profile defines two ways of handling time zone offsets:
1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z").
2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC.
together, this would indicate to me that 'YYYMMDDHHMMSS' alone would be read as UTC, and 'YYMMDDHHMMSS EST' or 'YYMMDDHHMSS +0300' should be read as a local time with timezone to get back to UTC if necessary.if no explicit timezone is given, UTC is assumed.
I see GBPVR has an hour offset setting, maybe this could be used to fix this? Or is that what people are saying keeps getting reset?
Please don't think I'm trying to knock your program. I think that you did a great job!
Not at all, I'm just intereseted in making sure that the bugs are squashed correctly, not in a 'just make it work' fashion. Thanks for your input.Please don't think I'm trying to knock your program.
Not at all, I'm just intereseted in making sure that the bugs are squashed correctly, not in a 'just make it work' fashion. Thanks for your input.[/QUOTE]
Me too. I just wanted to make sure you knew that.
I attempted to use the hour offset in GB-PVR but it had no effect. I then ran a simple search and replace and changed all the offsets in the xml file to "+0000" and all the programs populated in the correct timeslot. If I removed the offset altogether, GB-PVR assumed they were local time which they weren't (they were UTC) and therefore they guide was off by 4 hours.
Hope this helps you.
At any rate, I found a few changes that are necessary to deal with DST properly, and to get the guide data starting with the current hour, so I'll deal with those first.