On Sunday 10 July 2005 14:51, Felix Domke wrote:
> Hi Andrew,
>
> I'm thinking of incorporating the service format of libdvbcfg into an
> application.
>
> The relevant parts of this application are written in C++, and currently
> i'm using a flat file format, but with essentially the same information
> inside as in the proposed one.
>
> So i have some wishes, maybe you (and/or others) can comment on this:
>
> 1.) the file contains many ascii-identifier, especially per-service.
> With a reasonable large service database, for example with ~3000
> entries, this would be ~180k (with 60 bytes of identifiers per service).
>
> I know that they are required for making the file format both
> human-readable and extensible. However, maybe it would make sense to
> compress it a bit further. I know this would change the complete
> "look&feel" of the file, but the question is if a "compression" would
> hurt, as no enduser should ever have to edit this file by hand.
>
> for example, the service-database written by my application currently
> looks like:
>
> 233c:00c00000:0400:0001:193:2087
> DATASYSTEMS TR 24
> p:CANALSATELLITE
> 233c:00c.... (next service)
>
> (for one service), and essentially carries the same information (the
> last line can be extended, for example like
> "c:0001ff,c:010200,c:020021,c:0301ff,p:ProSiebenSat.1" for zapping pids)
>
> (I agree that this is maybe a bit too compressed, a few newlines would
> make it much more easy to read)
>
> Note that this is just for discussion - if people get me convinced that
> the extra space is worth it, i'll be happy. (Before people start telling
> me that discspace is cheap: flash storage isn't, at least not NOR. When
> you're limited to 8MB for your whole system, you start thinking about
> optimizing such stuff. :)
heh :)
Hmm, we could shorten the names of things - e.g. [multiplex] -> [m] and stuff
like that. Would gzipping the file be of any help, or would that slow things
down too much?
> 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.
>
> (reason it that it makes some sense to sort services according to their
> provider_name, as BATs are generally unusable)
>
> of course one could argue that this sorting has to go into the channel
> scanning algorithm - but it's stored as the SDT, and we're otherwise
> mapping the SDT (plus extras) to a file.
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.
Whereas the presets file would allow the user to override channel names, group
them etc etc - it would make sense to have the provider_name in there to
me... does that work for you?
> 3.) as said, i'm using C++, and currently i'm storing, for example the
> transponders, in a hashed map. This has some advantages, because you can
> quickly lookup transponders (and services, they are in another hashmap).
>
> For some reason i'm not storing them as a tree, like libdvbcfg currently
> does ("service" is a list contained in "multiplex").
>
> My wish is that the parser gets split up into a frontend and a backend.
> One part, for example, could manage the fopen, fgets, fclose and the
> storage into the "database", the other part could be something like a
> state machine (or even simpler) which manages just the parsing.
>
> a first draft would be something like:
>
> struct dvbcfg_multiplex_context ctx;
> dvbcfg_multiplex_init(&ctx);
> FILE *f = fopen("channels.conf", "r");
> char buffer[1024];
> while (1)
> {
> char *l = fgets(f, 1024, buffer);
> /* NULL means "EOF" to the parser */
> switch (dvbcfg_multiplex_parse_line(&ctx, l))
> {
> case DVBCFG_MULTIPLEX_GOT_MULTIPLEX:
> my_add_multiplex_to_database(ctx.multiplex.source,
> ctx.multiplex.umid, ctx.multiplex.delivery, ...);
> break;
> case DVBCFG_MULTIPLEX_GOT_SERVICE:
> my_add_service_to_database(ctx.service.usid, ...);
> break;
> case DVBCFG_MULTIPLEX_PARSER_ERROR:
> /* bomb out */
> return ...;
> default:
> break; /* ignore unknown stuff */
> }
> if (!l)
> break;
> }
> fclose(f);
>
> the current API can be kept, with the option to circumvent the frontend
> and use the backend parser directly. I could then store the services in
> the way I want, while still keeping up-to-date with the parser and
> possible new features.
I get you - sounds cool... what about a structure containing a set of callback
function pointers though? I think it might make the parser easier than doing
it line by line.
The default pointers would just do the current stuff, but you could override
them with your own ones.
I'll look into it - in the middle of SI code right now.
> 3.) Favourites.
>
> I need favourites / presets / bouquets / however-you-call-them. ;)
>
> I like the current idea pretty much. The only think I would think of is
> to not have multiple lists in one file. What about a directory, where
> one can collect the preset files? It has the advantage that they could
> be distributed between users without problems (just add the file into
> the directory), and probably even (optionally) maintained from a central
> position.
>
> Hierarchies could be built with directory levels, if the software wants
> to support that. Filenames could be ignored, instead the "[group] name="
> entry will be used.
>
> What do you think about this?
Ooh, I hadn't thought about using a directory structure to store that stuff.
The reason I hadn't implemented presets was that I wasn't entirely happy with
the file format and wanted to think about it.
Wouldn't using lots of wee files be bad though? You'd prolly waste lots of
space on your flash filing system :(
