Bugzilla – Bug 3115
Synced player -> SN -> Sign-Off, crashes SlimServer
Last modified: 2008-09-15 14:38:25 UTC
From tim @ http://forums.slimdevices.com/showthread.php?t=21829 I've been enjoying the new Pandora service (Rocks!) and absolutely love it. Prior to this, I've run my 3 sb2's synced to a Shoutcast station for many months without issue. Now, when I use one of these synced players to go into SN for a while, and then sign off, my server behaves lethargic. A quick check in the TaskManager reveals that its using 173,343K and rising. I need to restart the server to restore normal functionality. The problem has happened three times this last weekend and is pretty repeatable. Any thoughts? --tim SlimServer Version: 6.2.2 - 6012 - Windows XP - EN - cp1252
The sn plugin will need to call Slim::Player::Sync::unsync($client,1); when it connects to sn, Better yet, it should probably call Slim::Control::Request::executeRequest($client, ['client', 'forget']); and then add the call to unsync to Slim::Control::Commands::clientForgetCommand() I believe that the player's sync will be restored when it reconnects.
Good, maybe a simple fix. The client should be automatically forgotten after 5 minutes though, and he says he was in SN for "a while". I'll try to reproduce.
Here's what happened when I tried it using trunk. Synced SB2 and SB3 to a RadioIO stream, no problems. Connected the SB3 to SN, the SB2 stopped playing. (is that normal?) Logged off SN, players resynced. Started up RadioIO again, they play in sync. However, as you indicated, the memory starts leaking and cpu usage is high. The web interface now reports: SB2 (synced with SB3 & SB3). Tim, does this match your experience? Will try Dean's suggestion and see what happens.
Andy, >Connected the SB3 to SN, the SB2 stopped playing. (is that normal?) Yes. This has been my experience, When I log on to SN from a synced player the other ones stop as well. I haven't experimented with all the permutations of which player was the one on which the radioIO was initiated and which one drops off, but thats generally what happens. >Tim, does this match your experience? Yes. This matches my experience, I'm glad you were able to reproduce it so quickly! Thank you.
Fixed in r6524 by adding Dean's temporary unsync to clientForgetCommand.
Verified, Works great. Thanks for the prompt response!
Was this also fixed for the 6.2.2 version as of 4/27/2006?
Nope, was only fixed in trunk. I'm going to reopen and backport it for 6.3.
Created attachment 1211 [details] Mem usage after 3 hours
I've backported the fix for this bug to 6.3. It will be in tonight's nightly build.
Verified fixed in SlimServer Version: 6.3.0 - 7895 - Windows XP - EN - cp1252
This bug fix is now part of a released version, and so has been marked closed. If you are still experiencing this problem, please reopen the bug.