Rockbox mail archiveSubject: Re: RuntimeDatabase
From: Daniel Stenberg <daniel_at_rockbox.org>
On Sat, 16 Apr 2005, Jonas H. wrote:
> I mostly agree with this, but when you are updating the songdb, wouldn't you
Yes, in most cases I will have it around. But I don't want to be *forced* into
Given my suggestions, you can simply generate a new songdb the same way you
Especially the part with using the previous songdb is what bothers me, as this
> If we're going to hash files, I suggest we do it by hashing X kb from a
Not a bad idea, but it would make a much slower operation. When the songdb is
> This way editing tags etc. won't confuse the db, nor will renaming/moving.
... but will of course have the exact same issue (as the hash on tags) if you
That's not an actual argument, just a fact that I came to think of.
> I think this is the fastest/easiest and most precise way to do it.
Most precise yes, fastest no.
> Or at least ask "do you want to update?". And if not, you lose runtimedb
That is indeed a good idea, as it might be a rather slow (and battery sucking)
> Doesn't seem to be many real comments from me here.. think I agree with you.
I came to think of an implementation approach for target runtimdb resynchs:
o We store the entry hash in the songdb. When a new songdb is put on the
o When the runtimedb lookups an entry in the songdb (using direct offset), it
o If the hash matches, things are good. If it doesn't, it scans the songdb
This way, the runtimedb can take advantage of the parts of the songdb that
It can also allow Rockbox to update entry-per-entry and not all at once. I'm
-- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/ _______________________________________________ http://cool.haxx.se/mailman/listinfo/rockboxReceived on Sun Apr 17 01:49:55 2005
Page was last modified "Jan 10 2012" The Rockbox Crew