[vdr] Re: split up channels.conf

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

Thanks! :o)

But Jaakko Hyvatti's idea just to use the triplet is alright. We won't need
a MD5SUM.

But I just realized another problem. We could have one channel on several
media (e.g. DVB-S/C/T).
So we also need a identifier for the source and build the uniqueID with that
four numbers.

With the triplet we can identify the channel and with the sourceID we select
the channels.conf-entry for the source to be used.

Rene


----- Original Message -----
From: "Rienecker, Fa. Evenio, ITS P, M" <C.Rienecker@deutschepost.de>
To: <vdr@linuxtv.org>
Sent: Thursday, September 26, 2002 11:49 AM
Subject: [vdr] Re: split up channels.conf


> 100% consent from my part.
>
> CU,
> Christian.
>
> > -----Original Message-----
> > From: Rene Bartsch [mailto:vdr@bartschnet.de]
> > Sent: Wednesday, September 25, 2002 7:49 PM
> > To: vdr@linuxtv.org
> > Subject: [vdr] Re: split up channels.conf
> >
> >
> > 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 !!!
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > If we do a bad job here the 1.1.x-branch of VDR will become
> > obsolete within
> > one year - I don't want to waste such a good software and all
> > the great work
> > you did for us!
> >
> > Rene
> >
> >
> >
>
>
> --
> Info:
> To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as
subject.
>



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