Pretty frequently, my two paired Play 3’s will drop the stereo pairing and just both play one channel (either both left or both right), and I have to re-add the stereo pair. This only happens when playing through my Connect.
This happens at least twice a month, but I’ve never actually been sitting in the room listening when it goes down, so I tried to capture a Diagnostic ticket in the moment.
Diagnostic 1730205163
After capturing the ticket, I separated the pair and tried to re-add. Sonos couldn’t “find” the Left speaker - which is the one plugged into the router.
Then, all of my speakers disappeared. Luckily, this happens frequently enough that I know all I have to do is go, room by room, and unplug all my speakers, recycle my router, and then go room by room and plug them all back in. Easy peasy!
Before anyone can say “interference”, I’ll say it again: the Connect and the router are in the same room, less than 12 feet between them, direct line of sight. The router is a TP-Link Archer A9 - which should have enough power to get that first down.
Page 1 / 1
Duplicate IP address is another possibility.
I’d second the IP problem as a likely suspect.
Go to the router’s DHCP page, assign each Sonos device a static/reserved IP address, you can give them names there too.
Power down all Sonos. Reboot the router.
Power your Sonos up, wired to Ethernet first then the rest.
They don’t appear to have conflicting addresses, but they are on DHCP. Never thought about the need to assign. Will try.
I presumed that once the speaker and the router shook hands, it held that same IP until one of them restarted. Are you suggesting that they drop, re-shake, and somehow the left and right both get the same IP?
What’s weird about that is, I would presume that it’s something happening between the Connect and the rest of the system - it only broadcasts one channel. (You know, I’ve never gone to a room with a Play 1 - which aren’t paired - to see if they’re only getting one of the channels. I always just presumed they were. Need more data! Usually I just “feel” that the stereo isn’t stereo, then I pull out a test record or CD* and confirm.)
Like I said, this is an every-few-weeks problem, so even if I reassign IPs tonight it may be a while before I know.
* “Eminence Front” by the Who has vocals in one channel and instruments in the other; “Welcome to the Machine” by Pink Floyd has that awesome bass echo that slaps back and forth between each channel, and of course there’s the old standby “Shure Audio Obstacle Course”...
DHCP (Dynamic Host Configuration Protocol) is dynamic, it is a bit complicated but the IPs are temporary and need renewed at an interval usually set by the router. Most clients will try to renew early and keep the same IP.
Deciding if the IP assignment has fixed or improved things is as you suggest a try it then wait and see operation. Still worth it as it only takes a few minutes and only has to be done once unless you change routers and can’t import the old DHCP assignments.
I have done a lot of log reading on a higher-end business router and there is nothing obvious to see going wrong. I never saw a duplicate address being issued by the router or an odd one requested by the Sonos. That doesn’t rule out a glitch in the Sonos DHCP client or networking stack, which is what I suspect. I did not make the effort to capture and analyze the packets being exchanged though, that might provide an answer.
Logs on the Sonos side are not visible to customers, if they exist, so it is hard to say just what is going on/wrong behind the Sonos security blocking. Most frustrating and that makes the problem almost impossible to troubleshoot without packet capture and analysis. Maybe even then.
After much resistance to making changes “because” and facing an unhappy spouse who was missing her program, I caved in. I took the advice here to do the static/reserved assignments without understanding why they helped. Since done there have been no problems at power-cycle, reboot or update times and random glitches like yours are a very rare thing.
I’d love to see someone do the packet analysis but it is a lot of effort and to be honest I’m too lazy to make that effort since my Sonos is now working well and stable.
I presumed that once the speaker and the router shook hands, it held that same IP until one of them restarted. Are you suggesting that they drop, re-shake, and somehow the left and right both get the same IP?
Maybe, but don’t count on it. A rogue device can simply start using x.x.x.x. If one of your regular devices is currently using this address, there will be trouble.
What if a particular device has been offline for a while and the router decides that its address is now available, but that offline device then returns online and starts using its old address? You can minimize the risk (notice that I said “minimize”, not “eliminate”) of duplicate IP addresses by “reserving” or “fixing” IP addresses that the router hands out to specific devices.
During firmware updates each SONOS unit will shut down and reboot. This implies a return to the DHCP server to request an address. This sometimes results in duplicates. Reservations minimizes this risk. Community regulars have done this years ago and we don’t have any issues caused by the reboot.
Depending on your router and DHCP Server setup the reservations may be more or less effective at preventing rouge clients from causing issues.
If your router assigns DHCP addresses from a pool of addresses and you assign the static/reserved ones from outside the pool (which most allow) you minimize the risk as the rouge never gets past the request and request denied stage for the already reserved IP. More complicated if you have multiple DHCP servers.
If you can’t segregate the DHCP and reserved addresses the chance of glitches is higher.
Technically Sonos gear should (rules say “may” a lot) request the last assigned address be renewed (see DHCP discovery at the link above) and the server honor that request (see DHCP offer) followed by the client accepting (see DHCP request) the offered address. Followed by the final configuration (see DHCP acknowledgement) and the client preparing to use the IP address.
Yes the names are confusing, the network gurus who worked this out needed more sleep and less sugar and caffeine.
Well I hope it holds so I can re-direct my attention at the bats@#t Music Library issues!
