Crapness during a db upgrade

[Jeff Mitchell]

On Sun, 10 May 2009 21:13:08 +1000, Seb Ruiz <ruiz at kde.org> wrote:
> Hi folks,
> Just rebased after a little while, and Amarok greeted me with the
> following screen when I started up:
> http://imagebin.ca/view/kRpJq9.html
> 
> I imagine that this is because the db is being upgraded. Is it
> possible to clean this up?
> 
> Specifically:
>  1. Don't group the playlist

The DB upgrade removed the devices table, and recreated it with a proper
unique index.  It is possible that the index could simply have been
altered, but then it would have been an unknown *which* entry of all the
duplicated entries that were being created (since every time Amarok was
opened it would create new entries) would end up "winning", and you'd have
to do a full rescan anyways (which the DB upgrade triggers) -- so I simply
did the cleaner approach.

The issue with the tracks is probably that without the devices table they
can't find the right rpath for the tracks.

>  2. Fall back to Meta::File if we don't have a track so we can still
> retrieve meta info (might be bad on large playlists)
>  3. Refresh the playlist/current track when the scan is complete

One thing that might be possible -- but possibly hacky and slow -- would be
to set a flag for the collection rescan triggered by a database update to
have AFT emit the updated information for each track that is scanned. 
Since it basically says "here's the sqltrack uidUrl and here's the new Meta
information" this should work, but I'm not sure whether emitting e.g.
40,000 signals and having each one processed by each track in the playlist
is a good idea, or if it'd be unbearably slow.

--Jeff