I've been thinking more on how we deal with tuner ids and dvb name of our channels. If you think about it these things are the same thing.
The tuner id is some key your cable provider gives you for a certain channel. For me an example is tuner id '9' is the channel 'ATV'. The cable provider in the province next to ours has '7' for ATV, and there it is the different cable provider, not the provice, that changes this.
If you know DVB on linux then the DVB name is the first field for a channel in your channels.conf. Here the DVB name is really the display name (acording to the provider). There are also two more fields that may uniquely define a channel, the service id and radio id. If you have multiple DVB providers in a given channels.conf then you may have conflicting service ids (they are unique among a single provider). The service id is the channel _number_ that you tell your DVB receiver to goto. In VDR there is a channels.conf field called rid (radio id) that you may set to diferentiate channels of the same sid (service id) on different providers. Some people may add 1000 or 2000 to each sid to give them unique rids for example.
Anyhow, among a single provider the service name and service id should be constant, at least per delivery system. Do some providers offer multiple types of DVB?
More to my point: We already know that our problems come from the fact that any particular TV station may be broadcast by different providers under different ids. What we need to know is what each provider (or tvX/dvbX/ivtvX device) calls each station and which channels are on more than one provider.
Question: Is the tuner, or dvb name or id something that should be in the EPG DB? Right now the channels table contains tuner_id but I don't think that's fair considering it is only one of the keys to which you may access the channel. Ok, I think this should be in the DB but should be named differently.
XMLTV does an ok job of dealing with multiple names for a channel. They allow multiple display-name attributes:
<channel id="C4wgbh.zap2it.com">
<display-name>4 WGBH</display-name>
<display-name>4 WGBH 0002060:-</display-name>
<display-name>4</display-name>
<display-name>2 WGBH fcc</display-name>
<display-name>WGBH</display-name>
<display-name>WGBH</display-name>
<display-name>PBS Affiliate</display-name>
</channel>Still, these display-names don't have to be unique among channels. Generally people only use one display name for a channel and one id to access the channel. I only want to keep one display name in the DB, and its not even called that, it is call_sign which is what the television station calls itself. If applictions using pyepg are only going to use call_sign to generate a display name we may as well change it (back) to display_name and format it how we want as the DB is filled with data.
Again, what we need to know is what each provider (or tvX/dvbX/ivtvX device) calls each station.
Possible solution: I could change tuner_id in the DB to default_id. This would be filled by one of tuner id, dvb id, or dvb name. I would say that 99.9% of users only have one television provider. I am one of the few who has two and I give my duplicate channels unique channel ids!
We could solve this by using TV_DEFAULT_SETTINGS and TV_CHANNELS that compliment the DB (like in my reply to "recordserver doc"). DVB users will have their EPG filled using the dvb name (or service id if they wish) as the default_id. On second thought maybe default_id should be called access_id or default_access_id.
Ok, enough rambling from me, but I really think that would work well. :)
-Rob
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
