[vdr] Re: split up channels.conf

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Rene Bartsch wrote:
> 
> After all discussions I'm to tell you that we can't keep a line-number based
> channels.conf.
> We need to identify every channel by a unique ID.
> 
> In the future there will be a lot of more functions of VDR, so we need to
> keep nomalization which consequences in different tables/files.
> At any projects - especially the overnight hacks - I had to realize creating
> static data-bases resulted in software which wasn't possible to be
> maintained anymore with the consequence I've had to trash it. Once half a
> years work went into trash as of a little additional data-field which broke
> the static setup.
> 
> We already suffered to similar problems with the VDR >1.0.4-branch (because
> of his historical growth) and we shouldn't do the same fault again !!!

Please refresh my memory: what "similar problems" would those have been?

> So my suggestion:
> 
> We create a channels.conf which holds the complete data of a channel
> (source, transponder, original_network_id, transport_stream_id, service_id,
> pids, ...) and a unique ID - and nothing more.

If the unique ID is calculated from the data in channels.conf, why should
that ID be _explicitly_ stored there?

> We should calculate the uniqueID by the MD5SUM of original_network_id,
> transport_stream_id and service_id, the identifiers according to the
> DVB-standard.
> The MD5SUM has the advantage that any channel-generator can recalculate the
> uniqueID by original_network_id, transport_stream_id and service_id.

Maybe I'm missing something here, but what is the advantage of calculating
an MD5 sum instead of just building, say, a 64 bit number from the various IDs?

Ok, I just received your other posting where you dismissed the MD5 sum...

> For the user's OSD and the setup according to the hardware we should use
> other tables bounding the options to the uniqueID. So we can distribute a
> full channels.conf with all channels and the user's OSD-table decides which
> channels to use/favorize and we won't have problems with hardware-related
> things like DISEC.

The DiSEqC part has nothing to do with numbering or channel IDs. With the new
"source" parameter, the transponder frequency and polarization VDR will be able
to do the DiSEqC setting - without the need of any further channel identification.

> If we do a bad job here the 1.1.x-branch of VDR will become obsolete within
> one year...

Wow, how do you make such predictions? Do you have the lottery numbers for next
saturday, too? ;-)

Ok, more serious.... When I started writing VDR I was glad to have ONE file that
contains my timers, and ONE file that contains my channels. I don't want to be forced
to have an ADDITIONAL file that holds channel information. I want to be able to have
ALL that information in ONE channels.conf file. Needless to say that I want the
channel numbers to be given by the line numbers of that file (possibly with "holes"
in the numbering sequence).

So, whatever changes we make to the channel definitions, it must be possible to
still work with a single channels.conf file.

In order to allow others to uniquely identify channels I can add the NID field to
the channels.conf definition. I'm not sure about the transport_stream_id - is that
really something that is necessary? Can there be more than one TS on a given
transponder?

As far as I can see the data necessary to identify any channel would be

  source (Sat, Cable, Terrestrial - plus orbital or geographical position)
  transponder frequency
  service id
  network id (not sure about that one - can there be more than one network id
              on a given transponder?)

From these there will be generated a unique ID (which will NOT be stored in
channels.conf, since it can be calculated from the other data).

With that ID it should be possible to update channels if, e.g., their PIDs
or name changes. The timers.conf will store these IDs instead of the channel
numbers to avoid problems (but there will be an option to make it still use
channel numbers here, because that's how I prefer it).

The cChannel class will provide access functions (instead of exposing the
actual data members), and one of them will be something like 'UniqueId()'.
I suggest making the unique ID type a 64 bit integer, which would be easy
to handle and should be sufficient to identify any channel. Plus, it could
transparently be used to identify channels by "channel number", since I guess
it is safe to assume that nobody will ever have a channel list with more than
4 billion channels <g>, and if we define the unique ID in a way that it always
has at least one of the upper 32 bit set, any number below 4 billion can be
safely assumed to be a channel number.

The cChannel class could even allow a plugin to implement an additional level
of redirection, in case somebody wants to store user channel definitions in
a separate file.

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
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.