Skip to main content
IanJShaw
Chromatic Producer I
Jul 17, 2025 11:15 AM UTC

Is the Sonos ecology just too diverse now?

So, many months on from that event and my Sonos system is still best described as “quirky and unreliable”.

 

I won’t produce yet another list of things that go wrong, there’s plenty on here already.  But every time I open the app now I routinely expect, and get:

 - players refusing to join an existing group “try again later”

 - the app refusing to control an existing group

 - music taking up to 30s to start playing across a group of players (I fondly remember the days when I heard the beginning of the first track in a playlist)

 - etc.

 

All of these are resolved with patience and the digital equivalent of “jiggle it about and try again”.  And I usually manage to have a working system that plays my music within about 5-10 minutes of frustration and annoyance at the beginning of every session of playing music.  I’ve come to expect it now.

 

But I’m wondering if one of the problems is that I’ve now got over 20 different players, of pretty much every S2 compatible type, which spans several generations of technology.  Am I really trying to get hardware to work together seamlessly that, frankly, just isn’t up to the job?

 

Now, I know there would be a huge backlash if Sonos came clean and said something like:

“Hands up.  If you really want a responsive, controllable, reliable system then don’t mix products between generations.  So, for example, never expect a Era 100 to play nicely with a first generation Sonos One, they just aren’t fully compatible”.

 

But, given that I have got used to there being some “problem” players in my setup and am almost coming to this conclusion myself, might it not be preferable to the current fiction where we’re told everything “should” or “will” work together and constantly being disappointed?

This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

58 replies

Local Superstar
Jul 17, 2025 7:01 PM UTC

Thanks, I'm IP v4 only here, Quantum Fiber doesn't offer IP v6 except through the Rapid-Deployment hack and their v4-v6 gateway is slow and unreliable.

At some point I'll have a reason to setup a v6 tunnel, likely using Hurricane Electrics free level of service.

You will have IPv6 on your LAN, even if you don’t have a IPv6 address provided by your ISP. I’m also IPv4 on WAN. Check your local devices, you will see the IPv6 link local address.

Translate
Mr. T
Jul 17, 2025 9:15 PM UTC

For me, my newer speakers cause more problems than my older ones. I find this strange.

I do think though that if Sonos are going to keep recommending reserving IP addresses they should implement the ability to configure a static IP address for each device. This would make so much more sense IMHO.

 

Sonos has never explicitly recommended reserving IP addresses.  That recommendation comes from users. 


This FAQ thread has been updated to include reservation of IP addresses.

 

Translate
Local Superstar
Jul 18, 2025 7:24 AM UTC

For me, my newer speakers cause more problems than my older ones. I find this strange.

I do think though that if Sonos are going to keep recommending reserving IP addresses they should implement the ability to configure a static IP address for each device. This would make so much more sense IMHO.

 

Sonos has never explicitly recommended reserving IP addresses.  That recommendation comes from users. 


This FAQ thread has been updated to include reservation of IP addresses.

 

Read the 3rd comment from 4 years ago in that thread. I agree reserving IP address may have had some benefits back in the day, and possibly for diagnosing with Sonos diagnostics after restarts of router and/or speakers to identify other issues.. Reserving IP addresses will not fix other underlying network issues, but it may help identify them.

Translate
Mr. T
Jul 18, 2025 9:20 AM UTC

I’ve read the thread. Doesn’t change the fact the FAQ was edited to include the mention of reserving IP addresses.

Translate
Local Superstar
Jul 18, 2025 10:02 AM UTC

I’ve read the thread. Doesn’t change the fact the FAQ was edited to include the mention of reserving IP addresses.

Yes, you are correct, which suggests the FAQ may need a peer review. There is no harm in reserving IP addresses on a DHCP server, but it should not be the default recommendation. I’m wondering where this originally came from, I have questioned it before.

Translate
jgatie
Jul 18, 2025 12:06 PM UTC


This FAQ thread has been updated to include reservation of IP addresses.

 

 

Interesting.  I’d never seen that.  I guess I’m wrong.  But I do know mods have stayted away from that advice in the past, allowing us users to give it instead.

Translate
Stanley_4
Grand Maestro
Jul 18, 2025 12:09 PM UTC

I have no clue where it came from, it was here in the early 200?s when I got here.

While i wouldn't offer it as the first option in every case it does solve a problem that so far has escaped a better solution. Since it does solve that specific problem, is easy to do and does no harm I do offer it often. I feel the ability to remove the addressing issue from the list of possible issues makes that a reasonable position to take. If it is later found to not be a problem it is a couple minutes work to remove the reservations.

Translate
jgatie
Jul 18, 2025 12:30 PM UTC

I personally don’t know why anybody wouldn’t use IP reservations.  It doesn’t hurt anything, and it eliminates a problem that has plagued consumer grade routers for as long as they’ve been out there. 

Translate
Stanley_4
Grand Maestro
Jul 18, 2025 12:40 PM UTC

Not just consumer grade routers, my Ubiquity and Netgate/pfSense routers struggled with Sonos and random IP assignments. 

Translate
Local Superstar
Jul 18, 2025 2:05 PM UTC

Not just consumer grade routers, my Ubiquity and Netgate/pfSense routers struggled with Sonos and random IP assignments. 

 

Just for clarity, and as I previously mentioned, you may think they are random, as they are not sequential, but dnsmasq (that a lot of consumer routers, including UniFi will use) uses a mathematical hash to ensure the device gets the same IP address based on its MAC address, effectively a reservation by default:

https://manpages.debian.org/bookworm/dnsmasq-base/dnsmasq.8.en.html

--dhcp-sequential-ip

Dnsmasq is designed to choose IP addresses for DHCP clients using a hash of the client's MAC address. This normally allows a client's address to remain stable long-term, even if the client sometimes allows its DHCP lease to expire. In this default mode IP addresses are distributed pseudo-randomly over the entire available address range. There are sometimes circumstances (typically server deployment) where it is more convenient to have IP addresses allocated sequentially, starting from the lowest available address, and setting this flag enables this mode. Note that in the sequential mode, clients which allow a lease to expire are much more likely to move IP address; for this reason it should not be generally used.

If you see what appear random assignments they are not.

Edited: Added wikipedia link for further clarity:

wikipedia dnsmasq

Translate