SchedulesDirect major changes

[johnsonx42]

that particular IP isn't working for me tonight, but 54.210.29.17 does. I don't know what the final IP will be, as they are still calling this a beta test. As to how long it will be around, I suspect it'll be quite awhile; they went to significant trouble to create the Data Direct replacement service, I doubt they did it just to abandon it quickly. Once all the programming work is done, keeping the server running should be trivial.

as far as I know no one has tested the DD replacement service with GB-PVR, but it ought to work.

[johnsonx42]

now schedules direct has posted a new IP address, this one should be somewhat more permanent:

Code:

54.85.117.227  docs.tms.tribune.com webservices.schedulesdirect.tmsdatadirect.com

also, Schedules Direct is trying to get TMS/Gracenote to point the A records for those two hosts to the SD-DD server (or replace the A records with CNAME records, same effect), so it may all happen seamlessly without the users doing anything. (but they note that there's a lot of politics involved, so it may not happen)

today, using this new IP address, I'm getting much better response when downloading the lineup(s) in Settings->Channels->Details, just a few seconds. The actual EPG download still takes awhile, but that shouldn't be an issue as NPVR allows a fairly long timeout. So, NextPVR 3.2.9 appears to be fully functional with the SD-DD replacement server.

[ram4x4nut]

Thanks! I will use that new IP and let you know if it is working inside GBPVR.

[christheman]

now schedules direct has posted a new IP address, this one should be somewhat more permanent:

Code:

54.85.117.227  docs.tms.tribune.com webservices.schedulesdirect.tmsdatadirect.com

also, Schedules Direct is trying to get TMS/Gracenote to point the A records for those two hosts to the SD-DD server (or replace the A records with CNAME records, same effect), so it may all happen seamlessly without the users doing anything. (but they note that there's a lot of politics involved, so it may not happen)

today, using this new IP address, I'm getting much better response when downloading the lineup(s) in Settings->Channels->Details, just a few seconds. The actual EPG download still takes awhile, but that shouldn't be an issue as NPVR allows a fairly long timeout. So, NextPVR 3.2.9 appears to be fully functional with the SD-DD replacement server.

Thanks! I just got in, so I will try this too.

[christheman]

now schedules direct has posted a new IP address, this one should be somewhat more permanent:

Code:

54.85.117.227  docs.tms.tribune.com webservices.schedulesdirect.tmsdatadirect.com

also, Schedules Direct is trying to get TMS/Gracenote to point the A records for those two hosts to the SD-DD server (or replace the A records with CNAME records, same effect), so it may all happen seamlessly without the users doing anything. (but they note that there's a lot of politics involved, so it may not happen)

today, using this new IP address, I'm getting much better response when downloading the lineup(s) in Settings->Channels->Details, just a few seconds. The actual EPG download still takes awhile, but that shouldn't be an issue as NPVR allows a fairly long timeout. So, NextPVR 3.2.9 appears to be fully functional with the SD-DD replacement server.

Okay, I think I have found a suitable replacement for mc2xml. It appears that at least one of its authors, rmeden, is involved in the Schedules Direct beta testing. So that is a good sign.

http://sourceforge.net/projects/xmltv/fi...tv/0.5.65/

There is much more to this than there was to mc2xml, but for the user who wants to continue using a separate app to accomplish the download for whatever reasons, this seems to work well. It is slower for me than mc2xml, but I am a patient person and just glad to see something else that is being actively developed to specifically work with SD, as the last version of mc2xl2 (1.2) breaks with the user authentication step when using the new IP address.

I installed it by downloading the Windows zip file, complete with the executable needed to run on a Windows system. Then I followed the instructions in the Readme.txt file. I am in North America, so the command line parameter I used was "tv_grab_na_dd" (North American Schedules Direct subroutine)

Below is the batch file I built to run it

Code:

REM xmltv.exe tv_grab_na_dd --configure



xmltv.exe tv_grab_na_dd --offset -2 --days 15 --config-file=.xmltv\laptop.txt --output=xsltv\tv.xml

"C:\Program Files\Mozilla Firefox\firefox.exe" xsltv\tv.html

You can use the command REM'd out first line to setup the initial configuration. You will be prompted for your SD user name, option to not store password, and your password. As you type in your password, you will not see anything on the screen, not even asterisks. It cannot be copied and pasted in, it must be typed in. The SD username and password are stored in plain text in the config file, unlike the encoded one with mc2xml.

Finally the user will get the chance to choose an entire lineup, or select channel-by-channel (similar to the mc2xml.chl file). Only one SD lineup can be used per config session and config file, but multiple config files can be referenced with a .bat file, and only one download. Just create the first one and then change its file name, then create the next and so forth (see Readme.txt for more).
(I renamed my lineup config file here to "laptop.txt".)

The config file will be located by default in the "\.xmltv" subdirectory once it is created.

Below are the initial results I got when I tried it against mc2xml:

-Schedules Direct lineup with 15 movie channels,

XMLTV output with default HOSTS file @13 days (13 + 2 offset days)
4.25 MB download size, 11 sec download time, 2:24 total processing time

XMLTV output with NEW IP address in HOSTS file @13 days (13 + 2 offset days)
3.65 MB download size, 9 sec download time, 2:07 total processing time

MC2XML output with default HOSTS file @6 days (6 + 2 offset days)
38 sec total processing time. (probably about a minute and a half if compared to XMLTV workload)

MC2XML output with NEW IP address in HOSTS file
**does not get past password authentication step**


Finally, here is my batch file again

Code:

REM xmltv.exe tv_grab_na_dd --configure



xmltv.exe tv_grab_na_dd --offset -2 --days 15 --config-file=.xmltv\laptop.txt --output=xsltv\tv.xml

"C:\Program Files\Mozilla Firefox\firefox.exe" xsltv\tv.html

In that last couple lines of code, I am writing to and opening the output file in Firefox with a secondary program called "XSLTV", which can be found here
http://ericandchar.com/xsltvgrid/

I unzipped that into my XMLTV directory, so it is now a subdirectory. The name "tv.xml" is necessary for that program.

This last part is just to display it in a nice grid.

I haven't tried this out on my NPVR computer yet, but it looks like it should work with a few minor adjustments to file and directory names.

[johnsonx42]

Glad you have that sorted, and thanks for posting your configuration. I was planning to post here that XMLTV is the approved method of downloading SD data to an XML file; unfortunately it is a little more complicated to setup than MC2XML.

By the way, you have a typo in your post, I'm pretty sure you meant "MC2XML" here:

Code:

XMLTV output with NEW IP address in HOSTS file
**does not get past password authentication step**

[christheman]

Yikes, bad copy and paste job. Yeah, I just wanted to type all that out while it was still fresh in my mind...lol.

[christheman]

P.S. The processing times may be somewhat influenced by the slower speed of my Pentium 3 laptop (good for dragging out to coffee shops). :>)

[christheman]

Okay, I just had a chance to get this running on my NPVR machine, and honestly I cannot tell the difference between the two different grabbers when I force an update with the "Update EPG" button, which is nice. This is on a significantly faster machine (a Quad Duocore).

Here is my .bat file for the NPVR machine. The default lineup config filename was renamed to ".xmltv\npvr.txt". Also the output filename was changed to "TVGUIDE.xml", presumably to follow NPVR rules.

Code:

REM xmltv.exe tv_grab_na_dd --configure

xmltv.exe tv_grab_na_dd --offset -2 --days 15 --config-file=.xmltv\npvr.txt --output=TVGUIDE.xml

The .bat file itself is named "UpdateEPG.bat", presumably to follow NPVR rules. Also I went into NPVR and remapped the channels. Changing the directory reference in the Config.xml file wasn't enough.

I then updated the HOSTS file and added the NEW IP address.

I tested it by clicking on the "Empty EPG" button, then verifying that the NEWA TV Guide was empty. Then I clicked on "Update EPG", and confirmed that the guide was back. So far so good it seems. It looks like NEWA has been repopulated correctly.

[johnsonx42]

Also the output filename was changed to "TVGUIDE.xml", presumably to follow NPVR rules.

there are no rules in that regard; your xmltv file can be named whatever you want

The .bat file itself is named "UpdateEPG.bat", presumably to follow NPVR rules.

well yes, that is the the file it calls to initiate an EPG data download. some people just have their UpdateEPG.bat call some other batch file in another directory.

Also I went into NPVR and remapped the channels. Changing the directory reference in the Config.xml file wasn't enough.

the reference in config.xml just tells it what .xml file to read first the next time you go to map channels. if you had given your xmltv file the same name and put it in the same location, it might have worked without remapping... it depends on whether MC2XML and XMLTV output the channel id info that NPVR matches on in the exact same way.