Why is EPG dowloading times from 2012?

[johnsonx42]

by the way, things like this are why we often encourage use of other (legal) epg sources like Schedules Direct. Schedules Direct always works, and is very easy to setup. MC2XML has been plagued with these sorts of problems over the years; sure most of the time it works fine, but EPG data is the sort of thing you just don't want to have to think about. Every now and then when my SD subscription expires, I think about going back to MC2XML and then I remember threads like this.

[OTAjunkie]

Theoretically then, if you specify -d 1080, you'd get data from 12-11-12 to 1-25-13 (except that MC2XML might consider -d 1080 to be crazy talk).

well for the helluva it, I tried that,,,,, no change.

what isn't clear is where this 12-11-12 start date is coming from?

Damn Mayans!!

Something wrong at MS/Zap2It!? Some change at MS/Zap2It! that MC2XML is misinterpreting).

Something at MS, I believe. If you use ZAP2XML, Microsoft.com is removed from the equation and all data is retrieved. mc2xml will run and dnld but not all channels will be listed.

@zeb
I always use notepad to edit/view my xmltv listing files, it's a little slow to open but I find it more stable

@johnsonx42
When I had a SD subscription I used mc2xml to scrape it and got more info.

[epelic]

I had the same problem around Christmas. I contacted the mc2xml site owner/author via email. He instructed me to use the -s parameter to specify the offset from the current time (when the program is executing). This corrected the problem for me.

My theory on why it stopped working is that prior to it stopping to function (and before I added the -s parameter) the older program information was being regularly removed from the source. Thus, there was only a few weeks of program listing available ... so the download worked because the only information available kept moving forward. Then, this practice was stopped, so the oldest information kept getting older and the 2 week window of information became static. I have no way to know if this is actually correct, but it is the only theory I have.

Here is the contents of the batch file (located in the c:\program_files directory) I use:

cd "c:\program_files\mc2xml"
mc2xml.exe -d 168 -s -1 -o TVGUIDE.xml

I am a user in the United States.

[Zeb]

@OTAjunkie: Thanks for the tip about using Notepad to view xmltv files. I was quite relieved to find that my TVGUIDE file does NOT contain listings dating back to mid-December. For one particular channel:

First listing: <programme start="20130113180000 -0600" stop="20130113183000 -0600"
Last listing: <programme start="20130127170000 -0600" stop="20130127180000 -0600"

After my abortive and probably flawed attempt to test the revised code on wiki's mc2xml page featuring -s parameter, I reverted to tried-and-true UpdateEPG.bat code suggested by whurlston in a December post and obtained the new TVGUIDE file referenced above. I'm now reverting to my same old tune: mc2xml works fine with the right batch file - although I'm sure you are right regarding Canadian guide listings or the lack thereof. BTW, I vaguely recall a post claiming that similar problems had occurred one year ago, but can't remember what thread it was in.

@epelic: Thanks for posting! Your post seems to confirm that -s is the salvation of -d 168, and that putting the folder in program files is not the cause of this problem (although probably not recommendable).

[whurlston]

it looks to me like the problem is that MC2XML suddenly thinks the "start date" for the data is 12-11-12. If you don't specify the -d parameter, it downloads everything from 12-11-12 to the current date plus 2 weeks. If you do specify the -d parameter, it measures the number of hours of data starting from 12-11-12. This means -d 336 isn't exactly the same as no -d at all, though it should be. Theoretically then, if you specify -d 1080, you'd get data from 12-11-12 to 1-25-13 (except that MC2XML might consider -d 1080 to be crazy talk).

what isn't clear is where this 12-11-12 start date is coming from? Something in the MC2XML code, akin to the expiration dates that have been hard-coded in the past? Something wrong at MS/Zap2It!? Some change at MS/Zap2It! that MC2XML is misinterpreting?

The problem should be a direct result the data on the MS servers. MS pulls the data from TMS (parent company of Zap2It) and caches it on their servers. Media Center then pulls the data from the MS servers. MC2XML uses the same methods as Media Center to pull the data from the MS servers. If someone who is having issues with MC2XML and also has Media Center configured, it would be worth checking to see if Media Center has current listings or not. If it does, MC2XML is the problem. If Media Center is showing no listings, the data from the MS servers are the issue.

I agree about using Schedules Direct. They also get their data from TMS, the same place MS does.

[mediamad]

MCE data is fine. Using Zap2It as the source works fine as well. -s seems to tame problem in MC2XML

[whurlston]

Can you PM me your zip and the lineup you are using for my testing purposes?

[merc82]

I'm coming late to this thread but I'll add my findings. I'm using Canadian listing and I found mc2xml with only the -d option fails to download anything. Just running mc2xml alone works; or you can use -d if you also use -s. I'm successfully using mc2xml.exe -d 192 -s -1.