Bugzilla – Bug 9931
playlist (origin: MIP) is not restored after a player reconnects to SC
Last modified: 2011-03-16 04:39:19 UTC
i really hope, i've done enough tests (this time) to exclude a configuration issue on my side... my thesis: a playlist based on a MIP mix created by the PlayerUI or SBC (WebUI doesn't count!) is not restored when the player is disconnected from SC for a few minutes and then returns - instead an empty playlist/old playlist is been used => this type(*) of playlist is not really persistent! (*)maybe this applies to similar types of playlists (e.g. dynamic playlist) too. test case with SBC/SBR + SC, 7.3trunk: - load a album on the SBR with the SBC - create a MIP mix from the first track, start playback - pull power supply from the SBR - wait a new minutes (SC must remove this player from it's active list) - re-power the SBR - playlist contains the album from step 1 and NOT the MIP mix from step 2 As indicated this does not happen if the MIP mix was created by the SC Webinterface. In this case the MIP mix playlist is restored successfully after the player has reconnected. I've tried multiple players (SB3, Boom, SBR - okay almost all players i own ;-) and it was very "reliable". This problem is a bit annoying for me (see thread) so any fixes or hints about how i could help are much appreciated. thanks, Markus
Micheal: Is this related to bug 9933?
unlikely related to bug 9933 as this was simply a target problem (web ui link caused the info to show in the wrong frame). This bug doesn't seem to have an issue with web ui. Is the problem mix being created only via the Controller, or does the IR remote cause the same issue?
both, mip-mixes created by the controller _and_ the player-ui trigger the problem, the web-ui won't.
Can you reliably reproduce this? I don't see why there would be a difference between web and the other UIs, as they use identical commands ("playlist loadtracks listref=musicmagic_mix"). Alan meant it could be a timing issue, as playlists are not written back immediately, but somewhere in the background.
(In reply to comment #4) > Can you reliably reproduce this? I don't see why there would be a difference > between web and the other UIs, as they use identical commands ("playlist > loadtracks listref=musicmagic_mix"). Alan meant it could be a timing issue, as > playlists are not written back immediately, but somewhere in the background. > I can very realibly reproduce this. This power-plugging-thing is just for easy reproduction - i hope(d). It started with a small shell-netcat script which ran on the server and polled the number of tracks on the playlist every minute (via cli). A typical scenario was this: 20:00 load album with 10 tracks (script reports 10 tracks) ... script continously reports 10 tracks 22:00 create and play mip mix with 50 tracks (script reports 50 tracks) 22:30 put SB to standby ... script continously reports 50 tracks 04:00 network connection between SB and SC was interrupted for 5 minutes (after one/two minutes script reports "?" - probably because the player has been removed from SC's list) 04:05 connection reestablished (script reports 10 tracks again) 06:00 alarm goes off with album loaded at 22:00 o'clock I was finally able to narrow it down to "SB must be disconnected for a little time" and "MIP mix must be created by Player-UI (this was my best "test" because it happened a lot) or the controller-UI (just did a few tests)". I was not able to reproduce this problem if the MIP-Mix was created by the Web-UI (tried multiple time). If someone has any ideas what i could do to narrow this down, i'd be very glad :-) thanks, Markus
I found an even simpler method to reproduce this problem: instead of "power plugging" or "network disconnect" just restart SC and it will show the previously loaded album/artist/whatever-playlist and not the mip mix created later. Plugin.pm contains three different calls to $client->execute - one for Player-UI (in playMix) - one for the WebUI (in musicmagic_mix) - one for CLI (in cliPlayMix, probably used by jive) Only the second one survives a restart. Played a bit with the different calls to client->execute but failed (i just don't understand it, that sucks :-)
see also bug 9931 for another possible case.
(In reply to comment #7) > see also bug 9931 for another possible case. > kdf, this is nr 9931 :-)
of course it is. You should be looking at bug 9315 (comment 16). I thought it was obvious :)
Moving to 7.3.3
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out. If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it. Thanks.
For some reason Bugzilla did not change the target when I did this yesterday. Or maybe it was me. In either case, I'm trying it again.
If anybody has a hint (or even better a solution) i would really appreciate it. I'd even take a look myself if i knew where to start...
I expect that the key to this is to trace where in the code the playlist is being saved. Then compare the callers for that function in respect to how an MIP playlist is added vs how a browsedb playlist is created.
change 25842 We need to check for all allowed sub-commands. MIP was using playtracks, but only loadtracks would have triggered storing the playlist.
muchas gracias! worked fine this morning for the first time when i woke up with a MIP mix on my Boom. Now if bug 11582 gets fixed too i won't have to get up on the first alarm ;-)
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.