Rockbox mail archiveSubject: Re: RuntimeDatabase
From: Jonas H. <rasher_at_rasher.dk>
Date: Sat, 16 Apr 2005 23:50:43 +0200
On Sat, Apr 16, 2005 at 11:20:34PM +0200, Daniel Stenberg wrote:
> I read through the latest version of the RuntimeDatabase wiki page and I
> thought I'd jot down my comments.
> I really don't like how this format lacks support for upgrading of the
> songdb by simply copying a new db to the player. This format requires that
> you update the songdb (and runtimedb) with a special command line. (I could
> argue some more with lenghtier examples on how this is bad, but...)
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..?
> I propose that we make adjustments to make sure this becomes possible.
> I say this takes two things to make it good:
> 1. The current runtimedb uses offsets (only) into the songdb to get info
> a specific song. That is a convenient and quick cross-reference way as
> as they are in synch.
> What about a second way as well? It would uniquely identify a songdb
> Given some thought, I'm sure we can think of something else than the full
> path name. Possibly a hash of the full path, or a hash of some vital tags
> (it would give interesting support for renames).
If we're going to hash files, I suggest we do it by hashing X kb from a
certain point in the file. For mpeg files, the obvious choice would be
to start from the first mpeg frame and likewise for other formats -
start hashing from the first byte of data (as opposed to metadata). This
way editing tags etc. won't confuse the db, nor will renaming/moving. I
think this is the fastest/easiest and most precise way to do it. Of
course this makes the task even worse for the players
(I'm guessing the devices wouldn't enjoy reading and hashing a file
much? I may be underestimating them here..).
> 2. Detect an update and adapt.
> Perhaps we could have the songdb have a random id/sequence in its header,
> and the runtimedb would store that and check that on start and after USB
> attach to detect updates. On an update, it would need to refresh all its
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.
> Yes, the refresh is a very costly operation but we could easily have a
> PC program that can do it, if you opt (and remember) to.
> The difference between this host program and the one the current
> would require is two-fold:
> A) it doesn't need the previous songdb when updating
Because of the hashes.. smart :)
> B) it is optional as it can be done on target after update
> Okey, these are my suggetions that of course are based on what I would like
> to see and how I would like to use this. I'm very interested to read what
> others have to say.
Doesn't seem to be many real comments from me here.. think I agree with
-- Jonas H rasher(at)rasher(dot)dk -- I'm using Free software to post this. Are you?