[vdr] Re: split up channels.conf

[jhall@UU.NET (Jeremy Hall)]

In the new year, Ronald Steininger wrote:
> Hi List,
> 
> Klaus wrote:
> 
> <snip>
> KS> I can't see why everybody is routing towards a centralized channels.conf file.
> KS> The channels.conf file is a user defined setup file, just as the timers.conf is.
> 
>   It's simply a different point of view. Is it really good that a user
>   defined setup file holds this kind of data? There is only one
>   functional frequency,VPID,.. for every channel; the only thing a
>   user can really change is the order of the channels. So, this setup
>   file should only hold the "id" of a channel and maybe things like
>   channel-number, a user defined name,... Things that the user can
>   change.
> 
One reason I am leaning away from a centralized database is because that
database might be inaccurate.  In Adition, I wonder why we need the vpid,
apid, tpid, and pcr at all.  We only need to know the nid, tsid, and
sid.  From there, we can parse the PMT to get the vpid and apids.  Were I
to send a channels.conf to some maintainer of this data, I would be
sending updates every few days because of channel moves etc.  I also would
not be able to provide a complete map as I cannot tune all the
transponders due to spots.  I can, however, provide nid, tsid, sid, and
tier, and name if somebody cares.  That information is obtainable for all
services within a provider scope.  It still would change every few days,
but at least I could provide accurate reliable data.

Whatever happens, I would want that to be automated, and I wouldn't want
to be manually updating anything.  We already have a centralized database,
and that is maintained by the providers themselves.  Why not use that.  So
after I get some things off my plate, I was going to consider an option
where we do away with channels.conf entirely and dynamically build it from
information that is viewable from the stream.  If the user can build his
or her own channels.conf from the network, the need for so much
centralized information is reduced.

I might, for example, be able to be convinced to provide a
transports.conf that lists each tsid, nid, and maybe a nid name.  The only
time that would change is when a new bird arrives.  That doesn't happen
very often, unless spot beams are negotiable by the network at runtime.

> KS> VDR simply provides a channels.conf as a starting point. You're free to rearrange
> KS> the channels, add or delete them as you wish. Sources on the Internet or wherever
> KS> else can provide channel definitions that you can incorporate into your channels.conf
> KS> file, if you like.
> 
>   I spent hours to collect different APID, TPID and some
>   Hotbird-channels from all over the internet. IMHO it would be nice
>   to have a "standard" channels-database that is maintained by
>   someone, we could announce changes (like new channels...) and share
>   our work here.
> 
yes, an informative message like:

The following Network ID has chosen to give us some new services:

then list them with all the information possible about them.  It would be
purely for informational purposes and would only be useful for interested
humans.

>   The "arbitrary string"-idea (Klaus mentioned it before) sounds
>   really good, maybe this field could also hold a "pointer" to an
>   entry in the channels-database. This way, there would be
>   compatibility to older versions and everyone can decide to use the
>   database or user defined values...
> 
I do like the arbitrary string idea, but I would like to request that all
characters in the field be printable.  Strings added should potentially
contain subclauses of length=identifier=value so that parsers know how to
parse this string.

_J