MceEpg2XmlTv

[whurlston]

I attempted to do this when I first started writing the downloader but I was unable to get it working. I believe there is more than just registry keys involved, or at least more than just the registry keys in the ehome\EPG settings.

[jjaomni]

any fix for that epg download error?

[markbb1]

Vista Media Center displays its EPG data correctly. Using MceEpg2Xmltv to convert to XMLTV yields a file with all times off by one hour, as though not converted for Daylight Saving Time. There are two things wrong with the times, first the times themselves are all wrong, plus all timezone offsets are +0000 and should be +0100.

Is that due to a bug in MceEpg2Xmltv?

[zehd]

Vista Media Center displays its EPG data correctly. Using MceEpg2Xmltv to convert to XMLTV yields a file with all times off by one hour, as though not converted for Daylight Saving Time. There are two things wrong with the times, first the times themselves are all wrong, plus all timezone offsets are +0000 and should be +0100.

Is that due to a bug in MceEpg2Xmltv?

I believe that if your OS has the correct Timezone settings, including daylight savings time enabled/disabled as per region, and that the OS is patched to reflect official changes that some regions make, that MCE2XML would be correct in settings the timezone offset to +0000.

If you still need the across board modifcation, UltraXMLTV can do it.

[whurlston]

any fix for that epg download error?

I have not had the time to look into it yet.

Vista Media Center displays its EPG data correctly. Using MceEpg2Xmltv to convert to XMLTV yields a file with all times off by one hour, as though not converted for Daylight Saving Time. There are two things wrong with the times, first the times themselves are all wrong, plus all timezone offsets are +0000 and should be +0100.

Is that due to a bug in MceEpg2Xmltv?

No, it is not a bug in MceEpg2XmlTv. It would be due to either a problem with your timezone configuration, the daylight savings patch not being applied to the machine, a bug in the software used to display the EPG data, or incorrect times in the MCE data. MceEpg2XmlTV gets the times directly from the EPG data in MCE and those times are UTC which is a +0000 offset. It is then up to the program that is dispaying the data to apply the necessary conversion to the timezone that is set on the machine. GBPVR does this without issue. I know there is no bug in the GBPVR code in this regard. Are your listings off in Media Center as well?

[markbb1]

I have not had the time to look into it yet.

No, it is not a bug in MceEpg2XmlTv. It would be due to either a problem with your timezone configuration, the daylight savings patch not being applied to the machine, a bug in the software used to display the EPG data, or incorrect times in the MCE data. MceEpg2XmlTV gets the times directly from the EPG data in MCE and those times are UTC which is a +0000 offset. It is then up to the program that is dispaying the data to apply the necessary conversion to the timezone that is set on the machine. GBPVR does this without issue. I know there is no bug in the GBPVR code in this regard. Are your listings off in Media Center as well?

Not a problem with timzone configuration (that I can find).
I am not aware of the "daylight savings patch" to which you refer. I will see what I can find for Vista in the UK.
No bugs in the software used to display the EPG data (XSLTV). The data from Radio Times displays with correct times.
Can't tell if the times are incorrect in the MCE data, the file is binary.
And the UK is currently in daylight time, so I would expect MceEpgXmltv to put the current offset for GMT, which is currently +0100.

Here is a sample program listing as it was converted from Vista Media Center using MceEpg2XMLTV:

<programme start="20080406020000 +0000" stop="20080406050000 +0000" channel="756898.Diva TV.192">
<title lang="en">Channel Off Air</title>
<desc lang="en">This channel is currently off air. It will resume again at 06:00</desc>
<episode-num system="mce_progid">1999999698</episode-num>
</programme>

Changing the UTC offset from +0000 to +0100 has no effect on the displayed data in XSLTV (or any other viewer I have ever used). I have tried that.

In order to display correctly, it would need to be like this:

<programme start="20080406030000 +0100" stop="20080406060000 +0100" channel="756898.Diva TV.192">
<title lang="en">Channel Off Air</title>
<desc lang="en">This channel is currently off air. It will resume again at 06:00</desc>
<episode-num system="mce_progid">1999999698</episode-num>
</programme>

Note that the time in the uncorrected version is an hour behind, plus the timezone offset is wrong for my current location.

And yes, my system settings reflect GMT at UTC + 1 hour.

As I stated in the original post, Media Center displays the guide correctly. It would show the above program as running from 3:00 am local to 6:00 am local.

