Bugzilla – Bug 2189
Playlist get broken (contains numbers)
Last modified: 2009-09-08 09:27:51 UTC
I still get broken playlists with the 2005/09/20 nightly of slimserver 6.2. When adding new songs to a playlist using the remote the saved playlist file contains number like this: #CURTRACK 13 #EXTM3U #EXTINF:-1,Gekommen um zu bleiben D:\Eigene Dateien\Eigene Musik\mp3\Wir sind Helden\Wir sind Helden - Gekommen um zu bleiben.mp3 2458 #EXTINF:-1,Nur Ein Wort D:\Eigene Dateien\Eigene Musik\mp3\Wir sind Helden\Wir Sind Helden - Nur Ein Wort.mp3 #EXTINF:-1,Narcotic D:\Eigene Dateien\Eigene Musik\mp3\Liquido\Liquido - Narcotic.mp3 #EXTINF:-1,Ich lebe D:\Eigene Dateien\Eigene Musik\mp3\Christina Stürmer\Christina Stürmer - Ich Lebe.mp3 #EXTINF:-1,Lemon Tree D:\Eigene Dateien\Eigene Musik\mp3\Fool's Garden\Fool's Garden - Lemon Tree.mp3 #EXTINF:-1,Lonely D:\Eigene Dateien\Eigene Musik\mp3\Akon\Akon - Mr. Lonely.mp3 265 2480 2461 When I want to play the complete playlist on the squeezebox an error message is displayed that some songs cannot be played and when scrolling through the playlist some songs are shown correctly but in addition some empty lines and some lines only containing numbers are shown.
right, so I posted more questions to the forum. feel free to answer those here instead.
I always use the remote and most of the time search for songs when creating playlists. In detail I have just created a new playlist with the following steps: 1. selected a song using the remote via "browse artist", selected an artist, then an album and then an song and pressed play to insert it as the first song in the "now playing" playlist. 2. selected a song using the remote via search for songs and pressed + to add it to the "now playing" playlist. 3. selected another song using the remote via search for songs and pressed + to add it to the "now playing" playlist. 4. switched to the "now playing" playlist and pressed and hold play to save the playlist (simply under the name "A" be pressing twice right. 5. went to the server an had a look at the newly created A.m3u, it looks like #CURTRACK 0 #EXTM3U 1730 258 1154 I also just found that trying to edit such a playlist on the web interface crashes slimserver (firefox shows a windows with "the window contains no data"). Dieter
I saw this on my nightly system last night. Started a rescan (to pick up an album I just added to my collection, then clicked to play an existing playlist. KDF: are you working on this?
sadly, the collection of comments across the numerous bugs claiming to be different yet all oddly mention numbers in playlists, is not making any collective sense in the limited time I have to deal with this. I can't even tell where all of this is coming from, as I cannot reproduce (yet). I was trying to sort out of the recent BMF feature I added was related, but it seems not to be (browsedb used in this case above). As such, I haven't any place to even start looking yet. Dean, was yours an existing good playlist? instinctually, I think Fred may be right that it is something to do with bad info being returned on a db lookup. If I can reprduce this somehow, I'll see if I can find anything useful.
Yes, it was a good playlist. And later on it worked. I'm guessing that the rescan was the trigger for the failure.
so, the good playlist has file urls in the content? if they are id's, it could be that they only work AFTER a full scan, when id's are fully populated with objects.
I see that the playlists contain just numbers in them, not URLs. (I didn't know we did that. Ew.)
I dont think that was teh intent. I think the idea is to store them as ID's in the DB, for space reasonse. Is that correct, dan? it may be that the playlists are being written out without checking that all items have been converted (the server does a lot of lazy conversion of current playlist) I'll try a look at later
ok, reproduced, finally. I added a few songs one by one as described above. press now playing, press and hold play, and save a playlist. A dumper line added in teh playlist save section of Control::Command shows that the list is coming in as track objects, but a dump in Player::Playlist::scheduleWriteOfPlaylist shows just id's. Somewhere between Command.pm line 800 and the Player::Playlist.pm line 579, the tracks came out as ID's only. It looks like DBI::Track::setTracks is putting the $track->id into the create, which may be to save space, and was done way back at change 3507. I'm guess the thing to do is add a couple lines to get the path from ID on Formats::Parse::writeM3U.
ids are what setTracks is supposed to use - it's done explitly because of a LWT / Track issue. The real problem here is - how are ids ending up on the client object's playlist as ids and not as objects. I'm sure this has something to do with your recent changes to song() and the like, kdf.
I dont see how. The bits of code that I altered dont seem to be in the steps for saving a playlist. They are track objects at the save playlist command in Control::Command::Execute, and $playlistObj->setTracks($annotatedList); converts to ID's as it should. Then Slim::Player::Playlist::scheduleWriteOfPlaylist does this: Slim::Formats::Parse::writeM3U( [ $playlistObj->tracks ] and gets an array of id's (as I would expect) writeM3U simply takes the array and writes it out. whether or not I've broken anything, I'm more than happy to try to fix, but I can't see what it comes in. Following those steps, I would totaly expect id numbers in the m3u file. What would have converted them otherwise? I'll try reverting later and retrace, but I could sure use some help. This was also originally reported before I made those changes. bug 2110 was fixed on Sept 24, and this was originally based on the nightly build from Sept 20, even though it was opened on Sept 25. I'll try reverting and see what I can trace.
$playlistObj->tracks should be returning objects, and not ids.
ok. interesting. That would be the missing piece for me. where is the tracks accessor exactly? I've just assumed it was a direct call for the list created by setTracks, so I didn't see how they were anythign but Id's
tracks accessor is setup as a has_many() at the top of Tracks.pm - and that hasn't changed. So something else has. It might be changes to Class::DBI, but I don't think so. If you can reliably reproduce it, go back in time for a bit till you can't.
I'm on it
reverting back to 4300 and doing a complete rebuild of the db still shows this problem. note, it only seems to write out the id's when using the SavePlaylist feature after adding individual songs only. Saving from the web interface seems to work ok, as does adding albums to the playlist and saving via remote. i dont understand the process that allows you to set using id's and then get back objects. Is it possible that some slight alteration of that function call might trigger ids? something like the wantarry returns? I'm back to 4100 now, and currently building the db. I think more and more that this is related to Fred's comments in 2028. 4100 exhibits the same symptoms.
also, when set to 'play all tracks in album' and you press play on a single track among many in an alubm, it works ok. added single tracks with then start to show numbers again. I'll note all this here in case it starts to twig an idea with anyone. from here on, I'm basically just digging around
I was wrong about web save working. I'm able to reproduce with that. it seems that if the call is writeM3U([$playlistObj->tracks]... it will fail sometimes with a mix of lightweighttrack objects and id's if the call is: writeM3U(\@{Slim::Player::Playlist::playList($client)}); then it works, and the array in this case is of track objects. This is currently testing with svn4100 test patch coming soon to show off something I have found....
Created attachment 864 [details] debug patch to show something interesting use this patch (hopefully also works on HEAD). I'm using it at 4100. Now, browse albums->album->press play on a song. navigate to another song, press add. add a few more songs this way. press now playing. press and hold play. then press right twice to just save a playlist called A.m3u. You will now get a dump on the console of the annotated list given to the playlist save command, and the dump of the playlist->tracks content. What I've seen here is that the annotated list is a mix of lightweightTracks and track objects. The playlist->track shows a list of lightweighttrack objects and id numbers. The items that are numbers are track objects in teh previous list. only the lightweight tracks make it through. I cannot go much farther back without setting up another test copy with new prefs. If you need me to dig back farther, let me know. 4100 is dated Aug 27
Thanks - I have some ideas now.
This should be fixed in subversion change 4438