On Monday 11 July 2005 10:49, Johannes Stezenbach wrote: > Felix Domke wrote: > > I'm asking myself if the "eloquence" actually makes the format (much) > > more human readable than a short version. Sure you have to lookup once > > how the things are layed out, but after that? > > Personally I like a terse format better, too. 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=<...> [s] usid=<..> name=<..> flags=<..> ca=<..> zap=<..> pmt=<..> 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"). More suggestions welcome! (I've left provider_name out for the moment while we decide what to do with it) I assume the other formats - adapter, and sources are ok? > > Another thing is the speed of parsing. back in the days where we used an > > XML file (the other extreme), the parsing of the channellist data was a > > major part of the boot time. We're happy that this changed, and it was > > probably just a bad idea to use a full xml parser for such a simple > > structure. But that's the reason why i'm a bit scaried. > > > > Probably real world numbers will tell that it isn't as worse as i'm > > currently thinking. I just hate superfluous tokens, especially when they > > make the parsing slower/more painful. Not sure if they are. > > I also went through the xml thing and I share your experiences. > But even a lowly embedded box has a few MByte/sec memory bandwidth > for the CPU, so the size of the files doesn't matter that much > (still, smaller is faster; try to run "wc -l" on your file, it > has to scan through all data to count the \n). > The slowness of xml is due to the much too complicated parser. Heh, been there, done XML too. Wanting to escape from it :) > > >>2.) well, it might be a bit conflictive with my first wish ;), but i'm > > >>missing a "provider_name" entry in the sources. They might be collected > > >>and replaced by a token, though. > > > > > > I was thinking of putting that sort of thing in the presets file - the > > > multiplexes.conf was just for storing the raw information for > > > locating/tuning each multiplex. > > > > You're probably right, but my current understanding is that the > > multiplex.conf is the direct result of doing an automatic channel scan, > > i.e. more or less the contents of the SDT. > > > > But you're probably right, they belong elsewhere. But where? I don't > > like the presets file as I want to have the preset files clean of all > > automatically generated stuff. After all, it should contain just a > > "collection" of services with possible attributes (like another name, > > ...) I wouldn't feel good to include information which could change > > (same as the service's (default) name). > > > > Maybe the should be put elsewhere? > > 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 :( > 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. > > > Wouldn't using lots of wee files be bad though? You'd prolly waste lots > > > of space on your flash filing system :( > > > > Well, "lot's of" would be maybe 3 or 4. Most people only have one list > > of favourites. > > > > (My idea wasn't to put each *service* into an own file, but each *list* > > (like group/movies/action, group/movies/horror, ...). sorry if i didn't > > made this clear) > > 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.
