On Sun, Apr 17, 2005 at 01:41:55AM +0200, Daniel Stenberg wrote:
> 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).
The question is, I guess, just how slow it'll be. And how slow we're
willing to accept. I guess people will eithe rhave to deal with the
slowness, or build the db with the player connected.
> 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 see this as a bonus, rather than an issue. These two songs are
essentially the same - why should they have two entries in the
> >I think this is the fastest/easiest and most precise way to do it.
> Most precise yes, fastest no.
I'm not sure how I managed to write fastest there :) Of course it isn't.
The question is - is it worth it? Personally, I'd gladly wait for this,
but it may be too time-consuming, and for some people, not give enough
> >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
> 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
> it might not.
> o When the runtimedb lookups an entry in the songdb (using direct offset),
> 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.
Sounds good, but won't direct offsets always be changed if the db has
changed? Hm.. I guess if it's pointing to the part of the file before
any changes they won't.
> 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).
Sounds like a bad idea to me, but the posibility of doing it can't
hurt I guess.
-- no .sig today
Received on Sun Apr 17 14:50:01 2005