Spotify unstable when starting tracks

Update : nope, the upstairs jump in and out if playback started from floater. I guess we're never going to fix that and will just have to use the better rooms to start the group. It's a shame it's so temperamental... 

Hi @Standforhats 

My guess is that you experienced two dropouts - one 1m before the diagnostic, and one 6m before that? If so, that exactly coincides with multicast flooding reaching the Boost, which your IGMP switch should be filtering - if the Boost is wired to it, that is. I’m assuming it is, and that means I don’t understand why the Boost is still getting them.

The dropouts experienced when Floater is in charge make sense. As it is now relying on a wireless connection between the Velop nodes, it’s no longer necessarily the best choice of Group Coordinator (selected first when creating the group).

Your connection map should help you visualise this. The solid lines are wires, dotted lines are WiFi/SonosNet/mesh-backhaul.

A Spotify stream comes in at the top, and travels over WiFi to the Velop node, then over cable to the Floater. Floater then buffers it and sends it back to the Boost - two cables and one more WiFi jump. Boost sends it to the other speakers in the group, apart from Outbuilding, who gets it over one more WiFi connection and a cable. 

If, however, a unit connecting to the Boost was the GC, then things go smoother. Front Bedroom has the strongest connection to Boost, so is now the best choice. Spotify again comes in from the top, goes to the Boost and wirelessly to Front Bedroom. Front Bedroom buffers it, and then sends it to the Boost, which then sends directly to the other speakers. Outbuilding and Floater depend on the Velop backhaul as before. The key difference here I think is that when it’s a Sonos-to-Sonos connection, there is no third-party bandwidth.

I should say that it does look like at least one of the speakers (Dining Room) will actually prefer connecting to Floater, which it may do when rebooted. This could conceivably take some load off the Boost and make things more stable. Please reboot the Dining Room speaker. Please be aware of the need for the backhaul on the Velop system to be of good quality - I take it that’s what the Velop app reports about the nodes’ connections?

Shown below are the various signal strengths between your Sonos devices:

As you can see, Dining Room would likely connect to Floater rather than to Boost (63 vs 43). Sonos devices will only actively look for a better source of connection when the RSSI (signal strength) gets below 19, which is why the reboot would be needed. The secondary speaker of a pair will always get it’s stream from it’s partner, but it looks like Back Bedroom will connect to Floater too. Please reboot them to spread the load too.

When rebooting the entire system, it will be best to turn on the wired devices first and to wait for solid white lights before continuing.

So, with the speakers getting their connections from the 2 closer ethernet-wired units (Outbuilding isn’t an improvement for any of the speakers), stability should improve. It may make Floater the best choice of GC again - we’ll have to see.

Did you have any success in discovering the source of the multicast packets?

Hi

Thank you for such a comprehensive reply. Sorry I didn’t respond for a bit, some family stuff took me away from home for a few days.

So,

• The Velop backhaul is good insomuch as one can tell from the status lights, which all show blue. (good connection) 
• I tried rebooting the dining room as suggested, and things got a lot worse. Which seems odd. 
• Given the tortuous route the stream has to take from your description, I have disconnected floater and outbuilding from their respective Velop nodes, so it should all be via the boost now? It doesn’t appear to have made any real difference.
• I haven’t found the source of the multicast packets, given I don’t really know anything about them and indeed this thread is the first time I have heard of such a thing. I don’t know what an IGMP Switch is, but rooting around (sigh, no pun intended sorry!) in the settings of the TPLink Archer router which is now controlling everything, I have tried switching on the “snooping” option which seemed to suggest it might help. It doesn’t appear to have done so. 

Today’s diagnostic, taken just after the stream dropped out a couple of times but then continued playing (not the usual issue) 109893824… this is using Fire Room as the starting point as that seems to be the most stable. (Not oddly Front Bedroom which is where the boost is, I wonder if that is because it’s a pair?) 

I do feel like I’m just randomly trying things now. I clearly need to do some research on multicast packets…

Thanks again

John

@Corry P I don't know if this thread is still active but here's today's diagnostic 972940648 🙄

Using Fire Room as the group controller it's been reasonably OK the last couple of days but just now the upstairs pairs started mucking around again.

Also, it's still doing this thing where if you change the queue (like, start a playlist then select shuffle) it will almost certainly skip to the song after next when it finishes the one you started with.

Having spent forever mucking around with wifi interference and things like that and getting nowhere, could we be barking up the wrong tree? Could it be the router settings? I don't know much about the technical side of that but it's the only real bit that I haven't been asked to look at.

