[linux-dvb] Johannes' idea of simple zap (szap)
manu at kromtek.com
Mon Jun 13 00:23:49 CEST 2005
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:
>>>>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
Since we are going to have multiple uses for it, it would need more
> 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.
More information about the linux-dvb