RadioTimes XMLTV feed ending on 16 June 2016

[starfire]

I get them separate now from the title.

[jamesdisco]

So does anyone get season/episode info like the screenshot below from using digiguide & stephanes importer and if they do HOW?

Series.jpg

The reason i have that info is from the catchuptv service.

[rickgillyon]

I do, in some instances, see attachment. But I suspect Batch Metadata Tools are responsible for some of this stuff...

[Slugger]

Originally Posted by jamesdisco

So does anyone get season/episode info like the screenshot below from using digiguide & stephanes importer and if they do HOW?

Attachment 15557

The reason i have that info is from the catchuptv service.

I'm pretty sure the xml importer predates Sage v7 when the season/episode fields were introduced. So I doubt the xmltv epg plugin knows how to handle inserting that data properly so Sage recognizes it. My sdepg plugin was the first I knew of that supported the new Sage 7 apis for that data. My guess is you'll need to get the author of the xmltv plugin to update to the newer Sage apis to get that data imported as expected or switch to another epg plugin, like sdepg, if it supports getting data for your region.

EDIT: I shouldn't say "my" plugin anymore, as I don't use/maintain it anymore. But it is a working solution that does support proper import of the S/E numbers, when available.

[jamesdisco]

Slugger that will be the problem I hadn't realised that it was only introduced in V7 and the plugin was last updated in 2010.
His website is back up and running now so I'll try and contact him.

[rickgillyon]

Originally Posted by Slugger

switch to another epg plugin, like sdepg, if it supports getting data for your region

I'd already considered trying sdepg out on my system, but it seemed a bit risky with the current lack of any maintainer.

[something fishy]

I got my SD account setup, but haven't had chance to setup a V9 test server yet. Are you getting season and episode nos. for all series, that is the one thing that annoys me about stephans importer because its in the digiguide data.

I used to use digiguide but the lack of complete SxxExx information irritated me. I switched across to using Atlas metabroadcast grabbed into xmltv just in time for their terms and conditions to be changed to prohibit us using it that way.

I now use schedules direct. Its series and episode data are much better than I was getting with digiguide (I think the problem is with the digiguide to xmltv conversion, not with digiguide data itself) but not quite as good as Atlas (soaps don't most other things do).

I tried using the SageTV (v9) schedules direct plugin but gave up because
1) channel management was driving me nuts
2) I wanted to recreate the channel names and IDs I used before so the recording histories weren't lost and I didn't have to redo channel locks in favourites
3) I like having SxxExx in the title, Stephanes importer gave me that.

So now I use the xmltv schedules direct JSON importer to convert schedules direct data to xmltv and then process that with Stephane's importer. This sounds illogical but I've always had to source xmltv data myself (I used to live overseas and scrape websites using TVxb) so I'm used to it and it satisfies all the requirements above.

Been using it a couple of months now and no complaints. I did have a problem at first that the xmltv header wasn't quite what Stephanes importer wanted but I sorted that by using xmltv's merge function. Happy to provide details if anyone wants to replicate.

The xmltv windows grabber needs to be a specific version for it to have the Schedules Direct JSON grabber included, it's one of the recent Alpha's. Google should find it (I'm afraid I haven't kept notes).

Edit:
I should add that SageTV seems better at knowing which episodes are new, which are repeat/reruns with the SD data than it ever did with Digiguide even if there isn't a SxxExx entry in the xmltv. For that reason alone I think its better.


Cheers
Eric

[jamesdisco]

Is this the correct grabber
Please share how to make the header acceptable to Stephane's importer.

[Fuzzy]

Originally Posted by rickgillyon

I'd already considered trying sdepg out on my system, but it seemed a bit risky with the current lack of any maintainer.

It's not like the alternatives you are discussing from 2010 are well maintained.. honestly, I'd really suggest using sdepg. If nothing else, having a well supported data provider goes a long ways, and as long as they don't change their api, i can't imaging the sdepg importer having issues.

[michaeldjcox]

Originally Posted by jamesdisco

Slugger that will be the problem I hadn't realised that it was only introduced in V7 and the plugin was last updated in 2010.
His website is back up and running now so I'll try and contact him.

