xmltv - guide to channel mapping (1 Viewer)

Laban

Portal Pro
July 1, 2007
206
18
Luleå
Home Country
Sweden Sweden
Hi

I'm having some problems with the xmltv plugin. Or perhaps it's not a problem per se.

If i'm not mistaken, the way that the plugin works is that it takes maps the channels using their display-names.

example from a tvguide.xml file:

<channel id="eurosport.com">
<display-name="Eurosport">


The programs for Eurosport (eurosport.com) is then mapped to the existing channel with the name "Eurosport". If there's no such channel available, it'll create a new channel with no information about the channel, dvb-s in this case.
All those channels will of course be unusable. Which means that the channels will have to be renamed to match the xmltv (tvguide.xml) name exactly before importing.

Is this correct ?

If it is, is there another plugin for xmltv that does this a better way ?

Swedish channels in this case, i'm using tv_grab_se_swedb.

If the answer is yes on the first question, no on the other, i might actually try and write a xmltv2 plugin that'll create a xml mapping file using the display-name in the tvguide.xml file that'll map the id to the channelid , f.e "action.tv1000.se" -> 2:TV 1000 and so forth (I'll keep the name from the channel search in the xml file also, for potential future use :)). It'll give you an option to change the mappings that were automatically created in case the names aren't matching. The options will be presented according to the closest matching name, if there are any. The rest will be in alpabetical order.

That mapping file will then be used for each new xmltv import. You'll also be able to do a new channel search (f.e when the provider adds new channels) and reuse all the mappings that are currently available.

Don't know if the above makes any sense, especially if there's a better way of doing this already. Let me know what you think.
 

dvdfreak

Portal Pro
June 13, 2006
979
178
Home Country
Belgium Belgium
If i'm not mistaken, the way that the plugin works is that it takes maps the channels using their display-names.

Perhaps it would be better to map on the XMLTV id, which is unique? But then again, if you switch to another guide source and the ID changes you're going to be "screwed".

So mapping on the channel name is not such a bad idea after all. But you are right, it should be possible to tweak the mapping, in case of a mismatch.

In any case, I know the MP database contains an "external ID" field in the channel table, so it's possible it does switch on the XMLTV id after all. Would have to look at the code to be sure, but perhaps someone else following this thread knows for sure...
 

Laban

Portal Pro
July 1, 2007
206
18
Luleå
Home Country
Sweden Sweden
True, the channel table contains an external id and it contains the id from the tvguide.xml file.

But i'm guessing that this mapping is initially done using the display-name in the tvguide.xml so the problem is still the same.

But this means that there might not be a reason to use a separate xmltvmappings file since i could use the channel.externalId instead. The benefit of using a separate xmltvmappings file though is that it's easy to share this file.

On the other hand, you could perhaps use the export functionality instead if you want to share your settings with other people that's using the same provider. Canal Digital (sweden) in my case. That'll also contain all the dvb-s information.
 

dvdfreak

Portal Pro
June 13, 2006
979
178
Home Country
Belgium Belgium
If you look at my posting in the improvement suggestions section you'll notice I'm suggesting a split between a "guide channel" and a "tuning channel".

This would effectively mean you could link any tuning channel to any guide channel. So if you have e.g. "BBC London" both on satellite and on cable you could link those two tuning channels to the same guide channel.

By default this linking could occur on channel name (you have to start somewhere, and it's a good and usable default). But you could then tweak the link to the right guide channel in case the name did not match.

So to continue on the example I made before. If you were to switch the guide source, and you would get a bunch of new channels you would simply re-link the tuning channels to the new guide channels.
 

Laban

Portal Pro
July 1, 2007
206
18
Luleå
Home Country
Sweden Sweden
This would effectively mean you could link any tuning channel to any guide channel. So if you have e.g. "BBC London" both on satellite and on cable you could link those two tuning channels to the same guide channel.

The link between the two is a one to many relationship:

channel:
channelid int,
externalid.. (not sure how this is used either, need to look at the code)
...

program:
programid int,
channelid int,
name ...

This means that you'll need an extra row in the program table for each channel you want to assign the program to. That's easy to do of course. Not sure if this'll create some other problems in the tv-engine though.

The other solution is of course to make the relationship a many-to-many but that's not for me to decide :) Besides, i doubt that this'll be a commonly used thing anyway.
 

dvdfreak

Portal Pro
June 13, 2006
979
178
Home Country
Belgium Belgium
This means that you'll need an extra row in the program table for each channel you want to assign the program to. That's easy to do of course. Not sure if this'll create some other problems in the tv-engine though.

The other solution is of course to make the relationship a many-to-many but that's not for me to decide :) Besides, i doubt that this'll be a commonly used thing anyway.

What you describe will of course also work, but that's not what I was suggesting actually.

What I suggest we have is:

TvProgram -- (many-2-one) --> TvChannel -- (one-2-many) --> TuningChannel

This would be a very clean way to keep guide information in its own little subdomain. While usually a TuningChannel will have a one-2-one relationship with a TvChannel, it will actually be possible to have two TuningChannels use the same TvChannel, so the same guide data.
 

Laban

Portal Pro
July 1, 2007
206
18
Luleå
Home Country
Sweden Sweden
What you describe will of course also work, but that's not what I was suggesting actually.

What I suggest we have is:

TvProgram -- (many-2-one) --> TvChannel -- (one-2-many) --> TuningChannel

This would be a very clean way to keep guide information in its own little subdomain. While usually a TuningChannel will have a one-2-one relationship with a TvChannel, it will actually be possible to have two TuningChannels use the same TvChannel, so the same guide data.

That's another way of doing it. Though this solution requires a change in the mediaportal which i doubt is an option here. Same as the many to many of course. That solution would have ended up being pretty much what you described of course (usually you'll resolve the many-to-many relationship with a in-between table, f.e called TvChannel :)).

But i think we can live with the duplicate program's since it's an exception rather then the norm.
 

Users who are viewing this thread

Top Bottom