[PATCH] ReplayGain tags

[Andrew Turner]

There is a good reason to check for dbVersion > DB_VERSION. Sometimes
users upgrade to a new version of Amarok, which updates their
database. Then something pisses them off and they try to go back to
their old version. That check used to be used to prevent an old
version of Amarok trying to use a newer Amarok's DB and doing
unpredictable nastiness - it exited with a fatal error instead, I
think. Not exactly user friendly, but probably nicer than deleting the
user's statistics (and everything else).

-andrewt512

2009/1/11 Alex Merry <kde at randomguy3.me.uk>:
> On Sunday 11 January 2009 10:08:22 you wrote:
>> The first is that, perhaps, from the general view of database design, it
>> would be better to put replayGain stuff in another table, referenced by
>> foreign key.
>
> 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.
>
>>
>> > I incremented the DB_VERSION to 2 and made DatabaseUpdater::update()
>> > modify the tracks table if the version of the existing database was 1.
>> > Also, it does a full collection rescan (since an incremental scan only
>> > checks for changed files - there is no "look for new metadata in all the
>> > old files without clearing out the database" mode for collectionscanner).
>>
>> I don't think this would be a nice behavior. I'd make it pop out a message
>> saying something in lines of "Amarok needs more information from your music
>> files, please rescan your collection to enable shiny new features".
>
> 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.
>
>>
>> Also, I am not exactly sure the update logic is correct, because i can't
>> fully understand the old logic (why was there dbVersion > DB_VERSION?).
>
> The old logic didn't make any sense - in addition to having the DB_VERSION
> check the wrong way round, it wouldn't have DROPed the tables before CREATEing
> new ones, only cleared out their contents.  Hence my upgrade logic (since
> adding two new fields doesn't require dropping the existing database anyway).
>
> 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.
>
>>
>> As a minor rant, I'd make qreal variables initialized with 0.0 instead of
>> 0.
>
> OK.
>
> Alex
>
>
>
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>