[PATCH] ReplayGain tags

[Maximilian Kossick]

On Sun, Jan 11, 2009 at 2:53 PM, Edward Hades <edward.hades at gmail.com> wrote:
> 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.

Amarok 1 always did a full rescan after updating the database schema.
There's no reason to change that behaviour (well, it might be nice to
prevent it if the change does not require a rescan)

>> 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).

There are a couple of possibilities for an update mechanism. One
option that was discussed is to read sql scripts and execute them.
Another option that I prefer is to put the update logic into scripts
and run them using QtScript.

> --
> Edward "Hades" Toroshchin,
> Aides on irc.freenode.org
>
>
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>