YahooXMLTv (requires Go for TV)

[ram4x4nut]

When you configure Yahoo Go TV, it asks you to "select channels you receive" as one of the steps.

Delete and re-create your lineup in Go, removing the checks from the dupe channels.

Whew! That works!

I do see the EPG being off -1 hour though. News comes on at 10, it now says 9 in the EPG.

[whurlston]

No, the only difference is "UTC" vs "+0000" offset. I've found that the time offset is reliable, but the timezone alias is not - and I didn't think UTC was a valid qualifier, since it's the default if there is no offset...?!?

Whew! That works!

I do see the EPG being off -1 hour though. News comes on at 10, it now says 9 in the EPG.

Redownload the zip file and replace the YahooXMLTv.exe. I added a command line option for offset. The supplied value will replace the "UTC". Note that it does NOT change the timestamp values, only the offset. UTC is still the default if this option is not added at runtime.

YahoXMLtv.exe offset=+0000

Also fixed an issue where Guest Actors were listed as <actor> instead of <guest>

[ram4x4nut]

Redownload the zip file and replace the YahooXMLTv.exe. I added a command line option for offset. The supplied value will replace the "UTC". Note that it does NOT change the timestamp values, only the offset. UTC is still the default if this option is not added at runtime.

YahoXMLtv.exe offset=+0000

Also fixed an issue where Guest Actors were listed as <actor> instead of <guest>

Wouldn't we have to change the supplied offset then every time daylight savings kicks in or out?

[whurlston]

Wouldn't we have to change the supplied offset then every time daylight savings kicks in or out?

Not if you use +0000. +0000 and UTC are actually the same, but for some reason when UTC is used, it results in the times being an hour off. I tested both values with and without daylight savings. Hopefully sub may know why this happens.

[ram4x4nut]

Not if you use +0000. +0000 and UTC are actually the same, but for some reason when UTC is used, it results in the times being an hour off. I tested both values with and without daylight savings. Hopefully sub may know why this happens.

Oh I see, I was thinking you meant put in what would be our current offset (-0500 for CDT) but I see what you are saying, will test and let you know how it goes!

I really do appreciate your efforts!!!

[whurlston]

Oh I see, I was thinking you meant put in what would be our current offset (-0500 for CDT) but I see what you are saying, will test and let you know how it goes!

I really do appreciate your efforts!!!

It would accept that value but I don't recommend using it. I really just added the option as a fix till I know why UTC is off.

[ram4x4nut]

Works great!!! I had the HTPC run your app at 04:15 and GBPVR pulled it in at 05:05. Everything looks great! THANK YOU!!!!!

[Jim_]

The epg utility appears to be working fine after the change , but there is one other small problem I’ve been trying to isolate.

The part that extracts the listings to xml outputs only listings that start after the current windows time. But the problem may not be visible in the guide unless you empty the epg first or use -onlyemptyepg in updateepg.bat. This leaves empty listings in the epg until the next show begins, if a movie is playing or a station is off the air for the evening there can be some very long gaps before the epg data starts.
It took me a while to track down where it was coming, from because I wasn’t sure if it was the data Yahoo was sending or the xml conversion. But reprocessing the file a few hours later gave the same results.
The only solutions I can think of off the top of my head would be including the listings that have a stop-time after the current windows time. Or including all the listings for the day of the download (preferred).
Hope this helps.
Jim

[Jim_]

Works great!!! I had the HTPC run your app at 04:15 and GBPVR pulled it in at 05:05. Everything looks great! THANK YOU!!!!!

ram4x4nut, you could try disabling the windows index service and see if that helps.
Instructions on doing so are available by pressing F1 at the desktop, or on google.

whurlston,
I’m looking at this one also. I don’t know if the windows index service was running a normal scan at the same time or if it launched to scan the xml file as it was being created. I did end up closing the yahooxmltv.exe utility after 40-minutes. After closing the util, the epg update proceeded normally (the xml was created and loaded).
As a test I excluded xml files from being indexed and updating the epg from the tray icon, it worked without a problem. I’ll try to verify what I found, but I have a feeling the index service accessing the xml file (as it is created) may not allow the util to close the file.

[whurlston]

The epg utility appears to be working fine after the change , but there is one other small problem I’ve been trying to isolate.

The part that extracts the listings to xml outputs only listings that start after the current windows time. But the problem may not be visible in the guide unless you empty the epg first or use -onlyemptyepg in updateepg.bat. This leaves empty listings in the epg until the next show begins, if a movie is playing or a station is off the air for the evening there can be some very long gaps before the epg data starts.
It took me a while to track down where it was coming, from because I wasn’t sure if it was the data Yahoo was sending or the xml conversion. But reprocessing the file a few hours later gave the same results.
The only solutions I can think of off the top of my head would be including the listings that have a stop-time after the current windows time. Or including all the listings for the day of the download (preferred).
Hope this helps.
Jim

Yeah, I noticed this too. It's my app that's doing it. After I download the data, I have to basically search the listings for anything between two dates/times. I search from "now" to the "now+days" passed to the app (14 for default). The problem is that the search does not return anything that is currently playing. I will change it to search from now-5 hours and reupload it.