I-xmltv >Incremental XMLTV download utility

[Jim_]

If the –addignore batch worked there isn’t any need to check the MDAC version.
My rectracker.mdb also needed to be sparked to life with the –addignore command before it would work normally.
GBPVR lists MDAC 2.6 as a requirement on the homepage, but it’s the only dependency RecTracker has (that I know of) that isn’t included with a normal GBPVR installation.

Just wanted to make sure I covered every possibility in the post above.
If MDAC 2.6 or higher is installed, and GBPVRBackendCommon.dll & GBPVRPublic.dll exist in the same location, RecTracker will add and remove listings from its mdb as a standalone program.
Jim

[cginzel]

Jim,

For some reason my TV listings are still off by one hour... I'm in the centeral time zone. For example, for the New Yankee Workshop should appear on the TV Guide as 7:30am, but in the XML (see below) it is listed as 123000 UTC which -5 is 7:30, but on my guide it is listed as 6:30 so it's acting like i'm on central standard time... how do I change this? where is the setting?

Thanks,
-Charles

<programme start="20060429123000 UTC" stop="20060429130000 UTC" channel="I12011.labs.zap2it.com">
<title lang="en">New Yankee Workshop</title>
<sub-title lang="en">The Folding Screen</sub-title>
<desc lang="en">Mahogany folding room screen.</desc>
<date>20040117</date>
<category lang="en">Educational</category>
<category lang="en">How-to</category>
<category lang="en">House/garden</category>
<category lang="en">Series</category>
<episode-num system="dd_progid">EP003112.0262</episode-num>
<episode-num system="onscreen">1602</episode-num>
<subtitles type="teletext" />
</programme>

[cginzel]

Now that i think about it, the UTC entry in the XML is correct, so is this really an issue with GBPVR importing the XML?

On a related subject, i have two 150's and each has an identical capture source defined (before it was Zap2It, now it is this XMLTV file). Does GBPVR know this and run the update process only once? I realize it could be possible that the capture sources would be differnet for each card, but I was wondering if this is a contributor to the bandwidth load Zap2It is seeing. Now if i can get I-xmltv to work with GBPVR correctly, I realize I'm only hitting Zap2It once for both cards, but i was just wondering if GPBVR did the update twice... and also, when i do a manual UpdateEPG using the GBPVR configuration tool, do i need to update each card as well?

[Jim_]

Hi Charles,
Is that a listing from your TVGuide.xml?
The final TVGuide.xml output file shouldn’t have any “UTC” entries if you’re using the latest version of I-xmltv, they should all be converted to +0000.
Could you check your UpdateEPG.bat in the GBPVR folder to verify that it has the following lines near the very bottom?

Code:

:common
REM *** The next two lines replace "UTC" TVGuide.xml entries with "+0000" ***
I-xmltv %OutputFileName%
MOVE I-XMLTV.XML %OutputFileName%
REM *** End GBPVR "UTC" Fix ***

Also the I-xmltv.log file (in the I-xmltv folder) should log that the UTC entries were fixed.

Code:

Today 20060429 04:07:13 (This month has 30 days)
1.xml 20060428  Requesting update for today 20060429 & tomorrow
3.xml 20060501  Is now >> 2.xml
4.xml 20060502  Is now >> 3.xml
5.xml 20060503  Is now >> 4.xml
6.xml 20060504  Is now >> 5.xml
7.xml 20060505  Is now >> 6.xml
8.xml 20060506  Is now >> 7.xml
9.xml 20060507  Is now >> 8.xml
10.xml 20060508  Is now >> 9.xml
11.xml 20060509  Is now >> 10.xml
12.xml 20060510  Is now >> 11.xml
13.xml 20060511  Is now >> 12.xml
[color=Red]Replacing UTC entries in XMLTV.XML with +0000 >> I-XMLTV.XML[/color]

Thanks
Jim

[Jim_]

Now that i think about it, the UTC entry in the XML is correct, so is this really an issue with GBPVR importing the XML?

Yes and no. There are lots of different xmltv formats, but UTC wasn’t used by any of them until we found this one. sub may add support for UTC in future releases but it's a very easy fix and not a big deal.

On a related subject, i have two 150's and each has an identical capture source defined (before it was Zap2It, now it is this XMLTV file). Does GBPVR know this and run the update process only once? I realize it could be possible that the capture sources would be differnet for each card, but I was wondering if this is a contributor to the bandwidth load Zap2It is seeing. Now if i can get I-xmltv to work with GBPVR correctly, I realize I'm only hitting Zap2It once for both cards, but i was just wondering if GPBVR did the update twice... and also, when i do a manual UpdateEPG using the GBPVR configuration tool, do i need to update each card as well?

You know, I'm not quite sure because I have two different systems with one capture source each. Sub could answer this question better but I’ll give it a shot.
Someone correct me if I'm wrong but from my understanding the pre v0.96.08 versions hit Zap2It one time for each capture source, even if they downloaded the same listings. The new version tries to re-use the EPG data if it's the same for each capture source. But I'm not sure if it works differently when "complete EPG reload" is selected or not.
I'm guessing that UpdateEPG is called one time, then both capture cards are updated using the same xmltv data, but I could easily be wrong on this.
I'm also guessing that both sources would need to be updated if you do it manually with the config utility.

