Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: split up channels.conf



Jeremy Hall wrote:
> 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.

I agree that parsing the PMT/... is a very elegant concept.
Unfortunately, it would introduce additional steps during channel 
switching. I'm almost sure that this would slow down channel switching,
especially with the full-featured cards. 
Therefore, the extracted information should be cached.
Let's call the cache file channels.conf. :-)

The idea is to implement PMT parsing as a plugin which should run in the 
background. The updated data could be passed to vdr, either automatically
or on user request.

Oliver




Home | Main Index | Thread Index