Charles Mason schrieb:
> I presume this means there's a problem with the DB my extension has
> written. I presume that's a memory address, is there any easy way to
> find out what that relates to?
> Comparing the output of a DB generated with Rock Box and one with my
> Extension I can't see any major differences. The only one I have found
> is with the entry in the index file after the first 4 version bytes
> (offset bytes 4-7). According to the Tag Cache DB Spec in the Wiki
> that is supposed to be the number of non header bytes in the index
> file however in the version created by Rock Box its about 2.5 times
> larger than the actual number of non header bytes. Is the wiki wrong
> and if so what does this field relate to ?
I have, together with ArenOlson worked on that Wikipage. I've pretty
familiar with teh Tagcache file format.
I have to admin though, that I've never written "selfmade" db files, nor
I double checked the bytes field that's bugging you.
The bytes field should be actually state the exact filesize of the file,
minus the header (12bytes), if I'm not wrong.
Looking at my parser, the bytes stated in the db index file also tells
a much higher (1.6x higher) value than the file size is actually.
However, it's correct for the tag (0-8) files.
Looking in tagcache.c, this particular part looks interesting:
/* Update the master index headers. */
if ( (masterfd = open_master_fd(&tcmh, true)) < 0)
tcmh.tch.entry_count += tch.entry_count;
tcmh.tch.datasize = sizeof(struct master_header)
+ sizeof(struct index_entry) * tcmh.tch.entry_count
The bytes field for the index file seems to mean something different
actually, including the size of the header
As being said, I just looked shortly. This needs further investigation,
as the wiki page (and the source code comments?) seem to be wrong, or at
PS: I highly appreciated your work on a external rockbox database tool.
I'd love to have a look at your plugin, and try it out myself.
Received on 2008-10-14