Yet again the wonderfully robust and user friendly software messes up my day.
The Sonos software and update process is a piece of junk, there’s imply no way it should behave as it is, the lack of attention to detail is astonishing.
The hoops we have to jump through to get something working is absurd.
Of course to complain means I’ll get asked lots of questions, I’ll be asked to unplug this and that, connect this or that to something else with a piece of cable and so on and so forth, all the burden is on the customer.
I tried to update because the PS controller software insists that I update, yet it always fails. If I try the same update from my iPhone, again it fails.
The iPhone fails (I think) because the controller is “not S2 compatible” whatever that means. The PC software is not S2 yet that also fails and the error code I get varies each time.
e.g. “Error code 30: BRIDGE” or “Error code 1002: BRIDGE”.
If these error codes mean something then why not pull down the message text and display it in the controller software???
Everything was working but I have a Roam that fully discharged, I recharged it yet it was not visible in either the PC controller or the iPhone controller, as I tried to get more insight it kept suggesting I update so I tried.
Now the system can’t find jack s**t, it cannot see even one of the devices.
I submitted a diagnostic and the code I got back was: 703555998 perhaps that can shed light.
I’m a very experienced software engineer so before people rush in to defend Sonos don’t bother, this is abysmal, with today’s technology the customer experience can be far far better than it is.
Now I have no system, can listen to no music and was planning on a restful Christmas alone this year to do some reading and studying, without Sonos this really messes up what would have been a restful period for me.
The update almost works, I get this far:
but then I get this:
“More information” gives this:
and that’s pretty much that!
Now I’m stuck with this:
See? I cannot choose “Just continue running with current version” why?
This update is something I CHOSE to try (because the Roam was not working) so by definition the existing version did work - at least - with the non-roam devices.
This is a one way trap door, the system works with some version, one tries to install an updated version - that fails - yet it is no longer possible to run with the older version - even though it was working!
Page 3 / 3
@Korporal
Yes it’s often the case that some routers (not all), may see the SonosNet wireless devices, as ‘wired’, as the communication with the router is via the wired ‘root bridge’ Sonos device - you can tell (easily) if the non-portable Sonos devices are correctly running on SonosNet by going to the ‘about box’ in the Sonos app and looking at their Wireless Mode (WM) setting - if running on SonosNet the devices will have WM: 0 next to them in the device list.
In an ‘ideal’ Sonos setup, what most users aim for is the controller mobile device attached to the same access point linked to the wired ‘root bridge’ device. If the mobile controller switches to a different WiFi access point altogether, which has a different SSID (as you have in your own current setup) then the Sonos App will see this as a different Wifi network and look for devices that are then on that network, which might not be any, if you do not have that SSID stored in your network settings in the Sonos App.
I would personally choose to add that network SSID to your list of networks in your Sonos App network settings - in my own case, I prefer to have the same SSID name for all the WiFi access points on the network, but people have varying views about this.
That said, the most important factor is that all Sonos devices and controllers must be on the same network subnet and the communication across all needs to support SSDP multicast/broadcast for the discovery of the devices. This is usually simple in a single central wifi access point network, but it can become more complex in some cases, where different access points form part of the network that use different SSID’s and WiFi channels/channel-widths, as the communication can become interrupted.
Hmm, when I attempt to edit the name of the SSID of the the extender’s 2.4 GHz this warning popup appears:
It will let me change it, but I’m reluctant, like this model may have limitations and so on...
Well I changed the extender SSID name, no worries.
But in the S2 phone app, things are weird now, I went to network to add the HighChaparral network but shows a PLAY3 and asks me to chose it.
I did that and it now asks if I want to add the play3 device to HighChaparral - but I don’t, the PLAY3 devices are working fine on SonosNet, I just wanted the apps current listed channel to be changed.
Anyway, instead I removed the wifi SSID HighChaparral_2.4 from the app so that it only listed SonosNet.
I’m now readding the ROAM and its going better, told me it needs to update the roam and asked for the password for HighChaparral - which is now the SSID for casita and house HighChaparral_2GEXT has gone.
Its updating now…
OK done, at last!
The roam appears in desktop app and phone and is playing music again.
Man oh man oh man, what a labor intensive operation, thanks to everyone in this thread, your posts and encouragement were of huge value!
Just when you thought it was safe…
Sonos explicitly doesn’t support extenders. When the Roam is attached to the extender there’s likely to be a warning message whenever one goes to group any of the players in the system (not just the Roam).
I’d also note that a good number of extenders, including older Netgear units, mangle the MAC address of attached clients, substituting a virtual MAC for the device as seen from the router side. This can result in the client IP address changing as it moves between up- and downstream of the extender (the DHCP server sees a different MAC in the request) and ARP caches can go stale.
The effect could be that a controller loses the players, and players lose the controller, at least temporarily.
It can be hit and miss, it seems. I’ve seen some say that the ‘Roam’ doesn’t like to … er… roam. (pun intended).
It seems better though with some extenders, if they have the exact same SSID/credentials/channels/channel-width as the main router itself, it can work okay with some (not all) devices setup in that way. If it doesn’t, then I would personally choose to go back and rename the extender SSID’s so they are completely different to the main router WiFi and (ideally) ‘filter’ the Sonos products from using their WiFi signal altogether, so that all Sonos devices connect just to the main router only.
It’s an area I would like to see Sonos look at further to perhaps try to resolve these things, so that they do transparently roam between the different access points on the same local subnet.
As it stands you have to reboot the Roam to get it to connect to a different access point.
On the extender issue, Sonos seems remarkably cunning in detecting the presence of one and complaining when players are grouped. (Pushing past the nag, the group may still work okay.) This restriction doesn’t apply to controllers connecting via an extender, nor should it apply when APs have a meshed backhaul.
One passing comment: the OP’s DHCP server is supplying two DNS addresses. One is the gateway’s DNS forwarder as usual, but the other is an ISP’s DNS (CenturyLink). If the ISP is CenturyLink this feels like a waste of time, as the gateway would quite probably be using the same external DNS.
Assuming redundancy is required it would be better to specify something like Cloudflare (1.1.1.1) or Google (8.8.8.8) instead.
One passing comment: the OP’s DHCP server is supplying two DNS addresses. One is the gateway’s DNS forwarder as usual, but the other is an ISP’s DNS (CenturyLink). If the ISP is CenturyLink this feels like a waste of time, as the gateway would quite probably be using the same external DNS.
Assuming redundancy is required it would be better to specify something like Cloudflare (1.1.1.1) or Google (8.8.8.8) instead.
Ratty, what are you referring to? I’d be interested to learn more about your concern.
Everything is running fine now, but I noticed unlike before, I can now group the ROAM with the other PLAY3 units, I was not allowed to do that earlier!
One passing comment: the OP’s DHCP server is supplying two DNS addresses. One is the gateway’s DNS forwarder as usual, but the other is an ISP’s DNS (CenturyLink). If the ISP is CenturyLink this feels like a waste of time, as the gateway would quite probably be using the same external DNS.
Assuming redundancy is required it would be better to specify something like Cloudflare (1.1.1.1) or Google (8.8.8.8) instead.
Ratty, what are you referring to? I’d be interested to learn more about your concern.
The default would have been the gateway 192.168.0.1, so I’d guess someone added in 205.171.2.25 deliberately.
Assuming you’re on CenturyLink (Lumen) this extra DNS address might not be doing much for you, as the gateway could well be dependent on that server already. I was suggesting substituting a third party DNS for redundancy purposes.
It was something I spotted. If you’re never seeing any name resolution glitches then just ignore.
Well a problem has arisen and I want to be patient and see what others suggest before I try.
None of the PLAY3 devices or the ROAM play this morning. When I press the play button on the PLAY3 that’s connected - wired - to the router is flashes white several times, then orange and then freezes white.
Using the app indicates no issues, I can see all devices and it lets me try to play stuff.
If I try to play the main PLAY3 (wired) I see in the app after a few mins waiting “Unable to play <whatever> the server cannot be found” whatever I try to play and so on with the other - wireless - devices.
I guess the wired PLAY3 has lost its settings or something but I do not want to try to address that in case I end up having to re-add all of the other devices again, so want to know what exactly are the steps to take in this situation.
Ignoring the Roam for one moment, I believe you have 3 x Play:3’s all running of SonosNet with one wired direct to your router. What is the mobile device controller connected to?
I would perhaps just check to see if it’s connected to the Routers 2.4Ghz band, rather than an access point and if the App can then see your wired Play:3 (at the very least)… try closing and reopening the App and also (if necessary) power-cycling the wired Play:3.
Ignoring the Roam for one moment, I believe you have 3 x Play:3’s all running of SonosNet with one wired direct to your router. What is the mobile device controller connected to?
I would perhaps just check to see if it’s connected to the Routers 2.4Ghz band, rather than an access point and if the App can then see your wired Play:3 (at the very least)… try closing and reopening the App and also (if necessary) power-cycling the wired Play:3.
Hi, I don’t know what you mean Ken by “What is the mobile device controller connected to”, do you mean the app on the iPhone?
In the app under network it just says “SonosNet Channel”.
The phone itself is connected to the 2.4 GHz channel.
I’ll power cycle the wired PLAY3...
(the problem is present whether I use the phone or desktop app too).
Yes (sorry if my post wasn’t too clear) I meant the WiFi signal (SSID) that your iPhone was connected to - I just wanted to establish if it was connected to your main routers 2.4Ghz band, rather than it being connected to your WiFi extender.
Alright Ken, all sorted, cycling the power did the trick. I was reluctant to try anything without asking simply because I’d dread having to re-setup all of that c**p over again!
Thx
Alright Ken, all sorted, cycling the power did the trick. I was reluctant to try anything without asking simply because I’d dread having to re-setup all of that c**p over again!
Thx
Ah good to hear that has worked and Happy New Year too by the way.
Alright Ken, all sorted, cycling the power did the trick. I was reluctant to try anything without asking simply because I’d dread having to re-setup all of that c**p over again!
Thx
Ah good to hear that has worked and Happy New Year too by the way.