Is this only happening for the Power on Resume or any setting?

What SC revision and browser are you using?

Andre:

I was unable to reproduce this bug using the latest dayly build (SqueezeCenter Version: 7.0 - 17424 - Windows XP - EN - cp1252)

I have not tried Server 2003 yet, but will do that later tonite.

Can you verify that you are clicking on the APPLY button at the bottom of the page when you are making your changes?

Also, could you provide me with the following: 
1) version string you are using -- Settings >  Status > SqueezeCenter Information
2) SB device you are using
3) Browser version you are using

I have been able to reproduce this bug using the SB Reciver (ray) only.

Using the SBC or Transporter I was unable to reproduce this bug.

So what you're saying is that you can't reproduce the issue in the web interface, but only (well, still) with the controller?

I hope I'm paraphrasing accurately: on the way out James told me he saw this bug with Ray but not SB3 or Transporter. I think it has nothing to do with Jive. 

Does SBC=SqueezeBox Controller (aka Jive), or SqueezeBox Classic (aka SB3)? 

I can't reproduce this issue. I've tested a SBR's settings in the Default skin and everything was saved as expected.

Andre:  what web browser are you using?

Created attachment 2876 [details]
Document explaining How and Where the error happens for me.

Setting > Players > Audio > Power On Resume error conditions

Ray Information:
Name: RoscoRay
Model: receiver
Firmware: 22
The IP address for this player is: 172.19.120.56:54582
The ethernet MAC address for this player is: 00:04:20:16:02:7a
Wireless Signal Strength: 95

Name: RayPuppy
Model: receiver
Firmware: 22
The IP address for this player is: 172.19.120.254:43325
The ethernet MAC address for this player is: 00:04:20:16:02:7f
Wireless Signal Strength: 78

SqueezeCenter Host Information:
SqueezeCenter Version: 7.0 - 17491 - Windows XP - EN - cp1252
Server IP address: 172.19.120.239
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt 
Platform Architecture: 586
Hostname: NB-JRICHARDSONT61
Server Port Number: 9000
Total Players Recognized: 6
Cache Folder: C:\Documents and Settings\All Users\Application Data\SqueezeCenter\Cache
Plugin Folders: C:\PROGRA~1\SQUEEZ~1\server\Slim\Plugin, C:\PROGRA~1\SQUEEZ~1\server\Plugins

SqueezeCenter Version: 7.0 - 17491 - Windows XP - EN - cp1252
Server IP address: 172.19.120.239
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt 
Platform Architecture: 586
Hostname: QA-XP-Pro
Server Port Number: 9000
Total Players Recognized: 6
Cache Folder: C:\Documents and Settings\All Users\Application Data\SqueezeCenter\Cache
Plugin Folders: C:\PROGRA~1\SQUEEZ~1\server\Slim\Plugin, C:\PROGRA~1\SQUEEZ~1\server\Plugins

SqueezeCenter Version: 7.0 - 17491 - Mac OS X 10.4.11 (8S2167) - EN - utf8
Server IP address: 172.19.120.76
Perl Version: 5.8.6 darwin-thread-multi-2level
MySQL Version: 5.0.22-standard 
Platform Architecture: x86
Hostname: QA-Mac-mini.local
Server Port Number: 9000
Total Players Recognized: 1
Cache Folder: /Users/qatest/Library/Caches/SlimServer
Plugin Folders: /Users/qatest/Library/PreferencePanes/SqueezeCenter.prefPane/Contents/server/Slim/Plugin, /Users/qatest/Library/Application Support/SqueezeCenter/Plugins, /Library/Application Support/SqueezeCenter/Plugins, /Users/qatest/Library/PreferencePanes/SqueezeCenter.prefPane/Contents/server/Plugins

Browser(s):
Internet Exporer 6.x
FireFox 2.x
Safari 3.0.4

System:
The system host that was controlling the Ray / SC Host combo during the test

Results:
Did the combination of -- Ray > SC7 Host > Browser > System = Pass or Fail

Results:
RAY	        SC Host	                Browser Version	        System	        Result
======================================================================================
RayPuppy	NB-JRICHARDSONT61	I.E. 6.x / FF 2.x	JRICHARDSONT61	Fail
RayPuppy	NB-JRICHARDSONT61	FireFox 2.x	        QA-Mac-mini	Fail
--------------------------------------------------------------------------------------
RayPuppy	QA-Mac-mini.local	I.E. 6.x	        JRICHARDSONT61	Pass
RayPuppy	QA-Mac-mini.local	Safari 3.0.4 (from mac)	QA-Mac-mini	Pass
RoscoRay	NB-JRICHARDSONT61	I.E. 6.x / FF 2.x	JRICHARDSONT61	Pass
RoscoRay	QA-XP-Pro	        FireFox 2.x	        JRICHARDSONT61	Pass
RoscoRay	NB-JRICHARDSONT61	I.E. 6.x / FF 2.x	QA-XP-Pro	Pass

Conclusion:  Only the combination of MY RAY & MY SC7 cause the failure.  Attaching MY RAY to another SC7 OR another RAY to my SC7 does not have an error.  It would appear that there is something wrong with the way my ray is communicating with my SC7 instance.

James is going to upload his prefs files.  Also, do we know if the setting actually works on Ray?   

Michael: any idea here?

James - that's interesting. And it's repeatable?

Please upload server.prefs which you should find below C:\Documents and Settings\All Users\Application Data\SqueezeCenter\. I wonder whether the configuration file is corrupted. But then the prefs are kept in memory in a hash, and only written out later. Thus at least the in-memory copy should be updateable.