Having said all that, XSLTV pretty much ignores the offset for any data stuffed into it, as do any other XMLTV viewers I have tried (Freeguide, TVGuide, Picoguide, TVHolic, and others). All the XMLTV grabbers I have used (XMLTV GUI, both Win32 and PERL versions of tv_grab_uk_rt, both Win32 and PERL versions of Zap2xml, tv_grab_au, and others) produce program times in the current timezone as well as appending the UTC offset.

In my experience, MceEpg2Xmltv seems to be producing data an hour behind what any other grabber would produce, even if MceEpg2Xmltv is working according to design.

I will see if I can find the "daylight savings patch" and give it a try. Any hints about where to look would be appreciated. I really don't want to go back to screenscraping the Virgin Media XL channels that exist in Media Center that I can't get from Radio Times.

[whurlston]

As I said, MceEpgXmltv outputs the data in UTC format with a 0 offset. If your current time is UTC + 1 hour then the app you are using should convert the UTC time to local time. This is the first issue I have been aware of because of the times being UTC.

The xmltv grabber produces the exact same UTC times using the na_dd grabber. Here is a sample produced by xmltv on my system that I used for comparison when working on MceEpgXmlTV

Code:

<programme start="20080225[color=Red]2200[/color]00 +0000" stop="20080225223000 +0000" channel="I33659.labs.zap2it.com">
    <title lang="en">WAVE 3 [color=red]News at 5[/color]</title>
    <category lang="en">News</category>
    <category lang="en">Series</category>
    <episode-num system="dd_progid">SH00776626.0000</episode-num>
  </programme>

As you can see, the news that airs at 5PM is showing a start time of 2200 or 10PM (local time was UTC - 5 hours on that date).

I can probably add an option to output the local time but I cannot give you a timeframe on when I would ever get around to it.

You can try replacing "+0000" with "UTC" and see if it makes a difference.

[markbb1]

As I said, MceEpgXmltv outputs the data in UTC format with a 0 offset. If your current time is UTC + 1 hour then the app you are using should convert the UTC time to local time. This is the first issue I have been aware of because of the times being UTC.

The xmltv grabber produces the exact same UTC times using the na_dd grabber. Here is a sample produced by xmltv on my system that I used for comparison when working on MceEpgXmlTV

Code:

<programme start="20080225[color=Red]2200[/color]00 +0000" stop="20080225223000 +0000" channel="I33659.labs.zap2it.com">
    <title lang="en">WAVE 3 [color=red]News at 5[/color]</title>
    <category lang="en">News</category>
    <category lang="en">Series</category>
    <episode-num system="dd_progid">SH00776626.0000</episode-num>
  </programme>

As you can see, the news that airs at 5PM is showing a start time of 2200 or 10PM (local time was UTC - 5 hours on that date).

I can probably add an option to output the local time but I cannot give you a timeframe on when I would ever get around to it.

You can try replacing "+0000" with "UTC" and see if it makes a difference.

I haven't used the xmltv grabber for na since before SchedulesDirect picked up the torch.
The problem with MceEpg2Xmltv is not with the format of the offset, it is the value. Plus the program start and stop times themselves. I haven't actually installed GBPVR yet, so I don't know how its EPG treats times and timezones. If GBPVR displays the data and records programs correctly, then MceEpg2Xmltv is probably best left alone. In order to get complete listings I have written some custom screenscrapers using PERL. Yesterday morning I wrote a quick and dirty PERL script for converting the MceEpg2Xmltv times and timezones to what I wanted. And then I added a line to my batch file to run that conversion. So I am good to go.
Thanks for the offer to an option to fix this, but you definitely don't need to be in any hurry.
And in case anyone is curious about what I found out about the daylight saving patch, MS says it doesn't apply to my current OS as my OS (Vista Home Premium) is up to date.

[whurlston]

No problem. I will put it on the todo list, that list is just long at the moment. There are a couple of other small changes I want to make anyway.

[markbb1]

No problem. I will put it on the todo list, that list is just long at the moment. There are a couple of other small changes I want to make anyway.

How about an option to create the XMLTV file in ISO-8859-1 encoding instead of UTF-8? When I run tv-cat to combine the MceEpg2Xmltv-created file with a file created with another grabber that outputs an ISO-8859-1 encoded file, tv_cat errs out saying that it can't combine the utf-8 file with the ISO-8859-1 file.

Besides that, when I am checking xmltv files for errors and stuff, being on a windows box I open them in notepad so I can see illegal characters that wordpad would not display. utf-8 file lines run on in notepad because it does not recognize the newline character as an end-of-line.

What do you think?