[vdr] Re: split up channels.conf

["Rienecker, Fa. Evenio, ITS P, M" <C.Rienecker@deutschepost.de>]

Just to be precise a channel is uniquely identified by the triple
[source|NetworkID|ServiceID]

The transponder (i.e. frequency & polarization), VPID and APIDs may change from time to time as we see almost every 6 months at Premiere.

CU,
Christian.

PS: Actually on Astra the ServiceID is already unique. But that is not according to the DVB standard and may be coincidence.


> -----Original Message-----
> From: Klaus Schmidinger [mailto:Klaus.Schmidinger@cadsoft.de]
> Sent: Tuesday, September 24, 2002 10:01 AM
> To: vdr@linuxtv.org
> Subject: [vdr] Re: split up channels.conf
> 
> 
> Olivier JACQUES wrote:
> > 
> > Hi.
> > 
> > I think that the issue here is that we can always imagine a 
> new feature that
> > needs another field in the channels.conf. Splitting the 
> channels.conf has
> > the advantage of keeping backward compatibility (with the 
> few "scanners" or
> > "channels.conf generators") + allow addition of features 
> (which, I hope,
> > will grow fast with the plugins).
> > As an example, I was thinking of associating a channel logo 
> to each of the
> > channel and being able to choose (zap) from logos and no 
> channel names.
> > Well, I guess you can imagine whatever you want.
> > IMHO, the 'split' is a good idea.
> 
> Whatever way you "split" the data, you'll end up duplicating 
> information.
> The channels.conf lines contain all information necessary to 
> tune to a given
> channel, and their line numbers give a natural way of having 
> channel numbers
> going 1, 2, 3,... With an additional "favourite" field we 
> could have up to 32
> different favourite channel lists without the necessity of duplicating
> information or cross referencing tons of files.
> 
> If a channel scanner thinks it has to redefine channels, it 
> can do so if
> it knows how to identify a channel. It can use the (yet to be 
> implemented)
> "source", transponder and SID for this, without having to 
> "split" channels.conf.
> Of course, if that process would rearrange the sequence of 
> the channels, it
> would also have to take care of timers.conf - but that's 
> something VDR does,
> anyway. So if we implement some additional functions that 
> allow a plugin to
> rearrange channels and have timers.conf be automatically 
> updated, this should
> be no problem. 
> 
> I could even imagine an additional field in channels.conf 
> that contains an
> arbitrary string, which VDR itself doesn't care about. So if 
> you have additional
> information you want to store in a channel definition, you 
> could do that.
> 
> If we "split up" channels.conf I believe things would become 
> unnecessarily
> complicated. Imagine somebody who wants to define a channel 
> with only one
> of several audio PIDs. If we only use 
> [source|transponder|SID] to identify
> a specific channel, that wouldn't work since there could be 
> several channels
> that match this key, only distinguished by the APID. So I 
> guess we would have to
> add the APIDs to the key as well - but what's next?
> 
> I still firmly believe that it's best to keep things simple, 
> and that means
> having channels.conf as it is, possibly extended by a 
> "favourite" flag field
> and (if this is something people would like to have) and 
> arbitrary string
> field for various purposes.
> 
> As for the above example of "associating a channel logo": 
> this could be done
> by the plugin by identifying the channel through the 
> [source|transponder|SID]
> without any impact on VDR, especially without "splitting" 
> channels.conf.
> 
> Klaus
> -- 
> _______________________________________________________________
> 
> Klaus Schmidinger                       Phone: +49-8635-6989-10
> CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
> Hofmark 2                               Email:   kls@cadsoft.de
> D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
> _______________________________________________________________
> 
>