[vdr] Re: split up channels.conf

["Rene Bartsch" <vdr@bartschnet.de>]

----- Original Message -----
From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de>
To: <vdr@linuxtv.org>
Sent: Thursday, September 26, 2002 1:52 PM
Subject: [vdr] Re: split up channels.conf


> 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?

Ok, not with the data-base, but the statical implementation of  VDR bound to
the DVB-S ...

>
> > 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.

How are you going to decide between LNB A,B,C, ...?

>
> > 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? ;-)

Sorry, I don't have. ;o)
I never do gamble - at least not if I do not have a calculated chance of
winning above 85 percent.

But thrashing software I've had to learn to think five steps into future and
especially
use ObjectOrientedProgramming and Normalization in DBs.

> 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).

I didn't want to flame you in any way. When you started you implemented VDR
for your private purpose and certainly never thought about becoming a column
of OpenSource - you did a great job and I want to thank you! :o)

But because of it's historical growth first VDR has been much to static.

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

This is OK, if we don't have to change the structure of channels.conf
anymore.

> 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?)
>

DVB-specs says any channels can be identified uniquely by
original_network_id, transport_stream_id and service_id.

> >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).

Thats OK.

>
> 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
> --

You're great! :o)

Rene



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