[PATCH] ReplayGain tags
edward.hades at gmail.com
Sun Jan 11 14:53:52 CET 2009
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
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
Edward "Hades" Toroshchin,
Aides on irc.freenode.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20090111/6102b878/attachment.sig
More information about the Amarok-devel