Free XMLTV EPG scraper

[smajor]

I agree. You can add the program to the exclusion list and it should not trip it.

No problem, thought it was worth mentioning just in case. I wasn't accusing the author of being malicious, just to clarify.

[JimF]

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).

[drlava]

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...

[whurlston]

Here is a snip from my XMLOut

Code:

<programme channel="28456298" start="20070804033500 -0300">
  <title>The Tonight Show With Jay Leno</title>

The start time 20070804033500 is actually the UTC start time of that program. It should read:

Code:

<programme channel="28456298" start="20070804033500 +0000">
  <title>The Tonight Show With Jay Leno</title>

[drlava]

Hmm, the ISO 8601 which is referenced in the DTD
http://www.w3.org/TR/NOTE-datetime

says:

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.

Also, from the DTD:

if no explicit timezone is given, UTC is assumed.

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.

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?

[whurlston]

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.

Correct. The problem is that the time is not local time but UTC. Also, the -0300 is actually wrong for my timezone (-0400 during DST and -0500 otherwise).

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?

I haven't tested it. I'll try it tomorrow and let you know.

Please don't think I'm trying to knock your program. I think that you did a great job!

[drlava]

Correct. The problem is that the time is not local time but UTC. Also, the -0300 is actually wrong for my timezone (-0400 during DST and -0500 otherwise).

Interesting. Those values are taken from the MSN response. Perhaps there's some more canadian diffferences I hadn't noticed, because in my time zone in the U.S., it reports local time.

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.

[whurlston]

Interesting. Those values are taken from the MSN response. Perhaps there's some more canadian diffferences I hadn't noticed, because in my time zone in the U.S., it reports local time.

You're the second person in a week to think I'm Canadian. I'm actually in Kentucky.

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.

[drlava]

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.

Thanks. That operation seems to run counter to what we were thinking the standard specification was a few posts ago, where a time without a zone would be UTC and a time with a zone would be local.

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.

[whurlston]

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.

Sounds good. You're still well ahead of the cutoff date. If you have any questions, I'll do my best to answer them.