[linux-dvb] DVB file formats
Andrew de Quincey
adq_dvb at lidskialf.net
Thu Jun 16 04:27:43 CEST 2005
On Thursday 16 June 2005 01:58, Robert Schlabbach wrote:
> From: "Andrew de Quincey" <adq_dvb at lidskialf.net>
> > In the current format, you would just create more than one [transponder]
> > section. [channel]s simply belong to the most recent [transponder] seen.
> Why not merge channels (I'd prefer the DVB term "services") and transponder
> (locator) information in one section then...? Might be better to keep them
> together anyway.
Yeah, that would be ideal. However what I'm trying to avoid is the state of
affairs in something like the VDR channels.conf example on the wiki page. It
has had more and more stuff put into a single line of text as time goes on
and unfortunately it is very hard to understand and parse (I wrote a parse
for it recently).
That is why I chose to have seperate sections for the [transponder] and
[channel]s - so they can be extended with additional keys as necessary, and
also remain readable.
As for channel->service - if thats the DVB standard, it would make sense to
move to that I agree. Its a pity they don't have a standard name to describe
the concept of a transponder across all media types though :)
> > the dvbs=, dvbt=, dvbc=, etc key tells you what type of transponder it
> I don't like the idea of having a "variable" on the left side of the
> equation sign. IMHO, a line like "type=dvbc[;tuning parameters]" would be
> better, as an application parsing them could easier find out that it does
> not know/want a specific locator/transponder, rather than having to parse
> through all values to see if it finds any it recognizes. Using the "type="
> style allows the parsing application to tell unknown locator/transponder
> types from _corrupted_ sections.
Yeah that is a very good point.
> > I agree it would be good to use the DVB specified ONID/TSID. However,
> > I am not using that on purpose because I have found several instances
> > of transponders with what appear to be "default" settings for these
> > values.. i.e. the IDs are the _same_ as on other transponders.
> If you merge locator/transponder and service data in one section, that'd be
Indeed, but see above.
> > Aha, a presets file is something I hadn't considered.
> > I'd definitely want to keep it seperate from the other files though.
> Then you have to find a way to satisfactorily reference services. DVB's
> ONID:TSID:SID may not be sufficient, as e.g. here in Germany, ASTRA
> satellite transponders are fed into the cable networks with exactly the
> same ONID:TSID:SID's, so a preset file using only that would not allow
> selecting whether the service is to be received from cable or from
> satellite (if both are available)... OTOH, services might move and their
> ONID:TSID:SID might change, but it will still be the same service. For such
> cases, referencing the service name would be better, but some service names
> can be found several times, e.g. I think there are a couple "Bloomberg"'s
> on ASTRA 19.2°E... Maybe the presets file should contain ONID:TSID:SID
> _and_ service name (and maybe network and provider name) and even the
> adapter ID, so that the application can then look for the closest match.
Duplicate channels on seperate sources are not a problem as each transponder
knows what source it is from. But yes, identifying duplicate channels from
the _same_ source are a problem you are right.
Previously I've used a combination of the frequency, the polarization, the
ONID, TSID, and SID in order to uniquely identify a service. Not nice :(
More information about the linux-dvb