I logged a support query with Stephane here and this is confirmed - the API call was not available at the time.

I haven't requested an update though to provide season/episode in meta data.

My concern was that maybe I had lost something in the move from RT to digiguide but actually I never had season/episode with RT anyway other than in episode title.

The important thing I guess is that an episode has a unique id built from these components so we can track if watched or not.

I will probably monitor that one for a bit and may be move to schedules direct if I'm unhappy with the quality.

[jamesdisco]

Right next question is, is anyone using the SD UK guide data with Sage7 and sluggers V7 plugin. I am sure when i spoke with Robert from SD he said you would need to use sage9 as V7 was only designed to use US and Canadian data. Maybe now the UK is officially supported by SD it will be possible to use it in sage7.

[starfire]

I'd just try Sage V9 overwriting your current system, just backup the SageTV folder first and you can quickly revert back if for some reason you find an issue.

Attached some of my EPG examples.

[Fuzzy]

Originally Posted by jamesdisco

Right next question is, is anyone using the SD UK guide data with Sage7 and sluggers V7 plugin. I am sure when i spoke with Robert from SD he said you would need to use sage9 as V7 was only designed to use US and Canadian data. Maybe now the UK is officially supported by SD it will be possible to use it in sage7.

There is no real reason not to just upgrade to v9 at this point.

[rickgillyon]

Originally Posted by Fuzzy

It's not like the alternatives you are discussing from 2010 are well maintained.. honestly, I'd really suggest using sdepg. If nothing else, having a well supported data provider goes a long ways, and as long as they don't change their api, i can't imaging the sdepg importer having issues.

"As long as they don't change their API" is the operative phrase here. I don't know whether that's likely or unlikely. Sounds like it would break entirely:

Thing is, if SD ever does another api release on their end and deprecates the current release (which they tend to do a few months after a new api) then someone will need to step up and update this plugin otherwise it will just cease to work because when SD deprecates an api version on their end, that means they shut it off and force you to move to the latest api.

This one still works currently, has done for years, and if issues are with the grabber we can often fix anyway. Moving over is a real PITA with lineups to setup etc. so I don't want to do it and then have to move back again. Maybe @rkulagow can give an idea how likely an API change is?

[Fuzzy]

Originally Posted by rickgillyon

"As long as they don't change their API" is the operative phrase here. I don't know whether that's likely or unlikely. Sounds like it would break entirely:


This one still works currently, has done for years, and if issues are with the grabber we can often fix anyway. Moving over is a real PITA with lineups to setup etc. so I don't want to do it and then have to move back again. Maybe @rkulagow can give an idea how likely an API change is?

Of course it depends on your setup, but in general there is far less work in setting up the SDEPG plugin than there is in setting up an XMLTV grabber and importer. As for something getting broken, as long as SD continues to offer their JSON source, which is relatively new and what they are wanting everyone to switch to, then minor changes should be easy to deal with. The SDEPG plugin is open source, so anyone can make a fix if needed.

For me, though, the real reason I recommend it is to get everyone to move to a more common source - this helps the overall community if we can get more and more people on similar systems. The non-US markets have always had this issue of guide data being a chaotic mess of sources grabbers and importers - SD expanding into new markets is probably one of the biggest improvements in this scene in quite some time.