Created attachment 2880 [details]
Server log as requested

Uploaded log file as requested

Could you please upload the server.prefs, too?

Created attachment 2881 [details]
Server prefs log

Andre & James - have you been synching your player in question with some other player? The only thing I can't explain (yet) in your configuration file is the initial section like:

20050048-Sync: 
  powerOnResume: PauseOff-NoneOn

(In reply to comment #16)
> Andre & James - have you been synching your player in question with some other
> player? The only thing I can't explain (yet) in your configuration file is the
> initial section like:
> 
> 20050048-Sync: 
>   powerOnResume: PauseOff-NoneOn
> 

yes, i sync 2 player groups with 4 and five players .. with v6.4 i have no problems with this, this option is running well.

> > 20050048-Sync: 
> >   powerOnResume: PauseOff-NoneOn
> 
> yes, i sync 2 player groups with 4 and five players .. with v6.4 i have no
> problems with this, this option is running well.

Thanks for the feedback. Synchronization changed a lot in SC7. Thus I'm not sure whether what you see is a bug or not.

Alan, do you have an idea?

Well it used to be that Ray was not able to (logically) power-off at all. Maybe there are some other changes that assume that that is still the case.

> Well it used to be that Ray was not able to (logically) power-off at all. Maybe
> there are some other changes that assume that that is still the case.

Can you elaborate a bit? Is the behaviour the customer is seeing to be expected? Is it a bug?

(In reply to comment #20)
> > Well it used to be that Ray was not able to (logically) power-off at all. Maybe
> > there are some other changes that assume that that is still the case.
> 
> Can you elaborate a bit? Is the behaviour the customer is seeing to be
> expected? Is it a bug?
> 

- i have install today the newest windows version from youre server
- same problem
- i go to the settings from the 5 players, audio, synchronize, no synchronisation
- i change the Power On Resume on every player to Stop at power off / Restart song at power on
- i set the synchronisation for every player
- this workaround is running well

andré

Alan - is there anything we should do in the settings code?

Ping, Alan!

Alan answering: 

"I am not sure that I have any useful info. All I meant by my previous comment was that maybe there were additional changes made with the original decision that Rays cannot power-off, related to the settings connected to actions on power-on-off. Now that we have decided that Rays can indeed power off, maybe I missed undoing some of these other related changes, if there actually are any."

Will have to dig a bit further...

Michael: Ping!

The behaviour seems to be by design (and _not_ limited to Receiver): from Settings/Player:

} elsif ($pref eq 'powerOnResume') {
 $paramRef->{'prefs'}->{$pref} = Slim::Player::Sync::syncGroupPref($client,'powerOnResume') || 
    $prefs->client($client)->get('powerOnResume');


... which means the sync group's setting takes precedence over the client's setting.

Alan, I'm again asking you whether this must be this way. If yes, then we'd probably have to disable that setting in the pref page while the player is synched (or add a comment explaining the behaviour).

I would agree that the behaviour might need to be synched, but I doubt we should change the player preference to achieve this.

Just noticed that the behaviour change is handled in Slim::Player::Player::power() - do we need to change the pref at all?

Index: /Users/mh/Documents/workspace/SC7.0/Slim/Web/Settings/Player/Audio.pm
===================================================================
--- /Users/mh/Documents/workspace/SC7.0/Slim/Web/Settings/Player/Audio.pm	(revision 17707)
+++ /Users/mh/Documents/workspace/SC7.0/Slim/Web/Settings/Player/Audio.pm	(working copy)
@@ -146,11 +146,6 @@
 			
 			$paramRef->{'prefs'}->{$pref} = Slim::Utils::Prefs::maxRate($client, 1);
 			
-		} elsif ($pref eq 'powerOnResume') {
-			
-			$paramRef->{'prefs'}->{$pref} = Slim::Player::Sync::syncGroupPref($client,'powerOnResume') || 
-								$prefs->client($client)->get('powerOnResume');
-
 		} else {
 
 			$paramRef->{'prefs'}->{$pref} = $prefs->client($client)->get($pref);

I have been unable to understand why this apparently worked with 6.4. There have been lots of changes in this area but none that look relevant,

But the bottom line is that all this stuff is complex, incomprehensible and broken in several different ways. The set of interactions between player->powerOnResume and player->syncPower preferences when turning a synced player on or off are not properly thought out - at least not in a way that I can fathom. I do not think that I can accurately describe how it does work nor how it should work.

On the specific problem in this report, your proposed change Michael, may improve things. As it stands, attempts to change a synced player's powerOnResume preference will succeed but will not be reflected in the UI and will not be honoured as long as the player remains synced. Your change would allow the setting change to be reflected in the UI. But the sync-group will continue to use the value that was copied from the master player when the sync-group was created and there is no means to change it. I suppose the current behaviour allows you to see the current (active) value and you also see, after attempting to change it that it has not actually changed. The only actual way to effect a change in this setting is to unsync all the players in the sync-group, set the powerOnResume value as desired and then recreate the sync-group, at which point (or possibly, some point in the future) the sync-group will adopt the current value from one of the members of the sync-group (the one that ends up being the so-called master).

Fixing it properly requires first to come up with a design, that end-users can comprehend, as to how this should really work.

change 17913 - applying the above patch. Thus the _preference_ is not overwritten, while the behaviour is, as long as the player is synced.

Leaving the "full fix" for the future. Alan - feel free to assign this bug to yourself.

Untargetting and assigning to Alan for new evaluation

Fixed by new-streaming changes in 7.3

Unable to replicate with 7.3 - 23935

Please retest with this version and open if you still experience an issue.

This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Reduce number of active targets for SC