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. > I don't want to impose restrictions like that - for my purposes, putting > all types of transponders together in one file is exactly what I want to > do. As for the type of locator/transponder, in each [transponder] section, > 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. > 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... > I'm sure I remember seeing a transponder where all the channels > had the same service_id as well :( No, that's not possible. The service_id references the program_number in the PAT, and if they all had the same service_id, they'd all point to the same PAT entry, and thus to the same PMT, i.e. be all exactly the same service. > 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. FWIW, I think most set-top-boxes simply copy the entire locator/transponder data into the preset storage, which results in them retaining stale data even if the scan finds the updated ones. Using a smart referential approach would fix this... Regards, -- Robert Schlabbach e-mail: robert_s@xxxxxxx Berlin, Germany
