Help needed with xmltv from epg123

[garyan2]

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

Very possible. My nature is to save the user the 12 bytes per programme entry in file size and load on the consuming program.

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.

Which is why I plan on adding the time offset "+0000". That doesn't affect any of my users, but there is a greater than 0% chance that a change to NPVR will affect yours.

[SpinyGreen]

I am glad you guys are sorting this out rationally, without the finger-pointing that sometimes goes on between providers. Great support from both. Until sorted out, I have gone back to direct SD in NPVR.

As to which download format is better: I prefer the EPG123 download for a few reasons, among them:

• It works MUCH faster, and if I launch it manually, it also tells me exactly what it is doing.
  
• Some config changes require guide update. SD has a limit on the number of daily accesses, after which it imposes a 24-hour delay. Doing unnecessary connections exacerbates the issue.
  
• The EPG123 listings provide the ability to add episode numbers (ala: #1234) to news channel programs, automatically making them unique.
  

EPG123 also provides hyperlinks to channel logos, although NPVR ignores them, despite requesting icons, and checking all download types on the Artwork settings page. However, just as well, since many of the transparent .png files are basically invisible on the dark guide background. I downloaded a half-dozen favorite channels and added opaque white backgrounds and stored them in \NPVR\Media\Channels. That had the desired effect and they now appear in Emby's guide on the Roku.

[SpinyGreen]

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.

The first two lines in EPG123.xmltv are:
<?xml version="1.0" encoding="utf-8"?>
<tv date="10/16/2018 10:00:42 AM" source-info-url="http://schedulesdirect.org" source-info-name="Schedules Direct" generator-info-name="EPG123" generator-info-url="http://epg123.garyan2.net">

Line 2 would appear to be sufficient to identify this xmltv source as being one from which NPVR could reliably use the art.

I can supply the entire file for the indicated date if desired, but it looks as if a small EPG123 change will solve the time problem. (The file is about 70MB, 97 channels, 21 days, 1.75 million lines/tags)

[mvallevand]

Very possible. My nature is to save the user the 12 bytes per programme entry in file size and load on the consuming program.


Which is why I plan on adding the time offset "+0000". That doesn't affect any of my users, but there is a greater than 0% chance that a change to NPVR will affect yours.

If anyone is worried about the 12 bytes they really should use the json interface not xmltv asnit doesn't download duplicate information when the sd info doesn't change. It is far efficient especially with guide data that doesn't change often over two weeks.

Martin

[rkulagow]

• Some config changes require guide update. SD has a limit on the number of daily accesses, after which it imposes a 24-hour delay. Doing unnecessary connections exacerbates the issue.
  

[I created the JSON service.]

There isn't a limit on how many times you can access the service. There is a limit to the number of lineup changes you can make in a 24 hour period, but there's an API call that allows an application to "preview" the lineup, so that you can ensure that you've selected the appropriate one. Previews don't count against the lineup change limit.

[garyan2]

If anyone is worried about the 12 bytes they really should use the json interface not xmltv asnit doesn't download duplicate information when the sd info doesn't change. It is far efficient especially with guide data that doesn't change often over two weeks.

Martin

EPG123 works the same way... uses the same SD API. My approach was basically that XMLTV is pretty inefficient as it is. There is no reason to make it even less efficient. The time offset is not necessary and redundant, so I left it out.

[SpinyGreen]

[I created the JSON service.]

There isn't a limit on how many times you can access the service. There is a limit to the number of lineup changes you can make in a 24 hour period, but there's an API call that allows an application to "preview" the lineup, so that you can ensure that you've selected the appropriate one. Previews don't count against the lineup change limit.

Thanks for the clarification.

[snaitaz]

Good Day...I have used and still using both mc2xml and EPG123 with SD and using the local zip code (USA) or postal code (UK/Canada) when pulling data. My entire guide is populated correctly within the correct times as listed. I do note I have explicitly indicated in the batch file or withing SD to use UTC code so maybe that is why it is working correctly. When in Kentucky and Arizona for projects, I used the same programs and again they worked flawlessly. Maybe I just got lucky. Cheers!!