Regressions with new playlist code

[Casey Link]

On Fri, Oct 10, 2008 at 12:10 PM, Casey Link <unnamedrambler at gmail.com> wrote:
> Something else..
>
> As far as I can tell the playlist is no longer doing a trackForUrl()
> lookup on tracks it loads on startup from the current.xspf file.. and
> it should be. Otherwise, service tracks aren't tied to their service
> and the user sees a non-descriptive url.
>
> Casey
>

Ok I've figured out what is going on here.

The playlist used to have a restoreSession() method which opened
current.xspf and loaded the tracks into the playlist. However, with
the new playlist the restoreSession() method is gone, and the playlist
automatically restores when the model is instantiated.


So starting amarok now looks like this:

Amarok (App.cpp) -> Mainwindow -> Playlist Model -> Restores the
playlist (trackForUrl) ->  ... other stuff ... -> ServicePluginManager
is ran -> Services are created

ServicePluginManager is the class that starts the loading of services,
and also registers as a TrackProvider for all the services. This is
important because _even_ if a particular service (e.g., Mp3tunes, or
Magnatune) hasn't started yet as long as the ServicePluginManager has
registered as a TrackProvider the Playlist's trackForUrl call can be
caught and stored for later when the service is ready.

So, the playlist should not restore *until* the ServicePluginManager
has been loaded.

Why does this matter?

Because the user should not see (at startup):
http://www.binaryelysium.com/images/Amarok_magnatuneplaylist.png

they should see (at startup):
http://www.binaryelysium.com/images/Amarok_magnatuneplaylist_good.png


See line 558 here
http://kollide.net:8060/browse/Amarok/src/App.cpp?r1=18428&r2=18504
to see the crucial code that was obliterated.


Casey