[linux-dvb] Re: some libdvbcfg wishes, preset format

Felix Domke tmbinc at elitedvb.net
Tue Jul 12 01:06:10 CEST 2005

Andrew de Quincey wrote:
> I still like the [sections] idea - although if you can suggest a clearer 
> format, I won't insist on them :)
> What about something like:
> [m]
> gmid=<...>
> d=<...>
After thinking about it again, it like it more and more.

> The "delivery" stuff could be greatly shortened by simply using the frontend.h 
> integer values instead of the massive strings it is right now (e.g. "0" 
> instead of "INVERSION_OFF").
Yes, i vote for that.

We can still have a fixed header which explains the different values (as
human readable comment)

> I assume the other formats - adapter, and sources are ok?
For some reason i'm not planning to use "sources", and i haven't yet
decided about "adapters".

But i'll think about that again.

>>I vote for adding the provider_name to the service info
>>in the multiplex file (can't think of a better place
>>to put it).
> Will that not add lots of duplicate string entries though, again increasing 
> the file size? I suppose another option as Felix suggests would be to have 
> just the ID in the multiplex file and the actual strings in another.. of 
> course we then get the problem of clashing provider IDs :(
Well, it would be nothing more than some kind of compression. all
different provider_names must be collected, and there must be something
like a map at the start which maps them to the numbers.

>>BTW, it seems this file has undefined character encoding?
>>We should define the encoding to be utf-8.
> Yeah - I was thinking of UTF8, but never actually wrote it down anywhere. 
what's about the special DVB chars? I vote for just including them, of
course UTF-8 encoded.

>>Will there be a "list of lists"? I.e. how is the order of
>>favourites lists in the menu defined (to make sure that
>>"daddy's list" comes first)?
>>Flash file systems don't waste much space for small files, so
>>having a number of small files is not an issue.
> hmm, yeah, you'd have to have an index file. Do you think we need a full 
> hierarchical structure though? Thats what was causing headaches for me.
A stupid idea, just to think about that option:

What's about sorting the filenames (of the lists), thus defining the
list? (The name of the lists are defined inside the list..)

But I agree that this is probably going to be a bad idea. the advantage
would be that you could import favourites without editing any file, the
disadvantage is that, on hierarchies, the "directories" can't be named.


More information about the linux-dvb mailing list