Andrew de Quincey wrote: > On Sunday 12 June 2005 22:00, Manu Abraham wrote: >>Andrew de Quincey wrote: >>>On Sunday 12 June 2005 21:38, Patrick Boettcher wrote: >>>>Hi, >>>> >>>>On Sun, 12 Jun 2005, Andrew de Quincey wrote: >>>>>>Attached is my current channels.conf and a hacked version of scan which >>>>>>prints out the service_id at the very end. It is not a big problem to >>>>>>add in to parse the VDR format too, as i had a parser for the Metzler's >>>>>>libdvb format also, but temporarily removed of all those bells and >>>>>>whistles to make testing and debugging easier.. >>>>>I'd be interested in helping with parsing the file formats to start with >>>>>- if they were to be exported into a seperate library that is. >>>>> >>>>>Looking at VDR 1.26 there are three config files: >>>>> >>>>>From what I know the channels.conf-format from 1.3.* changed >>>> >>>>significantly. I would first implement 1.3-parsing and later, if really >>>>necessary (1.4 (= stable) is near), later implement support for >>>>1.2-format, if at all. >>>Ah thats a good idea. I'll have a look into 1.3.x then. >>> >>>OK, where do I get the ca_zap sources - so I can see what is there >>>already and start some coding? >>I have not committed the sources to CVS or anywhere, i would wait for a >>day or two to go through it again/test things out before i make it public. > > No problem. I've been thinking about additional structures to cope with VDR's > extra configuration information (basically struct source_params and struct > diseqc_params). > Since we are going to have multiple uses for it, it would need more config information.. > BTW Patrick, I downloaded VDR 1.3.26 - I couldn't see any changes to the > config files in 1.2.6 really. Hmm, I notice I said 1.26 initially - that was > wrong - I meant 1.2.6 sorry. > > I have a couple of questions about channels.c tho: > > 1) As far as I can see, the code parses the file every time a channel is > requested. The problem is that with VDR you need to parse 3 files, so the > time required is going to get longer. If we loaded the config files into > memory, we could then just convert them internally into a common set of data > structures... although that means we do use more memory I suppose... > Initially this was just a hack that i had to read in a single line only (ie one single channel). I needed to get ca_zap and the libs going on, the factorization came later when i started upon splitting things up to avoid a potential hairloss.. Reading the entire config into memory is not a bad deal, but would depend on the channels list size again.. But in general cases that wouldn't be a big problem i guess consoidering that even embedded systems these days have around 64Megs at least .. > 2) In channels.h, you define "struct channel_params" as having seperate > entries in the strurcture for bandwidth/polarity etc. Would it not just be > easier to embed a struct dvb_frontend_parameters directly in there? Then you > could just parse it once and pass it directly to the dvb IOCTLs etc. > > Attached is an example revised header file including the above points - just > for discussion though... I've no problems being told it is total rubbish :) > I don't mind reusing the structures from the API itself rather than me defining it again. Manu
