I moved over to 7.3 using yesterday's nightly. Now I find that if a player has been powered off (not from the remote, physically pulling the power cord out) then it loses it's sync settings when turned on again.
Since this is so different to the behaviour under 7.2, where all the sync settings were retained through a power cycle, I wondered if this was a bug or now the intended behaviour. I did search bugzilla but I didn't find anything.
Richard
Results 1 to 10 of 10
Thread: 7.3 Sync bug?
-
2008-11-16, 11:19 #1Senior Member
- Join Date
- Apr 2005
- Location
- UK
- Posts
- 332
7.3 Sync bug?
-
2008-11-16, 12:04 #2Senior Member
- Join Date
- Sep 2006
- Location
- Zurich, Switzerland
- Posts
- 794
I guess that this is probably a bug. The operating assumption with SBs is that they are never really powered down. I certainly did not test such a scenario. On the face of it, however, it should work, both from a top-level intention point-of-view, and how I designed that area of the code.
-
2008-11-16, 12:08 #3formerly known as Fletch
- Join Date
- May 2005
- Location
- Lake Oswego, OR
- Posts
- 2,162
Alan, I've seen many instances with 7.3 where synced players become unsynced. In my case, neither player is ever unplugged. I can't figure out how to reproduce it though...
-
2008-11-16, 12:15 #4Senior Member
- Join Date
- Sep 2006
- Location
- Zurich, Switzerland
- Posts
- 794
Well I can see why it happens in the unplugged case (power or network). When the player is "forgotten" (Slim::Player::Client::forgetClient()) it is unsynced, which is permanent - the syncgroupid preference is removed.
I'll have to think about the correct solution.
-
2008-11-17, 10:19 #5Senior Member
- Join Date
- Apr 2005
- Location
- UK
- Posts
- 332
Thanks for the update. Do you want me to raise a bug?
Richard
-
2008-11-17, 13:09 #6
7.3 Sync bug?
I have noticed a change in behaviour too with syncing under SC7.3.
I have two players synced - a Transporter and a Boom. I have sync settings set to persist from power off.
Sometimes both players are both playing the music in sync, but the Boom is displaying the power-off date/time screensaver. No button presses seem to wake it out of the date/time screensaver.
I'm not sure how I get into this state - I've tried various things, but failed to nail down when it occurs. I've seen it in this state a few times now though.
Phil
-
2008-11-18, 00:03 #7Senior Member
- Join Date
- Sep 2006
- Location
- Zurich, Switzerland
- Posts
- 794
What exactly do you mean by this?
This is very disappointing. I went to a lot of trouble to prevent exactly this type of scenario. player.source=info and player.sync=info logs should be sufficient to diagnose the problem, if you can recreate it.Sometimes both players are both playing the music in sync, but the Boom is displaying the power-off date/time screensaver. No button presses seem to wake it out of the date/time screensaver.
I'm not sure how I get into this state - I've tried various things, but failed to nail down when it occurs. I've seen it in this state a few times now though.
Alan.
-
2008-11-18, 09:25 #8Senior Member
- Join Date
- Sep 2006
- Location
- Zurich, Switzerland
- Posts
- 794
-
2008-11-21, 10:56 #9Senior Member
- Join Date
- Apr 2005
- Location
- UK
- Posts
- 332
I've just experienced something similar to Phil. I installed yesterdays nightly, one SB3 was off overnight and I'm pleased to say that when I turned my SqueezeCenter PC and then the SB3 it had remembered the sync settings.
However, I had 2 x SB3 and 1 Boom synced, both SB3s were fine but the Boom was not playing ball. It had the correct display for the track progress (using MusicInfoSCR) but no sound came out. Changing the volume looked to behave properly as the display changed to the volume screen but it had no effect on the level of silence from the Boom. Pushing the Boom knob made it display the Date/Time screensaver as if it was off, but after a short period would revert to the now playing screensaver.
Stopping and restarting the music made no difference. Turning the Boom off and on again using the front button fixed it.
This is the contents of my log file if it's of any use:
RichardCode:[08-11-17 19:27:30.6593] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7260 [08-11-17 19:28:42.0973] Slim::Networking::SqueezeNetwork::PrefSync::_syncUp_error (576) Sync Up failed: No such player: 00:04:20:06:1b:e9 [08-11-17 19:29:44.0701] Slim::Hardware::IR::executeButton (1088) Error: Subroutine for irCode: [voldown_front.hold] mode: [] does not exist! [08-11-17 21:28:30.1684] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7290 [08-11-17 23:17:38.5630] Slim::Networking::SqueezeNetwork::PrefSync::_syncUp_error (576) Sync Up failed: No such player: 00:04:20:06:1b:e9 [08-11-18 17:21:05.7542] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7320 [08-11-18 17:22:40.3507] Slim::Networking::SqueezeNetwork::PrefSync::_syncUp_error (576) Sync Up failed: No such player: 00:04:20:06:1b:e9 [08-11-18 19:23:05.1594] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7350 [08-11-18 19:31:39.5021] Slim::Networking::SqueezeNetwork::PrefSync::_syncUp_error (576) Sync Up failed: No such player: 00:04:20:06:1b:e9 [08-11-18 21:25:35.1742] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7380 [08-11-18 23:20:27.8394] Slim::Networking::SqueezeNetwork::PrefSync::_syncUp_error (576) Sync Up failed: No such player: 00:04:20:06:1b:e9 [08-11-20 18:02:08.8907] Plugins::TitleSwitcher::Settings::__ANON__ (37) GOT here [08-11-20 18:02:08.9014] Plugins::TitleSwitcher::Settings::__ANON__ (39) GOT here TOO [08-11-20 18:14:07.5084] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7410 [08-11-20 19:28:12.8354] Slim::Networking::SqueezeNetwork::PrefSync::_syncUp_error (576) Sync Up failed: No such player: 00:04:20:06:1b:e9 [08-11-20 20:17:37.1609] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7440 [08-11-20 22:21:37.1579] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7470 [08-11-20 23:18:03.3205] Slim::Networking::SqueezeNetwork::PrefSync::_syncUp_error (576) Sync Up failed: No such player: 00:04:20:06:1b:e9 [08-11-21 17:15:17.4793] Slim::Networking::SqueezeNetwork::PrefSync::_syncDown_error (359) Sync Down failed: No such player: 00:04:20:06:1b:e9, will retry in 7500 [08-11-21 17:27:56.9888] Slim::Networking::SqueezeNetwork::PrefSync::_syncUp_error (576) Sync Up failed: No such player: 00:04:20:06:1b:e9 [08-11-21 17:32:55.8307] Slim::Hardware::IR::executeButton (1088) Error: Subroutine for irCode: [voldown_front.hold] mode: [] does not exist! [08-11-21 17:33:02.1881] Slim::Hardware::IR::executeButton (1088) Error: Subroutine for irCode: [volup_front.hold] mode: [] does not exist! [08-11-21 17:33:08.9381] Slim::Hardware::IR::executeButton (1088) Error: Subroutine for irCode: [voldown_front.hold] mode: [] does not exist!
-
2008-11-24, 15:58 #10
7.3 Sync bug?
>> I have sync settings set to persist from power off.
>What exactly do you mean by this?
>
Sorry, I think I was mistaken. I thought there was an option to remember/forget synchronised players when players are turned off, but I can't find that option.
I have two players in a sync group - "Lounge" and "Boom Study". They stay synchronised, even when I power off the players, stop the server and restart, etc.
>> Sometimes both players are both playing the music in sync, but the Boom
>> is displaying the power-off date/time screensaver. No button presses
>> seem to wake it out of the date/time screensaver.
>>
>> I'm not sure how I get into this state - I've tried various things, but
>> failed to nail down when it occurs. I've seen it in this state a few
>> times now though.
>
>This is very disappointing. I went to a lot of trouble to prevent
>exactly this type of scenario. player.source=info and player.sync=info
>logs should be sufficient to diagnose the problem, if you can recreate
>it.
>
Haven't noticed it since I mentioned it here. If I can recreate it I will grab the info log and upload on a bug report.
Phil

Reply With Quote

