Rockbox mail archive
Subject: RuntimeDatabaseRuntimeDatabase
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg <daniel_at_rockbox.org>
Date: Sat, 16 Apr 2005 23:20:34 +0200 (CEST)
Hi
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 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 about
a specific song. That is a convenient and quick cross-reference way as long
as they are in synch.
What about a second way as well? It would uniquely identify a songdb entry.
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).
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
"pointers".
Yes, the refresh is a very costly operation but we could easily have a host
PC program that can do it, if you opt (and remember) to.
The difference between this host program and the one the current suggestion
would require is two-fold:
A) it doesn't need the previous songdb when updating
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.
Date: Sat, 16 Apr 2005 23:20:34 +0200 (CEST)
Hi
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 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 about
a specific song. That is a convenient and quick cross-reference way as long
as they are in synch.
What about a second way as well? It would uniquely identify a songdb entry.
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).
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
"pointers".
Yes, the refresh is a very costly operation but we could easily have a host
PC program that can do it, if you opt (and remember) to.
The difference between this host program and the one the current suggestion
would require is two-fold:
A) it doesn't need the previous songdb when updating
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.
-- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/ _______________________________________________ http://cool.haxx.se/mailman/listinfo/rockboxReceived on 2005-04-16
Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy