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

[Johannes Stezenbach <js@convergence.de>]

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).

- 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. 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).


> 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?

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?


Johannes


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