Fwd: Regressions with new playlist code

Casey Link unnamedrambler at gmail.com
Mon Oct 13 14:09:48 CEST 2008


I'm forwarding this to the list, and to Soren, just to make sure it
doesn't get lost in the shuffle. This bug is a showstopper/workstopper
for me,  and exposes unnecessary/confusing implementation details to
the user. Not to mention breaks the use of service tracks in
playlists.

Casey

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


More information about the Amarok-devel mailing list