On Sat, 16 Apr 2005, Jonas H. wrote:

> I mostly agree with this, but when you are updating the songdb, wouldn't you
> - in 99,9% of the time - have the player (and hence the runtimedb) available
> to consider during the update? I understand why in theory it is a bad thing,
> but is it really a serious issue? It may be that I'm missing something, but
> I'm afraid I need some lengthier examples..?

Yes, in most cases I will have it around. But I don't want to be *forced* into
having it. I have a mirror of all my songs on my local harddrive and I always
run things like songdb.pl on my local copy and not on the mounted music
player.

Given my suggestions, you can simply generate a new songdb the same way you
generated the previous one. Then you deal with upgrading the runtimedb
separately. Either on host (preferably), or on target (sloooow).

Especially the part with using the previous songdb is what bothers me, as this
feels very error-prone and complicated. What if you add a few songs to your
collection, re-build the songdb only to add a few more songs. Which is the
previous songdb you are gonna use then in the next update? (Yes I know which,
but many users are bound to do wrong here.)

> If we're going to hash files, I suggest we do it by hashing X kb from a
> certain point in the file.

Not a bad idea, but it would make a much slower operation. When the songdb is
updated, it has song name and lots of tags already in there so calculating a
hash based on those wouldn't imply any other files to read.

> 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
have file duplicates (file1 and file2 with the exact same contents).

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
> changes until you update the db (accessible through the menu. This sounds
> like the right way go to me.

That is indeed a good idea, as it might be a rather slow (and battery sucking)
operation.

> Doesn't seem to be many real comments from me here.. think I agree with you.

Goodness!

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
   player, we don't even have to know or care really. It might be the same db,
   it might not.

o When the runtimedb lookups an entry in the songdb (using direct offset), it
   always checks the hash to verify that this is in fact the same hash as it
   was the last time.

o If the hash matches, things are good. If it doesn't, it scans the songdb
   for the hash it knows. The scan is then a linear search through the songdb
   on the given (in the songdb header) intervals.

This way, the runtimedb can take advantage of the parts of the songdb that
remained the same as before, only updating for songs that actually moved.

It can also allow Rockbox to update entry-per-entry and not all at once. I'm
not sure if that is smart or not (disk spinning and thus battery runtime
wise).

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox