[vdr] Re: split up channels.conf

[Ronald Steininger <ronald.steininger@gmx.at>]

Jeremy wrote:

JH> One reason I am leaning away from a centralized database is because that
JH> database might be inaccurate.

I never wrote it would be easy to maintain ;)

JH> In Adition, I wonder why we need the vpid, apid, tpid,
JH> and pcr at all.  We only need to know the nid, tsid,
JH> and sid.

I don't think that it's a good idea to completely break with the
channels.conf-syntax...

JH> From there, we can parse the PMT to get the vpid and apids.  Were I
JH> to send a channels.conf to some maintainer of this data, I would be
JH> sending updates every few days because of channel moves etc.  I also would
JH> not be able to provide a complete map as I cannot tune all the
JH> transponders due to spots.  I can, however, provide nid, tsid, sid, and
JH> tier, and name if somebody cares.  That information is obtainable for all
JH> services within a provider scope.  It still would change every few days,
JH> but at least I could provide accurate reliable data.

JH> Whatever happens, I would want that to be automated, and I wouldn't want
JH> to be manually updating anything.  We already have a centralized database,
JH> and that is maintained by the providers themselves.  Why not use that.

You're absolutely right!
I tried dtv_scan a few weeks ago, and I think it works this way: The
user provides a "transponder-list", the program scans for channels.
Maybe this program is a starting point?

JH> So after I get some things off my plate, I was going to consider an option
JH> where we do away with channels.conf entirely and dynamically build it from
JH> information that is viewable from the stream.  If the user can build his
JH> or her own channels.conf from the network, the need for so much
JH> centralized information is reduced.

This would be the perfect work for a plugin: scanning for channels and
creating/updating a user-specific channels.conf.

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

>>   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...
>> 
JH> I do like the arbitrary string idea, but I would like to request that all
JH> characters in the field be printable.  Strings added should potentially
JH> contain subclauses of length=identifier=value so that parsers know how to
JH> parse this string.

I also thought about that: IMHO, a good solution would be:
identifier=value,identifier=value,...
VDR uses this syntax for different Audio-pids, and therefor it would be easy to
parse. In that field plugins could save "channel-depended" data, like
Operator-Logos. It would look like this:
Premiere
1:11797:h:0:27500:511:512,513;515:0:101:10:logo=/path/to/logo,someothervar=23
VDR could parse that information and pass this "variables" to the
plugins. It doesn't hurt older vdr-versions or users without that
specific plugin.

-- 
Best regards,
 Ronald                            mailto:ronald.steininger@gmx.at