[PATCH] ReplayGain tags

[Edward Hades]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20090111/6102b878/attachment.sig