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

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Johannes Stezenbach wrote:
> 
> Klaus Schmidinger wrote:
> > 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 ;-)
> 
> I hope you will reconsider if someone actually goes through all the
> trouble of defining and implementing a different "standard" format
> that you can conveniently just use in VDR.
> 
> Anyway, instead of bashing VDR or the other exisiting channel list
> formats, let me state the goal I am pursueing (sparked off by
> a recent posting by Jamie Honan): I would like to define a standard
> format for DVB channel lists and input configuration, which would
> be backed up by a tiny C library so it is usable by potentially
> every Linux DVB program out there. Why? Because it would simplify
> installation / configuration, making it easier for users to try
> new DVB software, making it easier for developers to write new
> software. Lets you use any scan tool to update the lists for any
> zapping or recording software.
> 
> I would like to hear some opinions if that goal is worthwile
> or if we should stop right here.
> 
> Now, I don't care much about the actual file format (whether it's
> flat or hierarchic, tagged or not, readable or not etc.). I would
> prefer a terse format which produces small files usable on embedded,
> but that's more a matter of taste. VDR's doesn't look so bad.
> 
> It was unfair that I said the vdr channels.conf format "sucks" and
> not tell you why. Below are some requirements that I think are not
> met by it.
> 
> - reliable unique identification of services and transponders.
>   ETSI TR 101 211 says:
> 
>     "A TS can be uniquely referenced through the path
>     original_network_id/transport_stream_id. A service can be uniquely
>     referenced through the path original_network_id/transport_stream_id/
>     service_id. The network_id, thus, is not part of this path. In
>     addition each service_id shall be unique within each
>     original_network_id. When a service (contained inside a TS) is
>     transferred to another delivery system, only the network_id changes,
>     whereas the original_network_id remains unaffected."
> 
>   Note that you can receive the same service on different networks,
>   e.g. ZDF via Astra, Hotbird, cable or DVB-T.
> 
>   However, you can bet that some broadcasters manage to screw up and
>   break the rules. I don't know if we should care, and I don't have
>   statistcal data to see how big a porblem this is.
> 
>   A unique ID however is necessary for building favourite
>   lists. This ID also must be stable across service scans, and
>   preferably be independent of the transport stream / frequency,
>   because services can move (EN 300 468 even defines a Service move
>   descriptor).

Currently VDR still uses the transponder frequency in the channel ids,
but this is going to chsnge in the next version. See 'man 5 vdr' and
the actual implementation in VDR/channels.c

> - it should be easy (for scanning applications) to get a list of
>   transponders
> 
> - it should be easy to get a list of services on a transponder
> 
> VDR currrently does not have the concept of favorites lists, and thus
> the sort order of the channels.conf is important.

The next version will ;-)

> Thus automatic
> update of channels.conf by a scan tool is problematic, and you
> cannot have a hierarchical format (well, one could put TP info
> separately and reference the TP from the service info).

I don't see the need to separate this. The way I want to do this is
that you can always tell VDR about a (new) transponder and it will simply
scan all the channels broadcast on it.

> > 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.
> 
> What is RID? Is this for the radio services with 10+ audio PIDs?

That's the idea.

> Looks like you're on the right track. Still: Do you want to do
> it yourself or would you use a library created by someone else
> which does it and could also be used by other DVB software?

I prefer to stay with the simple format currently in use by VDR.
But that, of course, shouldn't keep you from implementing your
ideas. I just like the simple format VDR is currently using and
intend to keep on using it. There will, of course, be favourite
channel lists in teh next VDR version, also based on the simple
"colon separated", "line based" format. Note that the very same
format is used by SVDRP to list, create and modify channels, so
why use two different formats?

Klaus


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