On Thursday 16 June 2005 01:58, Robert Schlabbach wrote: > From: "Andrew de Quincey" <adq_dvb@xxxxxxxxxxxxx> > > > 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 > > is. > > 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 > resolved... 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 :(