Ultimately, I can see SD support (whether based on Slugger's grabber, or recreated from scratch) being rolled into the core in the future, as it is the most universally available option out there. It just hasn't trickled to the top of anyone's priority list yet, because it's working pretty well in plugin form.

[rickgillyon]

Thanks, I know Jeff would rather it be in the core. My Digiguide sub is up in September, maybe I'll try before that, when I have a few hours to kill...

[something fishy]

@jamesdisco
Yes I think that's the correct grabber, certainly that is the syntax that I use.

I'm at work at the moment so I can't remember the precise syntax however, I can tell you the broad issue.

If you inspect the xmltv files generated by the xmltv SD JSON grabber and the files that you have been generating from DG2XML you'll see there's an extra line in the xmltv header with the SD file. Delete that line and Stephane's importer handles the file fine.

I do this by:
1. Grab the data from SD using xmltv.exe
2. Delete the offending second line and all the program info (ie just leave the channel definitions), don't forget that the file needs the closing </xmltv> line at the end.
3. Save this as something like "header.xml"
4. Use xmltv.exe's merge file function to merge the full xmltv file with your saved header file.

Step 4 adds back in all the program info and saves the file as a properly formatted xml file but with the header that you created.

That's the file that you specify for Stephane's importer. If you're good at scripting I'm sure that you can cut the offending line from the xml file directly, but I'm not.

After you've installed xmltv.exe just running "xmltv" will bring up all the arguments that it will take, this will tell you if the version you have has the SD JSON grabber and the merge files utility.

One tip that I would give for using the xmltv.exe SD JSON grabber is for a first configuration run select all channels. It will then download everything and write an appropriate configuration file (it create the directories on first run, I'm guessing all here are using Windows but these are hidden directories in Linux). You can then edit the configuration file in a text editor to specify which channels you actually need (if necessary looking through the channel headers in the xml file for reference). The Q&A based xmltv.exe channel configurator is a pain.

Sorry forgot, you turn a channel off in the configuration file by replacing the "=" with "!" (It will be clearer when you've got the file open).

[Fuzzy]

Originally Posted by something fishy

@jamesdisco
Yes I think that's the correct grabber, certainly that is the syntax that I use.

I'm at work at the moment so I can't remember the precise syntax however, I can tell you the broad issue.

If you inspect the xmltv files generated by the xmltv SD JSON grabber and the files that you have been generating from DG2XML you'll see there's an extra line in the xmltv header with the SD file. Delete that line and Stephane's importer handles the file fine.

I do this by:
1. Grab the data from SD using xmltv.exe
2. Delete the offending second line and all the program info (ie just leave the channel definitions), don't forget that the file needs the closing </xmltv> line at the end.
3. Save this as something like "header.xml"
4. Use xmltv.exe's merge file function to merge the full xmltv file with your saved header file.

Step 4 adds back in all the program info and saves the file as a properly formatted xml file but with the header that you created.

That's the file that you specify for Stephane's importer. If you're good at scripting I'm sure that you can cut the offending line from the xml file directly, but I'm not.

After you've installed xmltv.exe just running "xmltv" will bring up all the arguments that it will take, this will tell you if the version you have has the SD JSON grabber and the merge files utility.

One tip that I would give for using the xmltv.exe SD JSON grabber is for a first configuration run select all channels. It will then download everything and write an appropriate configuration file (it create the directories on first run, I'm guessing all here are using Windows but these are hidden directories in Linux). You can then edit the configuration file in a text editor to specify which channels you actually need (if necessary looking through the channel headers in the xml file for reference). The Q&A based xmltv.exe channel configurator is a pain.

Sorry forgot, you turn a channel off in the configuration file by replacing the "=" with "!" (It will be clearer when you've got the file open).

If you are going to be getting data from Schedules Direct, why bother with XMLTV at all?

[something fishy]

@Fuzzy
Perfectly legitimate question as the schedules direct plugin worked first time for me.
1. I'm fussy about how channel names appear in Sage, SD's Channel IDs for UK channels are not what I wanted (or pretty). I couldn't find a way of changing them in Sage that persisted through a guide update.
2. I use SageMC so I like to have SxxExx included as part of the episode title (otherwise SageMC can't display them being so old). Stephane's importer let's me do that trivially.

Plus after so many years of dealing with xmltv files it's actually more natural for me going into the server and working with the importer with keyboard and mouse than through the SageTV front end.

[Slugger]

fwiw, the sdepg plugin provides the ability to modify/massage/etc. the data as it's being loaded into wiz.bin. So with but a few lines of groovy script, one can massage the data as desired. This is one of the often overlooked features of the sdepg plugin, but one I personally exploited for various reasons. To my knowledge, I was the only one ever to use it. But with it, you can pretty much do anything you want to the data before it gets inserted into wiz.bin.

With the groovy scripting capabilities, you could easily handle both concerns on your list.