Created attachment 69236 [details]
Example XSPF playlist that won't load
Version: 2.5.0 (using KDE 4.8.0)
I have an XSPF playlist that I'm unable to load in the latest version of Amarok. The playlist is correctly detected when I run "Update Collection" and appears under Media Sources Home->Playlists->Saved Playlists. 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 can also load one of the listed streams directly if I enter the address using Playlist->Add Stream.
This XSPF playlist used to work on an older version of Amarok (possibly 2.4.x, I can't remember).
I'm running Amarok built from Fedora RPMs but I also built Amarok 2.5.0 myself from source and can verify the problem is still present.
I've attached a minimal XSPF playlist which demonstrates the problem.
Steps to Reproduce:
1) Add the playlist to the collection
2) Go to Media Sources Home->Playlists->Saved Playlists
3) Select the playlist and try dragging it to the main playlist
The tracks listed in the playlist should appear in the main playlist.
Created attachment 69237 [details]
Example PLS playlist with identical track that will load
Both playlists are loaded without problems and play fine on Amarok 2.5-git, build of today.
That's very strange. I rebuilt Amarok 2.5-git today after I saw the last comment and I still have the same problem. I can also confirm that another Fedora user has the problem I reported.
I did some looking at the 2.5-git source code and tracked my problem down to the file src/core-impl/playlists/types/file/xspf/XSPFPlaylist.cpp and the triggerTrackLoad() method. The problematic code seems to be the block at line 259 (which seems to be unchanged from the 2.5.0 tarball):
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 <email@example.com>
if( !trackPtr->isPlayable() && ( typeid( * trackPtr.data() ) != typeid( MetaProxy::Track ) ) )
trackPtr = CollectionManager::instance()->trackForUrl( track.identifier );
Coming into this block, trackPtr is non-null and the "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 everyone. Any ideas?
I can't reproduce this either. Latest Amarok git, KDE 4.8, Qt 4.8 on Kubuntu 11.10. It works fine either through playlist -> add media or by adding to the collection.
Git blame suggests that the longer if statement has not changed since August 2010, and the line after it since August 2008. The first if statement was changed most recently, but even then was December 2010.
I can now confirm the problem on three separate Fedora 16 systems (not all of them mine), running KDE 4.8 with Qt 4.8.
I'll post a bug on RedHat bugzilla and see if they have any thoughts.
I can reproduce this on fedora 17 as well. any hints or clues on how to further debug this?
Which Phonon and Phonon-backend versions do you use?
I have Phonon 4.6 and phonon-backend-vlc 0.5.0 here, phonon-backend-gstreamer is 4.6.0. This might be related to the phonon backend.
I'm also running Phonon 4.6 with phonon-backend-vlc 0.5.0.
I think the track is considered not playable on line 268 and so another trackForUrl request is made, which will return 0 because the track.identifier == "".
The behavior is different on fedora probably because of:
Solid::Networking::status() != Solid::Networking::Connected
Or you happened not to be connected at that point.
I'll have to fix this with track proxies using the data found in the XSPF (in this case it will be minimal). So tracks will always be shown, but might not be playable.
Fwiw, when I tested I was definitely connected and online, and used phonon-gstreamer-4.6.0
Please test with the patch from this review:
Should apply to current master.
the reviewboard patch doesn't seem to be build for me (against amarok-2.5.0 or git master):
/home/rdieter1/git.kde.org/amarok/src/core-impl/meta/proxy/MetaProxyWorker.cpp: In member function ‘virtual void MetaProxy::Worker::run()’:
/home/rdieter1/git.kde.org/amarok/src/core-impl/meta/proxy/MetaProxyWorker.cpp:32:72: error: ‘m_url’ was not declared in this scope
/home/rdieter1/git.kde.org/amarok/src/core-impl/meta/proxy/MetaProxyWorker.cpp: In member function ‘void MetaProxy::Worker::slotNewTrackProvider(Collections::TrackProvider*)’:
/home/rdieter1/git.kde.org/amarok/src/core-impl/meta/proxy/MetaProxyWorker.cpp:60:50: error: ‘m_url’ was not declared in this scope
/home/rdieter1/git.kde.org/amarok/src/core-impl/meta/proxy/MetaProxyWorker.cpp: In member function ‘void MetaProxy::Worker::slotNewCollection(Collections::Collection*)’:
/home/rdieter1/git.kde.org/amarok/src/core-impl/meta/proxy/MetaProxyWorker.cpp:75:47: error: ‘m_url’ was not declared in this scope
(In reply to comment #12)
> the reviewboard patch doesn't seem to be build for me (against amarok-2.5.0
> or git master):
Sorry, updated the patch. Should now build from master.
Patch applies, builds against amarok-2.5.0, and in my own testing, works as advertised. thanks!
Fixed with commit c7847192c8483d03023fb9ed73db5fee5ee82694
*** Bug 299387 has been marked as a duplicate of this bug. ***