[vdr] Re: split up channels.conf

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

Rene Bartsch wrote:
> 
> ----- 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 don't wrap lines when quoting - this makes the quoted text a mess!

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

One of the next things I'll do is to extend the channel setup to allow
the specification of all parameters necessary for DVB-C and DVB-T.
This will be done by expanding the meaning of the "polarization" field
to make it hold any information that particular device type needs, besides
the information common to all devices (like transponder frequency, symbol
rate, PIDs etc.).

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

The parameters 'source', 'frequency' and 'polarization' will be used to
look up an entry in the new file 'diseqc.conf', which will define the entire
DiSEqC sequence to send for this combination of the three parameters, as
well as the LOF to be used.

> ...
> I didn't want to flame you in any way...

I didn't consider your posting a flame :-)

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

The 1.1.x development is going to great lengths in order to make things
more dynamic and extendable.

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

Is this true in case the same channel is broadcast on different transponders,
or on different systems like DVB-S, DVB-C and DVB-T? So, in case ZDF is
broadcast on DVB-S on different satellites, and on DVB-C or DVB-T in different areas,
will the original_network_id, transport_stream_id and service_id be different,
so that we can distinguish all these different broadcasts? Will this be true worldwide?
If that were true, we wouldn't even need the 'source' parameter in the unique id.

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.