Bug 799906

Created attachment 567578 [details]
Example XSPF playlist that won't load in amarok

Description of problem:

I have an XSPF playlist that I'm unable to load in the latest version of Amarok (2.5.0-3). The playlist is correctly detected when I run "Update Collection" and appears under Media Sources Home->Playlists->Saved Playlists->Playlist Files on Disk. However, none of the tracks are actually shown when I try to expand the playlist, and I'm unable to move it to the main playlist frame. 

All the tracks are streams (from di.fm). A pls playlist with the same tracks works fine. I have a similar problem if I try to load the playlist directly using Playlist->Add Media, however, the listed streams load fine if I enter the stream addresses directly using Playlist->Add Stream.

I can confirm the problem on three seaparate systems running Fedora 16 (not all mine).

Version-Release number of selected component (if applicable):

2.5.0-3.fc16.i686
(Also tested on binary built from 2.5-git source)

How reproducible:

Always.

Steps to Reproduce:
1. Add the playlist to the collection
2. Go to Media Sources Home->Playlists->Saved Playlists->Playlist Files on Disk
3. Select the playlist and try dragging it to the main playlist

Alternatively, select the playlist through Playlist->Add Media.
  
Actual results:

Nothing happens.

Expected results:

The tracks listed in the playlist should appear in the main playlist.

Additional info:

I've attached a minimal playlist which demonstrates the problem.

I also filed this bug with upstream but they can't confirm it: https://bugs.kde.org/show_bug.cgi?id=295199

After some looking at the 2.5/2.5-git source code I tracked my problem to the file src/core-impl/playlists/types/file/xspf/XSPFPlaylist.cpp and the triggerTrackLoad() method. The problem seems to be in the code block at line 259:

if( trackPtr )
{
  /**
   * NOTE: If this is a MetaProxy::Track, it probably isn't playable yet,
   *       but that's okay. However, it's not a good idea to get another
   *       one from the same provider, since the proxy probably means that
   *       making one involves quite a bit of work.
   *         - Andy Coder <andrew.coder>
   */
   if( !trackPtr->isPlayable() && ( typeid( * trackPtr.data() ) != typeid( MetaProxy::Track ) ) )
       trackPtr = CollectionManager::instance()->trackForUrl( track.identifier );
}

Coming into this block, trackPtr is non-null and "if (trackPtr)" succeeds, as does the second "if", triggering an update to trackPtr. When it leaves this block, trackPtr is null. If I comment out the "trackPtr = collectionManager..." line, the streams load and play fine.

I don't know exactly what's going on here and why this is a problem for me but not for upstream. I'm hoping someone else can confirm the problem.