|
Rockbox mail archiveSubject: Re: RuntimeDatabaseRe: RuntimeDatabase
From: Jonas H. <rasher_at_rasher.dk>
Date: Sun, 17 Apr 2005 14:47:01 +0200 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 runtimedb? > >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 positive effects. > >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. 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. -- Jonas H rasher(at)rasher(dot)dk -- no .sig today _______________________________________________ http://cool.haxx.se/mailman/listinfo/rockbox
Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |