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. :)
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.
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.
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?
regards,
Felix
