Mailing List archive

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

[linux-dvb] Re: channels.conf syntax?



Gerd Knorr wrote:
> 
> Jamie Honan <jhonan@optusnet.com.au> writes:
> 
> > Seriously, the vdr format is simple; one line represents
> > one 'program' that a user would want to watch, but doesn't quite
> > cover all bases.
> 
> Neverless I'll go with that for now ...

Good, because that's the way it will stay ;-)

> > Scanned information has to be merged with previous information.
> > You have to have some way of having favorites, and things you
> > don't really want to bother with. Again Australian digital television
> > stations like to have the same program on different PID streams,
> > you simply want to ignore the other two copies. So you want to
> > remember that named services are to be associated with 'ignore'
> > or 'favorite - football' on a rescan.
> 
> My current plan is to use the channels.conf file much like a frequency
> table in analog TV.  xawtv's has tv station list with all that
> meta-information like hotkeys.  That list just maintaines a reference
> to the tuning information, i.e. something like "channel = E4" for the
> analog tv (which the frequency table will map to a frequency).  For
> DVB I just need a some ID (first column of channels.conf file?) I can
> put into the tv station list and which I can use as reference to find
> the tuning information.

I suggest you create the channel ids the same way VDR does (see 'man 5 vdr').
See also the 'sky' plugin, where I am using some of the fields in channels.conf
to store numbers that actually map to the ids they are using on their
Internet pages, where I get the EPG info from (see getskyepg.pl).

> > The information is really hierarchical.  For example, repeating the
> > FEC, guard etc., is really pointless for a number of programs
> > sharing the same frequency.
> 
> Why?  repeating doesn't hurt much as the table is autogenerated anyway
> (and small enougth that we don't have to care about the memory it
> takes), and a flat structure is easier to handle ...

Beginning with VDR 1.3 the actual unique id for each channel will be
derived from the Source/NID/TID/SID/RID, so there will be no repeated
information that is used in the unique channel ids any more. All the
other data will just be stored to have it available quickly when tuning
to a different channel.

Klaus


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index