Bug 363515

Summary:	Can not play saved playlist after Amarok restart because MySQL playlist_tracks table rows are missing track url values
Product:	[Applications] amarok	Reporter:	techouse
Component:	Playlist	Assignee:	Amarok Bugs <amarok-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal
Priority:	NOR
Version First Reported In:	2.8.0
Target Milestone:	2.9
Platform:	Fedora RPMs
OS:	Linux
URL:	http://shrani.si/f/2P/aa/U6FOcag/screenshot-from-2016-05-.png
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	A screenshot form Amarok A screenshot of the playlist_tracks MySQL database table

Description techouse 2016-05-25 16:00:44 UTC

When using a local MySQL server as the database for Amarok a saved playlist can not be played after Amarok is restarted because the playlist_tracks table rows do not get populated with track url values. The playlist will play untill Amarok is restarted, but will refuse to play after Amarok is restarted.

Here is a screenshot of the playlist_tracks table with missing url values: http://shrani.si/f/o/wJ/2hmke2H1/nourls.png

To fix this issue one can update the MySQL table in question using a query like this:

	UPDATE playlist_tracks AS pt
	INNER JOIN playlists AS p ON p.id = pt.playlist_id
	INNER JOIN tracks AS t ON pt.title = t.title
	INNER JOIN albums AS a ON t.album = a.id AND pt.album = a.name
	INNER JOIN artists AS ar ON t.artist = ar.id
	INNER JOIN urls AS u ON t.url = u.id
	SET pt.url = substring(u.rpath, 2)
	WHERE pt.url = ''



Reproducible: Always

Steps to Reproduce:
1. save a playlist
2. restart Amarok
3. play the saved playlist

Actual Results:  
Amarok can not play the playlist because it can not find the tracks associated with the playlist.

Screenshot: http://shrani.si/f/2P/aa/U6FOcag/screenshot-from-2016-05-.png

Expected Results:  
Amarok should be able to play the playlist.

Running on Fedora 23, Gnome 3.18.2

Comment 1 Myriam Schweingruber 2016-05-26 09:47:33 UTC

Could you please attach the png to the report?
Where are those tracks located, in the local collection or on an external share?
Could you please test with the default embedded database instead of the external MySQL server?
Could you eventually test if this is reproducible with Amarok 2.9 beta (aka 2.8.90)?

Comment 2 techouse 2016-05-26 09:53:30 UTC

Created attachment 99199 [details]
A screenshot form Amarok

Comment 3 techouse 2016-05-26 09:54:19 UTC

Created attachment 99200 [details]
A screenshot of the playlist_tracks MySQL database table

Comment 4 techouse 2016-05-26 09:58:37 UTC

(In reply to Myriam Schweingruber from comment #1)
> Could you please attach the png to the report?

Done.

> Where are those tracks located, in the local collection or on an external
> share?

They are located in the local collection (local library) and are located on an external hard drive which has been mounted at system boot, before Amarok was started. The path to the library folder is /var/run/media/techouse/Passport/Music/Unsorted

Comment 5 Myriam Schweingruber 2016-05-26 11:27:10 UTC

(In reply to techouse from comment #4)
> (In reply to Myriam Schweingruber from comment #1)
> > Could you please attach the png to the report?
> 
> Done.
> 
> > Where are those tracks located, in the local collection or on an external
> > share?
> 
> They are located in the local collection (local library) and are located on
> an external hard drive which has been mounted at system boot, before Amarok
> was started. The path to the library folder is
> /var/run/media/techouse/Passport/Music/Unsorted

Thank you for the details. Could you test with the embedded database and ideally with current amarok 2.9 beta? There have been quite a lot of changes done to the database since 2.8.0, so maybe this is already solved. 
FWIW: I can not reproduce this on Kubuntu 14.10, Amarok git master (which is only a few commits away from 2.9 beta), collection on an external USB hard drive, default embedded database.

Comment 6 Myriam Schweingruber 2016-06-12 13:01:53 UTC

Any news on this?

Comment 7 Myriam Schweingruber 2017-02-13 18:46:22 UTC

Closing for lack of feedback. Please feel free to reopen this report if you can reproduce this problem and provide the information requested in comment #5.