Timezone compensation in TV Guide (EPG Buddy)

[Mel]

So this is all the fault of the tvguide.com data for North America, I suppose that might be why MPortal2 provides the option to compensate. In any case, it sounds like its presently unfixable, that there are no tweaks I can make in any NextPVR files to correct for it, and no desire on sub's part to include, what I guess is an edge case, a GUI feature to compensate for tvguide's time zone handling. That's too bad but entirely fair. Ces't la vie. Thanks again for your efforts Martin but I think you've spend enough time on this. I know what my options are.

Stay safe, stay healthy.

[mvallevand]

I suspect it is a bug in EPG-Buddy scraping not the web site or their on line data would be wrong and it isn't. This pretty much summarizes what we just went through https://forum.team-mediaportal.com/threa...st-1272860

I suggest mentioning it here https://forums.nextpvr.com/showthread.php?tid=58945 the author might fix it at least other users might be saved the time.

Martin

[sub]

I have made a bit of hack to support this in the next release.

When you add your xmltv lineup, you can specify an optional bit on the end of the filename, to give a number of hours/minutes to added/removed from the time:

D:\TVGuide_1_unedited.xml [+07:00]

[mvallevand]

I have made a bit of hack to support this in the next release.

When you add your xmltv lineup, you can specify an optional bit on the end of the filename, to give a number of hours/minutes to added/removed from the time:

D:\TVGuide_1_unedited.xml [+07:00]

Should this hack be DST aware?  Perhaps [+08:00] and then you apply  DateLightDelta

Martin

[BrettB]

I have made a bit of hack to support this in the next release.

When you add your xmltv lineup, you can specify an optional bit on the end of the filename, to give a number of hours/minutes to added/removed from the time:

D:\TVGuide_1_unedited.xml [+07:00]

Should this hack be DST aware?  Perhaps [+08:00] and then you apply  DateLightDelta

Martin

I would think that since it's a hack you leave that part up to the user. Especially since as you're approaching the DST change date, you might or might not need different offset values for different days in the .xml file.

[Mel]

For what it's worth, I've ended up going at this from a different direction entirely and I'd say unless you guys hear from the author of EPG Buddy (or just want to add the functionality for your own reasons) it might not be worth putting additional effort into fixing/accommodating this. I've been able to cobble together a workflow using the python grabber from Kodi as a standalone solution scraping Zap2It guide data and it seems to be working. 

I don't know how much it would cut into Schedules Direct's bottom line, or if it's possible, but I suspect a lot of the problem edge cases like myself, who really only watch a single channel, could be avoided if they offered free local OTA 7-day data (or something). In any case, thank you all, Martin specifically, for doing your best to help me along. It's a shame there isn't a more unified open source effort around this stuff, it seems like there's been so much overlap of labour after WMC disappeared and as a result so many threads of varying/outdated/inapplicable info out there. Navigating to solid, up to date, and reliable info is way too much effort. I appreciate your efforts here. Stay safe and healthy, all.

[mvallevand]

SD buy their data from Gracenote/TMS so it wouldn't make sense for them to give it away. There is value added over free ota guide data which your use case suits you just want more. I believe in supporting SD because I don't want them to fold it provides safety that scrapping solutions can't provide. Also for a few dollars it isn't worth the hastle just today I pointed out to another user an xml issue with zap2epg failing.

Martin

[Lehmden]

Hi.
I just found this thread and I didn't had time to read all. If I understand it right, tvguide.com adds a -7:00 time compensation to the xml file? This is exactly as the XMLTV specs are telling to do. And as far as I can judge it is working in NPVR 5 this way... My own epg data has a time offset of +2:00 hours (middle European daylight saving time) and is working flawlessly in my NPVR V5 test environment (and also with MP, TVMosaic and even TVHeadend)...

This is one sample entry in the resulting xmltv file:
"  <programme start="20200911221500 +0200" stop="20200911231500 +0200" channel="K1">
    <title>Navy CIS: New Orleans</title>
    <sub-title>Im Bruchteil einer Sekunde</sub-title>
    <desc>Der aktuelle Grund: Er thematisiert Gewalt gegen Schwarze. Der weiße Detective Ted Bradley erschoss einen vermeintlichen afroamerikanischen Straftäter. Das Opfer: Navy Officer Mitchell. Der habe eine Waffe gezogen, behauptet Bradley. Zeugen gibt es nicht! Finden Pride (Scott Bakula) und sein Team die Wahrheit heraus?</desc>
    <date>2020</date>
    <country>USA</country>
    <length units="minutes">60</length>
    <episode-num system="xmltv_ns">5.16.</episode-num>
    <category>Detective / Thriller</category>
    <credits>
      <actor>Scott Bakula (Dwayne Pride)</actor>
      <actor>Vanessa Ferlito (Tammy Gregorio)</actor>
      <actor>Necar Zadegan (Special Agent Hannah Khoury)</actor>
      <actor>Charles Michael Davis (Quentin Carter)</actor>
      <actor>Rob Kerkovich (Sebastian Lund)</actor>
      <actor>Daryl Mitchell (Patton Plame)</actor>
      <actor>CCH Pounder (Loretta Wade)</actor>
      <actor>Matthew James Thomas (Ted Bradley)</actor>
      <actor>Shelley Robertson (Nessa Mitchell)</actor>
      <actor>Mandy Levin (Detective Christina Cooper)</actor>
    </credits>
  </programme>
"

By the way, I never needed to use the "add time compensation" feature in MediaPortal, no matter which EPG data source I've used and I'm using MP for more than 10 years now... 

If you may have a deeper look at the XMLTV specs you also will see that the time compensation is a "must" for every valid XMLTV file. 

A quote from the official Wiki:

"All start- and stoptimes must include a timeoffset (e.g. +0100). Timezones (e.g. EST) are not permitted."

You can see yourself here:

http://wiki.xmltv.org/index.php/XmltvCapabilities

If I misunderstood the issue, I apologise. Then, please explain exactly what's the issue is about. I've subscribed to this thread so I will get notice if there is an answer...

[mvallevand]

@Lehmden the issue is the time from EPG-Buddy is not local time so you get UTC time with the timezone offset. This is why removing the timezone offset works. It is either UTC or localtime with offset

Martin

[Lehmden]

Hi.
Finally we found why some people having trouble with Rytec... The source for the regions has changed without any notice. As the "old" data was/is conserved you only can see it, if you've installed EPG-Buddy from scratch after this change...

Simply replace the attached file and it should work again...

Aside this we are working on the Timezone issue with tvguide.com. Sadly they are adding wrong time to their data. XMLTV specs are expecting times in UTC with compensation. tvguide.com adds this compensation to the data directly, based on the timezone a user has chosen in it's lineup. This is not that easy to fix as it is possible a user gets data from two different timezone... Once we will have a proper solution for this there will be a new version published. That's why today only a singe file as replacement is published...

Other TV solutions are able to correct wrong times in EPG data... That's why this wasn't on the table earlier for us... 

NextPVR sadly didn't work properly with my hardware. See:
https://forums.nextpvr.com/showthread.php?tid=61857

That's why I only have a look every now and then here...