that actual default does appear to enabled. Slim::Utils::prefs sets the default to 1. 
Were there any problems logging into SN when you went through the wizard, though I can't see anything that would set the pref otherwise due to email or password issues.

Try erasing the sn_sync from the refs file and restarting, then check the prefs file after SC starts up.

No problems.  It confirmed that I entered a correct user ID and password.

Does it store the default value in the registry?  There was another setting stored there.  I uninstalled and manually deleted the remaining directories of a prior v7 setup, however, I did NOT manually search/clean out the registry - I figured that they uninstall routine would do that.  If so, then somewhere along the line it must have gotten set to disabled somehow.  

Can/should the uninstall routine clean up the registry - if it is storing stuff in there, that is?

Uninstalled 11/10 version.
Deleted Folders
Searched/Deleted registry entries ("squeeze", "logitech", "slim").  Note: legacy_* entries were not deleted.

Installed 11/11 version (yeah, no worries about month,date order today!)
Ran ServiceEnabler.exe

It started the Wizard.
It did NOT prompt me for a proxy this time.
It prompted me for my SqueezeNetwork ID/password.  Hitting the Add button after entering gave me a confirmation message.

The SqueezeNetwork tab of the Settings page: The SqueezeNetwork Integration option still shows as DISABLED initially.  The user ID and password (masked) show up properly.

Prior to uninstalling this was set to ENABLED so I don't know where it could have gotten a disabled setting from unless it was the installer.

This is what is in the perfs file after install, starting, and wizard run, but during the scan (no settings were saved manually): "sn_sync: ~
splitList:"  This was a tilda-squarebox before "splitlist" in notepad in the file.

Seems like the install/wizard is not setting the sync to be enabled by default.  If it is supposed to default to enabled then that needs to change - if it is supposed to default to disabled then the "help" text should change.  

Either way it would be clearer to change the label of the option...

can we please stop covering the symantics of labelling for now.

I asked if you could remove the ONE line from the prefs file for sn_sync, so that the wizard isn't involved.

Try these steps, and please try to avoid second-guessing what "should" happen, or what you think should be how it works.
Simple, direct responses, please.

Have you located the proper prefs file? (being a windows user, you may have a number of defuct one lying around)
What is the value of sn_sync currently?
Delete it.
Restart slimserver.
What is the value in the prefs file now (do NOT go into settings or anything, jsut let SC restart)
go to the settings page for SqueeNetwork
What does the setting say there now? (screenshot or decription)

Well, since the file is a unix layout file (I'm figuring, sorry to have to guess) it isn't in a format I, being a poor windows user, can edit.  Square boxes all over the place.

Since ALL of the files related to SqueezeCenter, etc. were deleted prior to installing (read notes on setup of test case) there are no old ones laying around.  The ENTIRE FILE was deleted along with all folders and registry entries.  SC was then installed.  The value of the sn_sync was NOTHING as reported - look for the string between the double-quote marks in this thread - that is exactly what is installed.

This is NOT SPECULATION:  if it is supposed to be enabled then IT IS BROKEN.  The install has it disabled (according to the settings screen).  The help says it should be enabled.  I don't care which way it is but it is a bug if they don't match.  The file, post install, has no value in it (again, see the quoted string mentioned earlier) and the screen displays as disabled.

Did manage to move the file over to a linux box and hacked out the sn_sync line.  It then creates a sn_sync with a value of 1.  However, THIS IS COMPLETELY NOT IMPORTANT TO THIS ERROR CASE.  The case is that a stock install does NOT have the sn_sync ENABLED.  NOTHING ELSE IS RELEVANT TO THIS ERROR REPORT.  All this proves is that if nothing is there then it is enabled but since it is never the case that nothing is there it doesn't matter in the least - the default after a stock install is disabled.  According to the help text this is incorrect - no opinion on my part.

As stated, the whole point is that the _install_ has a problem.  This is not speculation - it is fact.

files can be opened with wordpad, which will handle unix line endings.  

please answer only my question with short answers.  I am trying to help you bug if you can't give me the short answer I'm requesting, I cannot help you. continue yelling and I will not help you.  

If you are not willing to provide information to diagnose the problem, please post to the forums instead and allow those who are to file the reports. Not all confusing behaviours are repeatable on all systems, nor all they all bugs.  Please answer my questions in the manner requested.  If you need help acquiring them, I'll be more than happy to give you any tips where needed. I understand that the problem is frustrating you, and we're all trying to make things work.  I need clear answers because I do not see the problem as you have described.  I must recreate, therefor I need to know precisely where the setting is changing compared to what I'm seeing here.

thank you for your efforts.

After Install: "sn_sync: ~<squarebox>splitList:" is exactly how it reads.  No value that I can see.

Removed the sn_sync reference completely - SC then added a reference for it with a value of 1 and it shows as enabled in the settings screen - as previously noted.
On my system, with as clean a box as I can get, the install creates a perfs file with a missing value.  The tag exists but has no value that I can see.

Please indicate what other information you have requested that I have not provided.  thanks

thanks.  that's all of what I had asked.  I'm trying to track down the origin of the blank entry.  By 'after install' you mean when the setup exe is complete? or after the wizard?

I cannot seem to find where this would come from, at least not in SC code.  

I had checked the perfs file value after the wizard, I believe, the last couple of times.  I don't remember specifically checking it prior to actually getting SC running (and completing the wizard) so that is no help in narrowing it down, sorry.  The initial post wizard scan had not completed, though - not sure that is relevent but just in case.

np.  I'm just stepping through to figure out what's going on.  On a new intall, I'm seeing sn_sync: 1, before the wizard.  This make sense given the server prefs defaults.  No other SN prefs exist.  After the SN setup page in the wizard, the other settings are added and the sync prefs gets corrupted. I was not able to find anything in the code that would be doing this, but there must be something I missed in the wizard somewhere.

It seems that something in the SqueezeNetwork settings handler is overwriting the sn_sync value when the new user/password settings are created in the wizard.  

seems to be possible to mess with the sn_disable_stats pref as well.  i think this may be cause to elevate severity, as this might upset users who've previously chosen to disable the stats. I think the easiest might be to add a param from the wizard javascript request, so that the handler can know this is from the wizard and bypass the call to SUPER::handler which tries to set all prefs given in the sub prefs(). that or perhaps make sure the paramref->{$pref} exists before setting it on non-existent or undefined params.

cc'in andy and michael for thoughts.

What's the easiest way to recreate this bug?

Virgin system, or uninstalled SC and erase all prefs.

Install slimserver
Observe newly created prefs file shows sn_sync: 1
Start the wizard, entering SN email and password, click next
observe prefs file now shows:
sn_disable-stats: ~
sn_email: me@testhis.com
sn_password: password
sn_sync: ~

Doh, the wizard makes an Ajax call to the SN settings page without filling all params.  I'll see about a fix.

Fixed in change 14645.