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. Felix
