[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amarok-devel
Subject:    Re: [PATCH] ReplayGain tags
From:       Edward Hades <edward.hades () gmail ! com>
Date:       2009-01-11 13:53:52
Message-ID: 200901111654.09550.edward.hades () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 11 January 2009 15:25:17 you wrote:
> What Seb said.  For a value that is (a) different for every track and (b)
> each track only has one, an extra table doesn't save any storage and just
> introduces JOIN overhead.

Ah, okay, /me thought it was NULL, not zero.

> Which is why I'd like a "find new metadata" mode for
> amarokcollectionscanner. Bugging the user about something that should just
> happen is also not good, IMHO.  I'll have a look at how easy this would be
> to implement.

Yes, updating metadata transparently is better than bugging the user, but:
1) it may bring a degree of instability to existing incremental scanning code 
(or may not, which would be the preferred matter of things);
2) there's no way (or at least i can't see any) of knowing beforehand which 
files contain the metadata we want to update. So, essentially incremental 
metadata update would need to scan all the collection. And here I think the 
user has the right to know, why the hell Amarok started rescanning his 5 
terabyte music collection at startup (remember, that the operation is CPU- and 
HDD-consuming);
3) the important fact is also that metadata updates would hardly happen very 
often in the future, so perhaps it isn't even worth programming.

> The old logic didn't make any sense

Ah, nice, that's what I thought of it ;).

> Not that it ever mattered before: Amarok 2.0 was released with database
> version 1 and couldn't have conflicted with Amarok 1.x, since the database
> type changed.  Before 2.0, asking devs to delete their old database when it
> changed was fine.

Makes sense, yes. Perhaps we might also want to develop a consistent database 
schema update mechanism (but not unless we plan any more updates in 
foreseeable future).

-- 
Edward "Hades" Toroshchin,
Aides on irc.freenode.org



["signature.asc" (application/pgp-signature)]

_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


[prev in list] [next in list] [prev in thread] [next in thread]