Bugzilla – Bug 1329
Incorrect (wrong) song playing on Squeezebox player
Last modified: 2008-08-18 10:54:04 UTC
I've reproduced this several times, but can't reproduce it at will. When it does reproduce, nothing's logged. I have no debug flags set. If it helps to diagnose, I can set debug flags. When queueing playlists, I've noted that, at times, the incorrect song is displayed via the CLI. At first, I thought "Oh, a CLI bug - I'll talk to Fred about that" but then, much to my surprise, the same (wrong) song is displayed on the Squeezebox UI. So, what I mean more specifically is: 1. Queue a playlist to play (given an empty queue on that player), 2. The playlist is queued, and a song starts to play, 3. The song displayed on the front panel of the Squeezebox isn't the actual song that's playing. It's some other song. Skipping forward or back by song appears to resolve the problem. I've reproduced this with both a Squeezebox and a Squeezebox2 player. I can probably get it to reproduce again (I've seen it three times so far). So if you need debug flags set, let me know which ones, and I'll get back to you with the relevant details (if I can repro again).
I just received my Squeezebox2 tonight and have seen the same thing. In my case, I was playing a playlist from iTunes. The playlist had some iTunes music store songs in it. The songs were skipped by the player, but their information was being displayed by the player. So, since song 2 in the playlist was an iTMS song, after playing the first song in the list, the third song would start playing, but the title and artist of the 2nd song was displayed. Every time an iTMS song was reached, the display would get one song further off from what was really playing. The web interface was also showing the same wrong song as playing. As mentioned in the original report, hitting back, or play would start playing the song that was being displayed. Hitting forward would go to the song after the displayed song in the playlist.
Vidur - any thoughts on this?
Wild thought: can it be somehow related to 1199?
Oh, and FYI, the code of playlistcontrol (the command used by Jeff) is the same as used by the SlimServer UI. It's duplicated for a couple of reasons but is otherwise identical.
I'm still being dogged by this. I've had this come up 10-15 times in the past week or so. Again, suggestions for debug flags would be appreciated. In general, when I start playing songs, I use the INSERT command (not the ADD command) on an empty playlist. This is how my driver works; I clear the playlist with one button (if that's what I want) and then add to the end of the playlist. Playing somewhat with the remote: . If I use PLAY (i.e. ADD), the problem does not appear to crop up, . If I use INSERT (i.e. the '+' button), I've had this crop up w/the remote. Also, I've noted that INSERT will often "do the wrong thing". That is, if the playlist is empty, and I INSERT an album, I expect the album to be inserted into the playlist in track order. It is, but often the SlimServer starts playing at something other than track #1. It's at this point when it's most likely going to display one song but play another song. Any ideas on this at all. Any suggestions of how I can begin to diagnose this? Thanks ...
d_playlist, d_source is all i can suggest. d_playlist will show the results of the playlist caching and render, d_source tracks playing song, etc.
I've checked in what I believe is a fix to the 6.1 tree. It should show up in the nightly build at http://www.slimdevices.com/downloads/nightly/latest/6.1/ on 4/12/05. If this fixes any or all "incorrect song on Squeezebox" problems (and I believe it should), i'll move it to the 6.0.x branch.
I'm currently running 6.0.1, not 6.1. (I'm concurrently trying to release the AMX NetLinx automation code and that's it's release platform.) Should I upgrade to 6.1, complete testing, then downgrade to 6.0.1? Or could this be checked into the 6.0.2 branch and then I'll back to you quickly? If I upgrade to 6.1, will there be any downgrade issues (i.e. firmware updates to players, database updates, etc) that I need to know about? Thanks ...
The only issue I can think of that may come up by moving between 6.0.1 and 6.1 is related to radio plugins - see the thread at http://forums.slimdevices.com/showthread.php?t=13602. You may have to manually remove the new 6.1 radio plugins (in the ShoutcastBrowser, RadioIO and Pick directories) when you go back to 6.0.1.
Okay, I took a look at this last night. Good and bad. The good: The specific problem reported here appeared fixed. I couldn't make it fail, everything worked great (just as expected), at least while running the v6.1 server. It was, frankly, just wonderful. Things behaved just as I expected in terms of INSERTing songs, and in terms of display information. The bad: The server crashed. I had clicked "Browse Playlists" via the WWW interface (default skin), and boom - server dies. Last entries in the server log file: getpeername() on closed socket GEN80 at /usr/lib/perl5/5.8.5/i386-linux-thread- multi/IO/Socket.pm line 206. Can't call method "titlesort" on an undefined value at /usr/local/slimserver//Slim/Music/Info.pm line 1061. I then reverted back to SlimServer v6.0.1. The nastiness (queueing behavior screwey, display screwey) immeidately reappeared, but I could browse playlists again. If the browse playlist bug is unrelated to your changes, then your patch looks good. Otherwise ... Let me know if you need further information, -- Jeff P.S. FWIW, on the 6.0.1 version without your fix, I see a lot of the following messages in my log file: 2005-04-12 19:21:24.8533 Couldn't retrieve objectForUrl: [file:///home/media/music/Kindermusik/Fiddle%20dee-dee/128%20-%20Kindermusik% 20-%20Little%20Red%20Bird.flac] - skipping! 2005-04-12 19:21:24.8576 Couldn't retrieve objectForUrl: [file:///home/media/music/Kindermusik/Fiddle%20dee-dee/201%20-%20Kindermusik% 20-%20Fiddle-Dee-Dee.flac] - skipping! 2005-04-12 19:21:24.8615 Couldn't retrieve objectForUrl: [file:///home/media/music/Kindermusik/Fiddle%20dee-dee/202%20-%20Kindermusik% 20-%20Bumblebees%20Buzzing.flac] - skipping! A got a slew of those at virtually the identical time, although I didn't observe any errant behavior. Not sure if this is related or not.
The crash that you saw seems pretty unrelated...but I'll check a fix for it into the two branches. I think I'll also move the fix for this bug into the 6.0.x branch.
If you could let me know when the fix for this gets checked into the 6.0.x branch, I'll download a nightly and verify that everything still looks good. Thanks ...
Both fixes should be in the 6.0.x branch. Marking this bug FIXED.