Help needed with xmltv from epg123

[SpinyGreen]

NextPVR was working OK using JSON download from Schedules Direct. However, I also use EPG123 to download from SD to supply the guide for Windows Media Center on a couple of computers. I discovered this week that it also will create an XMLTV format file. In order to minimize the SD downloads, I decided to have EPG123 add the XMLTV output and then switched NPVR to use that file for its guide updates.

I managed to accomplish the changes with a fairly small amount of cursing, and it has populated the guide from the xmltv file.

However, there is one gigantic problem. The guide is populated using UTC time! I live in Arizona, USA. My time zone is UTC-0700. A Show that plays at noon in this time zone appears in the guide at 7:00 PM, which is UTC time. All of my series recordings have gone belly up. (The date and time at the top of the NexPVR window displays the correct date and time, so the issue is not my computer settings.)

How do I coerce NPVR to populate the schedule using my time zone? Is there some setting I must make in the NPVR config? Or is this an EPG123 issue?

[Graham]

is this an EPG123 issue?

Yep.

[SpinyGreen]

Yep.

Congratulations. A new record for "support" brevity.

[rkulagow]

In order to minimize the SD downloads, I decided to have EPG123 add the XMLTV output and then switched NPVR to use that file for its guide updates.

[I run the JSON service on Schedules Direct.]

Unless you're bandwidth limited, don't worry about it. Just don't let EPG123 and NextPVR download at the same time, otherwise they'll be invalidating the other's access token.

[Graham]

Congratulations. A new record for "support" brevity.

I can do better.

Is there some setting I must make in the NPVR config?

Nope.

Or is this an EPG123 issue?

Yep.

I use mc2xml to create an xmltv file from Schedules Direct ... http://mc2xml.hosterbox.net/

[sub]

Honestly, you'd be better off just leaving NextPVR using the SD api directly, rather than going via a xmltv. You get more data from SD this way, and better artwork matches etc.

[garyan2]

Yep.

I'll top this with "Nope." And if you bother to care...

The xmltv.dtd states that:

Code:

All dates and times in this DTD follow the same format, loosely based
on ISO 8601. They can be 'YYYYMMDDhhmmss' or some initial
substring, for example if you only know the year and month you can
have 'YYYYMM'. You can also append a timezone to the end; if no
explicit timezone is given, UTC is assumed. Examples:
'200007281733 BST', '200209', '19880523083000 +0300'. (BST == +0100.)

The key message being "if no explicit timezone is give, UTC is assumed." This is exactly what EPG123 provides... the UTC time with no timezone given.

BUT... NPVR does not consider a start/stop time in "yyyyMMddHHmmss" format being UTC, it brings it in as local time. Peeking into NPVR code, in the parseToUTC() function, you will find:

Code:

DateTime dateTime;
if (text.Length == 14)
{
    dateTime = DateTime.ParseExact(text, "yyyyMMddHHmmss", null);
}
else
{
    dateTime = DateTime.ParseExact(text, "yyyyMMddHHmm", null);
}

A .ParseExact, in the absence of a DateTimeStyle settings, will assume local. If you want it to assume UTC, then it would need to be:

Code:

DateTime dateTime;
if (text.Length == 14)
{
    dateTime = DateTime.ParseExact(text, "yyyyMMddHHmmss", null, System.Globalization.DateTimeStyles.AssumeUniversal);
}
else
{
    dateTime = DateTime.ParseExact(text, "yyyyMMddHHmm", null, System.Globalization.DateTimeStyles.AssumeUniversal);
}

Now the question is, is that intended? Does NPVR want to go against the DTD and make any start/stop time without timezones identified be considered as local? Maybe.

My point is: EPG123 is doing nothing wrong and is true to the requirements. The question is, is this a flaw in NPVR code? or is it intentional? Either way, next release of EPG123 will append " +0000" to the start and stop times in order to work around it.

[garyan2]

Honestly, you'd be better off just leaving NextPVR using the SD api directly, rather than going via a xmltv. You get more data from SD this way, and better artwork matches etc.

That would be my default position as well, but I just did a quick compare between NPVR using Schedules Direct and NPVR using an XMLTV from EPG123 (with Schedules Direct), and the guide is nearly identical to include the selection of the artwork. I would say in this case, there is no loss in quality using the XMLTV versus the native SD support.

The only differences I noted was EPG123 adds a category/genre to each program ("Series","Movie","Sports","News","Kids"... which is from being designed for WMC).

EDIT: I did just see another difference. Though the "producers" are included in the XMLTV file, they are not included in the guide program detail. The native guide with SD does show the "executive producers".

[Graham]

I'll top this with "Nope." And if you bother to care...

I apologise to everyone everywhere ...

I use mc2xml to create a xmltv file from Schedules Direct and I made assumptions based on my own experience ... There is no relevant setting in NextPVR ... I assumed that the OP had missed a switch or setting in EPG123.

[sub]

My point is: EPG123 is doing nothing wrong and is true to the requirements. The question is, is this a flaw in NPVR code? or is it intentional? Either way, next release of EPG123 will append " +0000" to the start and stop times in order to work around it.

I'm out of the country for the next week, so no way to check it right now, but if someone wants to supply me an example EPG123 xmltv file next week, I'm happy to check it with NextPVR and fix if necessary. I've not seen any other reports of this issue, but it's possible that no other common xmltv provider is producing listings with this same date format, so users haven't run into it before.

I do wonder if it will break stuff though, because I'm pretty sure we have encountered xmltv files that specify listings in local time if the timezone is not specified.

and the guide is nearly identical to include the selection of the artwork.

NextPVR will only use SD's artwork interface if the users listings are configured to use SD as the EPG source. Otherwise it falls back to name searches using thetvdb and tvmoviedb, which usually works ok, but sometimes ends up with the incorrect artwork (when it ends up with artwork for a similarly named show). When it uses the SD artwork interface, it always gets the correct show artwork.