Does the diagnostic show multicast issues? I'm lead to believe the snooping thing on the router being enabled should have fixed that..

H

So, removing the boost, wiring (long cable) the Front Bedroom R speaker, figuring it’s pretty much the most central I can get wired directly from the router…

Fault persists. Sigh.

224599629.

Seriously, it has to be something else - like do I need to do something with IP addresses or something? 

H

This seems about as good as I have ever seen it, yet the cutting in and out when starting tracks still happens, indeed it is worse than the last setup, so surely it has to be something else

Hi @Standforhats 

Apologies for the delay - I’ve been on holiday.

Your most recent diagnostic certainly shows a different connection map:

Unfortunately, with the Front Bedroom in charge of a group, it’s actually the Left speaker that gets the stream and distributes it. Are you able to connect the Left speaker to ethernet instead of the right one? If not, I recommend you physically swap the two speakers to see if that helps.

Note the Boost is missing now.

Regarding the adding of Spotify tracks to the end of the playing queue and them not playing, this is an issue we are aware of and it is unrelated to your other playback problems. It will take a software update either on Sonos systems or on Spotify servers to fix.

Reserving IP addresses can certainly be tried, but I wouldn’t expect it to fix this problem. It’s generally only used when speakers are missing from your system. As we’ve tried everything else, I would give it a go.

Finally, the only answer may be to reduce the number of rooms in the group you are playing to until you can find and resolve the source of the multicast packets - these are still showing up on the ethernet-connected devices.

Hi @Corry P  

How very dare you!! ;-)

There have been some further changes while you were away...

I had a suspicion this might be the case, something in the back of my head… (It should be noted that support told me it didn’t matter which speaker was wired) 

My decision to wire the Right was that the Right is basically in the middle of the house and so should provide the best coverage for connecting to the other speakers…

Anyhew, I have now connected both Front Bedroom speakers. (There is a switch involved which also allows the WiFi Printer which is near to the left speaker to be connected to the router via Ethernet and so I could turn off the WiFi broadcast on it and so leave it on without mucking up the Sonos. It was switched off for all the fault finding we did on here but a previous Support conversation had identified it as a source of interference to Front Bedroom Left)

Not required now with the purchase of the 10m ethernet cable! (Also I read that because you can’t address the boost directly as the group controller using a wired speaker is much better as it removes two journeys for the stream - I don’t know if this is true?)

Thank you again for this information - I suspect that not all your support operators got that memo… Really looking forward to having that fixed it’s really frustrating!

Anyways… with the current set up, I almost daren’t say it but all seems to be working well. The skipping channels seems to be resolved. To recap, both Front Bedroom speakers are wired directly (via a switch) and Fire Room is wired via a (gasp) Homeplug. It even seems to behave if I use Outbuilding as group controller in an attempt to make it misbehave… 

I daren’t say it’s all fixed now, since every time before I have thought this it has turned out to be a temporary reprieve… so I would be very grateful if you could cast your eyes over a couple more Diagnostics to just see how it’s looking:

278925707 - Floater as group controller (deliberately not one of the wired rooms)

804479730 - Front Bedroom as group controller.

(I worked out how to see the Matrix myself, can a user get to the connection map without your access?)

Are these still appearing? given the initial issue appears resolved what issue are they causing? Or is this part of the queue nonsense? I don’t really know much about this kind of level of things - what could be causing them? The only option I could find on the TPLink Archer MR600 settings was to turn on IGMP snooping - which I have done but I think I had already done that before the diagnostic you checked before. Oh well

Thanks again, I am very hopeful I will be able to leave you be now!

Cheers

H

Hi @Standforhats 

I am pleased to announce that in those two diagnostics I am seeing far less multicast flooding (though still a little) and only on one wired unit (Front Bedroom R, which is also the designated root bridge (controls SonosNet STP) so it kind of makes sense - don’t ask me to explain as I can’t without help). I think the IGMP Snooping option helped a lot. 

Also - 11 hours since the last dropout!

In terms of how many, or which, speaker(s) should be wired, there’s no right answer - whatever works best for you is the correct way to do it, as far as I am concerned. You are correct in that the Boost cannot possibly be a group controller, so in edge-cases like yours, yes, a wired speaker is better than a Boost. I would say the regular use of large groups is what is making this difference for you. It can be argued that with a Boost wired, a speaker has more CPU resources available for other tasks, but again, what works, works.

You are very welcome, and hopefully you can now enjoy the tunes in peace! Fingers crossed!