Weldon is going to make a modest proposal.

The basic strategy: users will be able to bypass the direct connection to SN (for firmware upgrade) AND the account creation requirement by making sure SqueezeCenter is running somewhere on the network prior to going through fab4 setup.

More specifically:

----------

Between Screen 10 (Connected to [Network Name]) and before the "Can we connect to SN?" test, we will check the network for a running version of SqueezeCenter.

- If there are 0 instances of SC running on the network (on a Mac/PC etc), we proceed as normal to the "Can we connect to SC?" test.

- If there is exactly 1 instance of SC running on the network (on a Mac/PC etc), we will connect to SC automatically.  

- If there are 2 or more instances of SC running, we will ask the user which instance of SC he/she wants to connect to.

(another option would be to always ask the user how they want to connect - SC or SN - whenever SC is detected.  But it seems this is the cleanest solution).

----------

Even if connected to SC, we should check to see if a firmware update is available, and if so, go through the standard steps (screens 11-14) to complete this part of the flow.

----------

Post-firmware check/upgrade, if the fab4 is connected to SC, we also bypass the account creation/login section (screens 18-20) (the vast majority of the time, a user with SC will have an SN account, and we can deal with non-SN-account cases as a separate issue, for example if a user tries to connect to Pandora, download something from the app guide, etc).

----------

So, to summarize:

