On Tue, Oct 14, 2008 at 6:19 PM, Thomas Martitz <thomas47_at_arcor.de> wrote:
> 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)
> return false;
> tcmh.tch.entry_count += tch.entry_count;
> tcmh.tch.datasize = sizeof(struct master_header)
> + sizeof(struct index_entry) * tcmh.tch.entry_count
> + tch.datasize;
> The bytes field for the index file seems to mean something different
> actually, including the size of the header
That's what I have been seeing the Wiki seems to be correct for the 8
tag files but not the master index. The one thought I had was perhaps
the the index file size includes the size of the data in the tag
files. It strikes me that would be handy thing to know for a parser
running on a device with limited resources, but that's purely
I guess the answers in the source code somewhere. I will keep digging
> 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 least
> 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.
I thought if people are using an open source os and an open source
music player it makes sense to get that to sync properly with an open
source DAP software. Especially when you consider that Rock Box lets
DAPs play open source formats like FLAC and Vorbis.
Since Banshee is written in C#, my extension is as well. The Tag Cache
DB handling code and the banshee side are quite seperate. So it would
be fairly simple for anyone that wanted to use it else where. I am
trying to comment the code and make it fairly readable. If there's two
examples of library manipulation then that's only going to help others
that want to build the same thing for other music apps and platforms.
Thanks for the info.
Received on 2008-10-14