I really doubt you'll have any problems with the times being off once your xml shows +0000 instead of UTC. I'm in the same time zone and everything has worked fine for over a month now.

If you still have problems when TVGuide.xml has +0000 entries let me know. I have a version of I-xmltv that can shift the listing times upto 23 hours in either direction. I added the feature because I use ZGuide TV on occasion for its movie star rating search, Z-Guide doesn’t automatically do the time zone offsets and I didn’t want to hit Zap2It again just for it.

[cginzel]

Guess what Jim? You aren't going to believe me, but the answers to all of those questions is yes!

That was a snippet from the TVGuide.xml In fact, there are several UTC entries in that file.

Here are the last to entries in the log that include the replacing notice:

Today 20060423 21:57:43 (This month has 30 days)
1.xml 0 Requesting update for today 20060423 & tomorrow
Replacing UTC entries in TVGUIDE.XML with +0000 >> I-XMLTV.XML

Today 20060423 22:05:40 (This month has 30 days)
1.xml 20060423 EPG for today & tomorrow is upto date.
2.xml 20060425 Is now >> 2.xml
3.xml 20060426 Is now >> 3.xml
4.xml 20060427 Is now >> 4.xml
5.xml 20060428 Is now >> 5.xml
6.xml 20060429 Is now >> 6.xml
Replacing UTC entries in TVGUIDE.XML with +0000 >> I-XMLTV.XML

Bu it doesn't seem to do the replace everytime it runs, for example, the last complete entry is:

Today 20060429 05:05:26 (This month has 30 days)
1.xml 20060428 Requesting update for today 20060429 & tomorrow
3.xml 20060501 Is now >> 2.xml
4.xml 20060502 Is now >> 3.xml
5.xml 20060503 Is now >> 4.xml
6.xml 20060504 Is now >> 5.xml
7.xml 20060505 Is now >> 6.xml
8.xml 20060506 Is now >> 7.xml
9.xml 20060507 Is now >> 8.xml
10.xml 20060508 Is now >> 9.xml
11.xml 20060509 Is now >> 10.xml
12.xml 20060510 Is now >> 11.xml
13.xml 20060511 Is now >> 12.xml

And the date of my I-xmltv.exe is 4/17/06 10:42am

Last lines of the UpdateEPG:

:common
REM *** The next two lines replace "UTC" TVGuide.xml entries with "+0000" ***
I-xmltv %OutputFileName%
MOVE I-XMLTV.XML %OutputFileName%
REM *** End GBPVR "UTC" Fix ***

CD "C:\Program Files\Devnz\GBPVR\"
gbpvr -OnlyEmptyEPG
IF %FirstRun% == 1 GBPVR -OnlyUpdateEPG


:end

[cginzel]

Jim,

When I manually run "I-xmltv TVGuide.xml" at the command line, I get:

I-xmltv v06.4.17
Replacing UTC entries in TVGUIDE.XML with +0000 >> I-XMLTV.XML

But when I manually try the move next I get the following:

C:\I-xmltv>MOVE I-XMLTV.XML TVGuide.xml
Overwrite C:\I-xmltv\TVGuide.xml? (Yes/No/All):

Is it possible that the move command in the batch isn't working because the original TVGuide.xml file still exists in the directory?

Maye I should just add a DEL %OutputFileName% before the MOVE...

[Jim_]

That's strange, I may have to do some thinking on this and get back to you.
I don’t quite understand why it would only replace the UTC entries some times.
Could you try running this batch file (several times) in your I-xmltv folder for me, and report if there are any errors? move will prompt before the overwrite if you use if from the command prompt, but it should just do it when used in a batch file.
I've used the utility on my three 2k systems and one xp system without any problems, but this is why I posted it in the developer’s forum! You never know what can turn up.



test.bat

Code:

I-xmltv TvGuide.xml
move I-xmltv.xml TVGuide.xml
pause

[cginzel]

You're right Jim! When run from a batch file it just does a replace. I can't explain it then. The log file shows that it isn't doing the UTC processing each time for some reason... i've gone over the batch file over and over and can't see a flaw that would stop it from proceeding... i wonder if I-xmltv is not returning to the batch file... is that even possible? is there a return code that halts batch file processing? maybe it is failing? can you add a debug logging option to I-xmltv that would indicate that that I-xmltv has completed successfully?

[Jim_]

The thing is, I-xmltv will write to the log file even if TVGuide.xml doesn’t exist, so it’s telling me that I-xmltv isn’t being called for the UTC conversion (some times) for some unknown reason.

I have a feeling that xmltv.exe is dumping during the “tv_cat” command for some reason, when it joins the sequential xml files into the single TVGuide.xml. That actually is the most likely because it can happen if a xml file fails to download or the download is corrupt.
I’ll do a little checking to see if there is a way to log if xmltv is failing at that point.

You probably haven’t watched the individual xml files, but do 1-13 exist, and are all of them about the same size other than 1.xml that is a 2-day download? Is your internet and Zap2It connection usually solid?

Jim