- User has SC running on a PC/Mac on the network
- User gets fab4 connected to network normally (screens 0-10)
- fab4 detects running squeezecenter and connects to it instead of SN
- SC handles check for firmware, and download if needed (on-device flow looks the same as SN version)
- fab4 reboots if needed
- fab4 connects to SC again, bypasses account creation/login (most SC users will have SN accounts, we'll deal with resulting non-account-holder bugs later)
- slideshow option still presented to 1st-time users/factory reset users (design coming soon for slideshow)

I'll update the flowchart accordingly (and quickly) if we decide to move forward with this.  I think this is the best solution:

- existing users with SC installed don't have to re-enter account credentials
- technically, you could get through setup without a working internet connection (though you'd need to get a version of SC from somewhere)
- hardcore users that really want to avoid EVER using SN in any way can do so
- first-time users will never know the difference.

I for one am extremely pleased with that plan. 

and now I give you a three word poem:
Well done, Weldon

Are there strong opinions on whether or not to connect to SC automatically, vs.
prompting users to choose between SC or SN?

I could go either way, but it seems auto-connecting to SC would be the most
graceful solution for typical use.

I don't see why someone with a running SC would want to initially connect to SN or even be given the choice of doing so at setup.

My vote would be: 
detect 1 SC, connect to SC automatically. 
detect >1 SCs, give choice (including SN in that list is fine but not really needed)

Cool, I will update the flowchart then.  The one bummer: this has to get into the factory firmware for it to work, since this happens before the firmware upgrade :-(.  Apologies for the late notice, but I think it's a major fix.

That's not going to happen, it's too big a change to make right now. This will have to work post upgrade. So SN connectivity will be required out of the box.

really??? this has to happen before upgrade?

we're only talking about SN *signup*, right? That's post upgrade...

No, this fix addresses 2 issues:

- SN account creation (post upgrade) 
- connecting to SC as a way to bypass the need for an internet connection out-of-the-box (pre-upgrade connecting to SC bypasses this).

This can be split into 2 bugs if that would help.

If this can't get in for MP (not my decision), then I guess users can still download firmware and put it on an SD card, right?  Not nearly as good a solution but I guess technically there would still be a way to bypass the internet requirement.

I leave it up to others to determine what firmware this can get into.  The solution as proposed is the best one though I think.

Dean?

Actually this proposal won't work well in the new Liberace model. We no longer have the concept of "connecting to a server", and the user will never need to choose between SC and SN.

If SCs are detected then it could be possible that fab4 skips registration and just displays the home screen (after loading the available menu options from all the SCs). The from My Music they will be able to browse music on those servers. the problem comes when all those servers are turned off, then a "register" option will somehow need to be available.

It's also a problem if the different SCs are registered to different SN accounts. As fab4 won't know which account to use. Maybe fab4 should find out all the SN accounts, and if multiple are found show a screen like:

 "Please select which mysqueezebox.com account to use"
 "account1@foo.com"
 "account2@foo.com"
 etc.

If only one SN account is found, it will use that to register with.

Looking back at Mickey's original comments: "2. User doesn't want to create a SN account but wants to use music services regardless. May never use SqueezeCenter."

That really makes no sense. If they want to use music services, they are required to have an account. If they don't use SC, they are required to have an account. I think people in the real-world (at least the ones I've talked to about this) don't have a problem about making an account. What are we trying to solve here?

We're trying to solve the issue that's been brought up with great intensity on the forums, that mandatory requirement of an SN registration to initially setup the device is a bad thing. My two cents: I agree with that sentiment. 

I'd backed off from making a stink about this aspect of setup but it's basically universally despised by our beta community. Our beta community != mainstream users, but in this case I think they have a good point.

I thought we were on the cusp of making this right, but it sounds like that's not the case.

Given the universal feedback from our community testing, I'd say that this might be the thing that we decide to change for MP vs MPQ.

Created attachment 5120 [details]
proposed setup flow including SC bypass

Proposed flow attached.  Only 1 new screen required (total), and that's to accomodate an edge case. Two parts:

pre-firmware upgrade (between screens 10 and 11).  If SC is detected, we connect to that automatically, and use SC to check for firmware updates instead of SN (I'm assuming this is plausible since this works fairly well already for other players)

One new screen is needed (10k), only presented if there are multiple Squeezecenters detected on the network, in which case we need to ask the user which one to connect to.  This is definitely a power-user feature, so I'm not super-worried about help screens or flowery language here.  

Copy: 

Choose Squeezebox Software
--------------------------
[computer name 1]
[computer name 2]
[etc.]

As per Richard's concerns:

"If SCs are detected then it could be possible that fab4 skips registration and
just displays the home screen (after loading the available menu options from
all the SCs)."

Yes.  However, if the user already has an SN account, which will be the majority of the time (especially with 8.0 SC, which will push you really hard to enter SN account credentials upon install), registration won't be needed anyway.  So this is fine.  As for the obvious UI bugs this resents, see below.

"Then from My Music they will be able to browse music on those
servers. the problem comes when all those servers are turned off, then a
"register" option will somehow need to be available."

We'd probably have to accomodate this case anyway, in case a user disconnects the player from SN, etc.  We can re-use the "sign in or create account" flow when fab4 tries to connect to SN without account credentials.

"It's also a problem if the different SCs are registered to different SN
accounts."  

If we prompt the user to choose which SC to connect to, this problem goes away.  And we're getting into super-duper-power user territory here anyway (existing SB owner with at least 2 SCs running, each with different SN accounts!!!)

Also agree Mickey's comment makes no sense.

---------------------

I seriously think this flow works pretty well.  First-time SB owners will have zero clue this exists, because they won't have SC 99.9 percent of the time.  Previous owners with SC running will have the easiest setup of all time.

I was averse to introducing weird cases here, but we'd probably have to (or already have previously) deal with non-SN-connection/account bugs anyway in time for release.  If we deal with those well we're fine IMHO.

Oh, forgot to mention: when "connecting to..." screen is presented, we'd show
"connecting to [computer name]" instead of "connecting to mysqueezebox.com." 
And thats pretty much it I think.

Fire away, I'll check back in an hour or two...

I think there's one more error case, which I think is handled automatically, but we should note it: if the SC that is connected to is running older (pre 7.4) sw, there is a "please upgrade" screen shown.

Otherwise, I think this is good and will resolve a lot of issues our beta users have been complaining about.

I think that this is a good proposal.

It is important that this includes getting the initial firmware update from the local SC so that it can deal with the situation that Fab4 has no Internet access. The forum discussions have pointed out that this is much more likely to be the case (in some important geographies) than has been assumed up until now. Even taking into account the 'Internet Connection Required' statement from the box, one can easily expect users to assume that an Internet connection to their PC, that is not shared with other devices, will be sufficient.

Going even more off-topic for this bug, the forum discussions referred to above appear to indicate that it will probably be necessary to make it easy for users to to the initial firmware upgrade via a USB-stick. It may be that the setup help text should anticipate this, at least by providing a link to online instructions. I realise that we need to avoid focusing on edge cases, but even 2% would constitute a sufficient end-user population that we should strive to reduce the support load or systems returned solely because of this.

As Matt said this is really two bugs:

1. Don't require SN for firmware updates. If this change was made this is the only part that is required pre-MP. BUT SC dynamically downloads the fab4 firmware from the update server, just as fab4 does. So we can only avoid downloading the firmware if the SqueezeOS platform firmwares are included with the SC install (30M + more with future products).

Over the last year we have had SC downloading firmware for the Controller on demand, and I am not aware this had caused any problems. There is not clear evidence that this problem needs fixing. And it does introduce substantial risk to the MP firmware adding this at this stage.

2. Don't require SN registration. This is really annoying me now. Months ago I argued that this was bad, but it was decided that we would always require this. Now it's getting too late to change, the decision is being reversed. GRRRR. It's good it's being changed, but the timing and decision making around this suck.

Anyway this does not need to be in the MP firmware, and it would be a big mistake to change this now. The firmware is about to be modified so that the concept of 'connecting to a server' no longer exits. This is what rings alarm bells for me about Matt's proposed solution, as I would do nothing with input of the new server selection screen. Fab4 will be loading the available options (music library, music services, etc) from ALL servers (including SN if available), and use this to build the home menu. This change in behaviour is require to support the server auto-switching functionality.

So, if one or more SCs are available then a good solution would be to go directly to the home menu (via an Interstitial screen while loading the home menu items). Then when the user first plays music, that SC will auto-register the player on SN (if possible). SN would need to provide a 'register' menu item for players that connect and are not registered. This requires no new (non-Interstitial) screens and is a change after the firmware update.

Additional comments on Matt's proposal:
1. A Interstitial would need to be shown for 10 seconds before "SC detected on network?", the firmware requires time to discover the servers.
2. It would not be possible to display the welcome slideshow, as this is SN content.

Just to be clear, Matt's proposal works for the existing connection model used by the firmware, but it is not compatible with the new connection-less auto-switch model that we will shortly be moving too.

If we do this right, I don't understand why we have on device sign up for people that download SC anyway. As the SC installer will register the SC on SN, and the SC will register the player on SN. On device sign up is only really needed for people that never use SN. But were now back to the discussions from months ago.

And final comment before everyone wakes up. These 'problems' are not new and were raised in the discussions back in January on the subject. At the time (for whatever reason) it was decided that these were not important cases to design for, and SN registration was REQUIRED. So what's changed?

(In reply to comment #18)
 
> Over the last year we have had SC downloading firmware for the Controller on
> demand, and I am not aware this had caused any problems. There is not clear
> evidence that this problem needs fixing. And it does introduce substantial risk
> to the MP firmware adding this at this stage.

Richard, Which point are you addressing with this comment?

answering Richard's comment#20, what has changed is that there is now a firestorm of negative reaction to mandatory SN signup.

http://forums.slimdevices.com/showthread.php?t=62338

I agree the timing is crap. But the beta community in this instance is right, and better late then never.

To be clear, I don't think we should put anything into MP firmware. The backlash isn't going to be about being online during setup, it's going to be in requiring SN signup for all users. That's the part that needs fixing.

This is a post-MP issue. Changing target to reflect this. Opening new bug to address the updating of firmware via SqueezeCenter if a Internet connection is unavailable to Fab4.

No.  We need to discuss tomorrow to make the necessary changes for the final MP build.

Just to be clear I want to discuss this in the context of not having a direct internet connection and wanting to get the unit up and running with an SC that may have access as well.

Opening a new bug for the MP portion of this bug (https://bugs-archive.lyrion.org/show_bug.cgi?id=11873), retargeting this one (the original issue reported) for 7.4

Matt, can you summarize the "SN registration avoidance" route?

Briefly, I think it's like this:

After upgrade...
   if the device doesn't have a music library selection cached and...
     if an SC is detected on the network...
        show the "Choose a music library" screen
        Once connected to the SC....
           if SC has SN credentials....
             SC should register that player's UUID/MAC with SN .
           if SC doesn't have credentials
             prompt the user to register their player

     if no SC is on the network
        prompt the user to register their player

Sound OK?

Tom: Can you please look into implementing the feature as outlined by Dean.

Aren't these steps missing? Added IN CAPS.

After upgrade...
   if the device doesn't have a music library selection cached and...
     if an SC is detected on the network...
        show the "Choose a music library" screen
        Once connected to the SC....
           if SC has SN credentials....
             SC should register that player's UUID/MAC with SN .
           if SC doesn't have credentials
             IF CONNECTED TO INTERNET
                prompt the user to register their player
             ELSE
                PROMPT THE USER TO SKIP REGISTRATION

     if no SC is on the network
        prompt the user to register their player

Reset priority before triage.

Comment on attachment 5120 [details]
proposed setup flow including SC bypass

This flowchart is not accurate, marking obsolete so people don't think it is.

Really wish someone had CC'ed me on this bug, grrr...

So we can do this provided you are all aware of a few things.

1. This will have to be a special method call from SP -> SC, and won't use the existing player sync/auto-reg mechanism that is used for ip3k UUID players.  This call should only be made during the initial setup, and never at a later time when connecting to SC.  I think we also need a call that allows SP to find out if SC has an SN account or not?  (Maybe this can use the existing pref CLI command to check for the sn_email pref.)

2. If you make a mistake during setup and select the wrong server (only an issue in MV most likely) your SP is going to be registered to the wrong SN account and there is no way to fix this without talking to that person and getting them to delete your SP from their account.  (Since we didn't fix bug 12836 completely, there is now no on-device way to unlink your player.)

Questions:

1. Does the special call in #1 allow you to move an SP from one SN account to another, or does it only work for brand new players?

2. Is this supported for software players?  There is no MAC/UUID security for software players which means this would be a security risk, allowing anyone to steal/register software players if they knew the MAC address (if we allowed player stealing from question 1).

Reassigning to Andy.

Can someone please confirm we want to implement this?  Please answer the 
questions I asked above.

Andy, re #1, yes, I believe this should provide support to move from one SN acct to another, but it's not _as_ important as being able to handle this for newly registered devices...

Re #2, I do not believe we need to support this for software players (unless I'm missing something) since we're focusing on device setup concerns.

That said, it would be nice, at some point, to enable removing a device from a SN account _from_ the device which I gather is addressed in bug 12836...

Reassigning to Andy after answering his questions...

This is a current bug. Lets get 7.4 out first, then come back and fix current bugs later. Moving to 8.0.

Going to reassign this bug to Tom, almost all of this bug is on the SP side and 
I'm not the best person to do that.  We also need to sort out which spec is 
correct, i.e., do we support skipping SN registration.  I think all the 
developers think we need to support it so that's probably what we'll do.

Andy, it depends on what you mean by "support skipping SN registration."

What we should do:
Case #1) If an Internet connection is present for the device and no SC is
detected we should prompt for registration. We should not prompt to skip
registration.

This is the (overwhelmingly) common case. This is also the current implementation.

Case #2) If no Internet connection is present for the device but a SC is
detected and that SC has SN credentials and has an Internet connection we
should automagically register the device. Apparently we do this in the current
release version of our firmware and SC (i.e., currently shipping products), but
it's not supported in the new firmware/the new SC.

That is this bug, which is a 7.4 P1 so, in theory, it's on the list to support
for launch.

Case #3) If no Internet connection is present for the device but a SC is
detected and that SC does not have SN credentials and/or does not have an
Internet connection then we can't register the device and the user can go to
the home menu in the unregistered/setup not complete state. They can still
access their SC and play local music. They can also still upgrade their
firmware if they obtain it (from work or a library for example) and drop it in
the appropriate SC directory. At some point in the future, we can work on
improving the experience for this edge case (i.e., modify the home menu items
and/or messaging).

This is an edge case. I believe this is also supported in 7.4 already.

We should _not_ add a menu item that appears to all users in Case #1 that says
something like "Skip registration." As Weldon has pointed out _many_times_ we
have good data from our user testing that this is not perceived as a problem by
new users. And, furthermore, it does create a downstream usability impact which
_is_ perceived as a problem (essentially people are in a different mindset when
setting up a product vs. ongoing use of the product).

Also, just to be clear, it is possible _right_now_ for users in Case #1 and
Case #2 to escape to the home menu manually (by press-and-hold of the back
button). At which point they are essentially at the end state of Case #3 (i.e.,
on the home menu in the unregistered/setup not complete state, able to connect
to their local SC to play content and manually upgrade firmware).

 == Auto-comment from SVN commit #7415 to the jive repo by tom ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7415 ==

Fixed Bug:12063
Fixed Bug:11873
Fixed Bug:11783 
Description:
- not mp so no need to force fw upgrade during setup
- During setup, offer Music Source choices if SN not available for registration.
- Complete setup when SC is selected.

This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

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