EPG update error

[aibo]

Version 1.4.7 - XP Pro SP3

Your EPG sources does not appear to be configured correctly. Please check the EPG Source Settings and try again. System.Net.WebException: The remote server returned an error: (505) Http Version Not Supported.

I disconnected the PC from internet for about 10 days. When I reconnected it, EPG update failed. I have reinstalled GBPVR and disabled firewall.

Please help.

[aibo]

I tried many times to update and it worked once. Could it be a problem with schedule direct? I will monitor if the problem continues.

[Firetoad]

I am having the same error ever since the SD outage over the last day or two. I have submitted a support post on their form regarding this issue but am still waiting for mod approval of the post and a reply.

[mikeh49]

Here is some information I got from SD after submitting a network capture of the error:

First let me discuss how things are *supposed* to work.
HTTP POST sent with request
HTTP 401 (authorization required) received
HTTP POST sent with user/pass
data

On my system ( Windows 7, app xmltv/tv_grab_na_dd) The first POST is 949 bytes, the second is 1309. Neither are fragmented.
Each HTTP POST call is it's own TCP session.

All three of you display the following differences:
the HTTP POSTs don't fit in a single packet and are split into two.
HTTP 401 is received before second half of first HTTP POST is sent!
second HTTP POST continues TCP session from first POST
If you use Wireshark's "Follow TCP Session" and look at the output, it's really hard to find the second POST. TMS may have the same problem.

What I think is happening is TMS sees the second half of your first POST as the new request. It fails with a 505 because it doesn't start with a HTTP header (and why should it? it's the second half of a request).

Questions:
1. What operating system and application are you guys running?

Solutions:
1. Modify the OS to set your MTU over 1350. That will prevent fragmentation.
2. Modify the app to send each HTTP POST as it's own TCP session.
3. Get Tribune to not respond with a 401 if the packet ends with a continue command (not sure if that's possible)

I think #2 is actually a bug... I'm not familiar with the details of the SOAP, but I bet new requests should be in it's own TCP session. Especially if an error is returned.

I tried their suggestion of increasing the MTU setting, but it didn't help. They are working on it, but it's not clear when they will have a fix. Hopefully we won't need a change to GBPVR.

Any thoughts on this, Sub?

[mikeh49]

Latest update from SD support:

I took another look and the TCP/IP packet wasn't broken up by the IP layer, the decision to split into multiple packets is somewhere in the libtary GB-PVR uses for HTTP or SOAP.

This definably looks like something that only affects GB-PVR....

Putting the second POST in the same session as the first is called HTTP piplining and is fine for browsers, but not recommended for SOAP (one reason is what we're seeing).

Hopefully Tribune will fix on their end, otherwise we'll need a GB-PVR patch.

Looks like we need input from Sub now. I'm not sure how much support he's willing to provide for GBPVR, since NPVR is now on the loose.

Note that mc2xml can access SD data, so that may be the way to go until Sub can fix, assuming it does not have the same problem. Looks like some work to setup, but it's described in the wiki.

[sub]

Unfortunately, there is nothing I can do about it. I'm no longer able to build patches for GBPVR - I no longer have the older versions of the development tools on my machine, which were used for building GBPVR. Sorry - this means there will be zero changes to GBPVR in the future.

I remember a very small handful of people having this problem over the years. A couple fixed it changing their MTU setting. A couple had to switch to using xmltv.org's grabber, which contained some workaround for this Tribune problem.

That said, the symptoms described in the past were slightly different, and related to the users only get a single day of listings rather than the 14 or so they were requesting (but the MTU change was what they suggested at the time).

[johnsonx42]

I'm using MC2XML to grab Schedules Direct data for NPVR. I just checked, and am continuing to get good data over the last few days.

MC2XML works fine, and is pretty easy to set up. In absence of a mc2xml.dat, it brings up a GUI to let you select your options and then builds the mc2xml.dat for you. On subsequent runs it just downloads the data and puts it in xmltv.xml; then all you do is point GB-PVR (or NPVR) to that file. Finally, MC2XML.exe goes in your updateepg.bat file.

If there's no fix from Tribune (schedules direct is basically just a proxy server for Tribune), MC2XML will be your fix.

[mikeh49]

Thanks for the update Sub.

I've done some testing and the xmltv based grabber works fine. So, it's off to configure that. I have 3 lineups for 4 tuners, so I need to figure out how to handle that. I'm assuming/hoping that GBPVR can accept a different xml filename for each lineup. I knew I setup the test box for something.

[htewam]

Ughhh... just saw that my last successful SD update occurred on July 6th... didn't notice it until I was paging through the Guide and saw that I don't have too many days of schedule left. XP SP3 similar to Aibo. Seems like SD has done something on their side since my config has been stable for more than a year.

Right now NPVR is not at option since I'm heavily analog & MVP based... hope someone (maybe SD) comes up with a fix or I will need to pull the plug and move on to another solution.

[johnsonx42]

hope someone (maybe SD) comes up with a fix

Just so you understand, SD really can't fix anything in this case. They simply act as a proxy or access portal to Tribune Media's servers; the change that broke things was done by Tribune and so they'd have to fix it. I suspect they aren't likely to fix it though, because it only breaks one free app that is no longer supported by it's author. I guess it depends on how much SD hears about this, and how much pull SD has with Tribune (very little I suspect).

or I will need to pull the plug and move on to another solution.

Right, because no one has found any other way to use SD data with GB-PVR. Sub mentioned something about an xmltv grabber, and I pointed out that I use MC2XML... but no, none of that will help at all.