[vdr] Re: split up channels.conf

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

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