XMLTV Plugin not working with V4

[mobby]

Hi,
I was using 2.2 for ages with the XML TV plugin as described by an old thread (the thread described how to get the XMLTV plugin to work with Sage and also how to configure the Radio Times XML Grabber to write the epgdata to sage). I have recently upgraded to Version 4 of sage. I thought XMLTV was working until i started to notice that my favourites scheduling was getting smaller. Yesterday I could see that i was getting to the end of the epgdata and although I had tried updating the schedule with the RT Grabber the epg is not updating. The epgdata.xml seems to have the full 14 days worth but sage is not updating. I have tried restarting, diabling/enabling a channel to get sage to update whilst it is running and so far still no luck.

Does anyone have any ideas how to sort this?

Also has anyone else got the same setup as me? i.e. Sage 4, RT Grabber (2.20) and XMLTV Plugin? Are you having problems with the RT Grabber not being able to write to epgdata.xml whilst sage is running? If you stop sage, then update it then the file can be written (I am guessing this is due to sage locking the file or the RT Grabber is trying to do something which is clashing with sage even though sage is not locking the file). Sage 2.2 did not cause this error.

I am actually a java developer by profession so I have resorted to looking at the xmltv plugin to either make it more tollerant of errors and/or see if I can see any general problems.

Thanks for reading,
mobby

[Lucas]

I run the same setup and everything is fine.

The only difference is I run nielms multi-xml variation of the plugin.
My xlm files are named 1.xml, 2.xml etc.

[nielm]

Originally Posted by mobby

Does anyone have any ideas how to sort this?

Have you updated Java recently -- check that xerces.jar is in the JRE/lib/ext directory, (Or better still, put it in SAGETV/Jars)

Try running the plugin tester (see the XMLTV page on the wiki) to check to see if the data is good...

[mobby]

It seems that Version 2.20 of RT Grabber is creating invalid xml. It is not filling in the enconding so it writes

<?... encoding=""?>

...and then becuase the encoding is defaulting to unicode (i think) the file encoding is not unicode so some characters are causing the parsing to fail. I have gone back to 2.19 of RT Grabber and everything is working fine. Not sure what is happening there i'm pretty sure 2.20 used to work so I am a little confused. I have also moved xerces into the JARs directory so i know sage can definately see it (as i have the JDK installed so im not sure which java Sage is using, im guessing which ever the pc is set up to use but i thought to be safe i'd just put the jar in the JARs dir).

Thanks for your help Niel and Lucas.

[mj_wood]

I'm having the same problem with the default xmltv grabbers (I use both the _rt and _be grabbers and the problem seems to happen with both).
As far I can see, the xml is valid.
I presume my sagetv and xerces setup is ok as it imported the data from the xml file the first time I ran it. The problem, like mobby's is that the epg data doesn't seem to be refreshing from a new epgdata.xml file

[mj_wood]

I've run the plugin tester and it produced the result "true"

[mobby]

You can also check the xml using IE, if you open it with IE it will parse the file and try to create a dynamic tree from it (so you can open/collapse parent tags). IE may say it has blocked access to the content and you wont be able to collapse any branches, just click on the yellow bar and allow the content, you will then be able to open/collapse the branches. It might take a while to parse but if it can do the whole file then it is ok. Check to the bottom of the page, IE will complain about any incorrectly encoded characters so make sure you can see the end of the file in IE. If there is an encoding error then this will cause the plugin to stop (this is where i was thinking of having a look at the plugin to make it a bit more resiliant to these types of failures but not looked that hard at it yet). Also make sure the first line in the xml file looks like:

<?xml version="1.0" encoding="ISO-8859-1"?> - if your filesize for the epgdata.xml is around 24-25mb for 14days (taking my ntl epg as a guide) then it is most likely in this encoding. If your file is more like 40mb(ish) then thats more likely to be UTF-8 or Unicode hence the first line will have "UTF-8" as the encoding type or no entry at all to default to Unicode (I believe not 100% sure about that last bit).

rather than:

<?xml version="1.0" encoding=""?> - this will be the first error in the file and it was this that was causing me problems. Dont know why but the RT Grabber was writing this line instead of the one above.

I have had a problem with the RT grabber not being able to write the epgdata.xml file whilst Sage(4) is running, so make sure that the new file is actually being written to the epgdata.xml file in your sage installation. TBH it sounds like the file is ok, it sounds more like a problem that either the file is not be updated or sage is not seeing the update. One way to make sure the file is updated is to just stop sage, run the grabber, check the filedate once it is done, start sage, leave it a bit and then check the guide. Often if sage has a lot of updating to do you will get a lot of harddrive access when sage is running. So leave it until this goes quiet and then check your guide. If it is a problem with sage not seeing the updates then i am lost but i am sure nielm, opus, etc will have something for you to try

As for xerces put it in the JARs directory of sage, if you have multiple Java installations, or the JDK installed then Sage may be using a different JVM to the one you have put the xerces jar file in. If you put it in the JARs dir then you are guaranteed that Sage will see it regardless of the java version. This is my guess as to what sage does, i think that sage reads the file into its running database but then rewrites the data into its own format somewhere else (wiz.bin i think). That means that the plugin only really has to work the first time to put all the data into sage but then it could fail after that and the guide will still keep appearing. Its only once sage re-runs the plugin that it updates its internal data, so if that plugin fails your EPG will not suddenly dissappear it just wont have the update. So for me it has taken 14days to realise that the epg was not being updated, it wasnt a case of one day epg, next day nothing, i just noticed that i was running out of epg data.

HTH

p.s. sorry for the long post or if have a I just rattled off everything you already knew or have tried

[Lucas]

I also managed to recreate the problem.

Once I got over the encoding def missing, I run xmltv tv_sort on the file which found several dozens of unicode characters in places were there were accented characters. I replaced one by one each of them and then tv_sort completed. The resulting file was read by the plugin.

Looks like going back to 2.19 as well.

I will let birty know.

[mj_wood]

I left it on overnight and the guide had updated (with a smaller xml file that I am using for testing) when I got up this morning.
I've now tried replacing the epgdata.xml file with the one with all channels (still only 8 channels) and it seems to take about 15 minutes to update. Is this normal?

[Lucas]

Alan replied that the encoding string can be configured in the .ini file.

The rest of the issues were always there and he is not planning to fix them in ver 2. He has fixed them in ver 3 beta.

BTW, I think the major obstacle is using the file to do the first channel definition. Afterwards, when the epg is populated, the epg update files, seem to be read eventually and update the epg.

[Lucas]

UPDATE: After setting the encoding to ISO8859-1 all is well as before.

[birty]

version 3 is now out of beta and should fix all your encoding problems