Spotify not streaming properly and continually dropping out

[milesrc]

For those of you having trouble with Spotify dropping out on your Sonos system, I have found a solution which might be worth trying. If the problem is continuous and is only remedied by resetting your Sonos device then it's not a fault with Spotify or Sonos' servers. It's a problem with your router's configuration. Below is a copy of the last thread of an e-mail I have sent to tech support after spending many hours trying to figure this problem out.
For more info on what a DMZ zone is, check out http://en.wikipedia.org/wiki/DMZ_(computing)

Hi,

I have solved the problem and thought you might like to know in case you get similar queries. The solution is to set up a fixed LAN IP address for the Sonos device on the router, and then set up the DMZ zone to point at this IP address.

For your customers using TP-Link routers (mine is a TD-W8960N), the following instructions will work:

1. Enter the router setup screen (192.168.1.1)
2. Click Device Info -> Statistics -> DHCP
3. Copy the MAC address of the SonosZP device
4. Click Advanced Setup -> LAN
5. Add a "static IP lease" using the copied MAC address and an IP address of your choice
6. Click Advanced Setup -> NAT -> DMZ Host and enter this IP address into the box. Then press "save/apply".
7. The system will then work perfectly.


Miles

[ratty]

Welcome to the forums.

I'm particularly interested in this as I sometimes suffer from the same problem.

Yours is a pretty scary, and I have to say rather illogical, solution. What made you think that exposing one ZP to the Internet would be the answer? I fail to see the connection. Is it repeatable in either direction: putting the ZP into the DMZ (Spotify works) then removing it without rebooting it (Spotify fails)? And what happens when you want to play Spotify on any other ZP? Do you reassign the DMZ each time?

From my reading of the detailed diagnostics a ZP latches onto a Spotify server out of the current cluster of ten then won't let go even when the connection becomes poor. A ZP reboot causes it to select a new server and in most cases resolves the issue.

[ratty]

A follow-up on this:

Having selected a Spotify server Sonos ZPs apparently maintain a persistent TCP connection to it. I'm starting to wonder whether there could be issues here related to NAT timeout, which might just explain why use of the DMZ appears to be a cure. Your comment was specific to TP-Link routers; have you experimented with other routers?

[milesrc]

Thanks for your response to this. I only have one Sonos S5 and had assumed that any other devices I add to my system would still work through Spotify as they'll connect wirelessly through my first Sonos device. Maybe that is not how it would work, though.

I had an identical problem using a Netgear DGN1000 router but when I first purchased the Sonos device late last year the Sonos worked fine for about 6 months.

I wonder if I've been unlucky with a dodgy router, or whether there's a problem with my Sonos device. The only reason I tried setting up the DMZ zone was in case the router was blocking some sort of communication from the Sonos. Interestingly, until I set up the DMZ zone the only way to make Spotify work was by rebooting my Sonos device or the router - either of which would cure the initial problem.

Miles

[jishi]

When you say "drop out", do you mean occasional dropouts when playing music, or the inability to play music at all?

I suffer from the latter, where certain zone players losees the ability to play spotify at all. Usually, my other zoneplayer then works flawlessy so it is intermittent problems with certain devices.

If I'm playing in a multizone, it's usually possible to just drop the players, find which one works and start playing again, and then rejoining the zone. Very annoying though.

After a few hours, it usually resort it self, however a reboot of the ZP would solve the problem immediately. Seems like the players can end up in some sort of fault state that isn't resolved by itself.

If it's a problem with NAT, where a established connection is "dead" in the other end and a reconnection is needed, it would by default in most routers take 5 hours for the router to drop the connection tracking, maybe thats a hint?

[ratty]

Originally Posted by jishi

When you say "drop out", do you mean occasional dropouts when playing music, or the inability to play music at all?

I've had both.

There have been occasions where correct play starts then stutters as a result of bandwidth issues somewhere along the line. A ZP reboot evidently forces it onto a different server. IMHO the ZP ought to be more diligent about server re-selection under such circumstances.

There have also been times where a ZP simply won't work at all. A reboot usually clears it immediately. I've no idea of the NAT timeout in my ISP-supplied router but the time since Spotify was last used on that ZP would be well over 5 hours. I have an old WRT54G with Tomato loaded so could play around with timeout when I have a moment, but to be honest the two ends (Sonos & Spotify) should handle things more elegantly if NAT were the issue.

[milesrc]

Originally Posted by jishi

When you say "drop out", do you mean occasional dropouts when playing music, or the inability to play music at all?

Spotify would play for a few seconds then stutter for a few seconds, then cut out completely. Sometimes it will work again after a few minutes but not usually. A reboot fixes the problem immediately.

Since setting up the DMZ zone it has worked flawlessly the whole time with not a single dropout.

Miles

[ratty]

@jishi

I can corroborate your observation that in a multizone group one ZP may be able to play Spotify successfully where another cannot. Interestingly if one starts to play on the good zone, links the second, then drops the good zone the other zone goes back to being bad again. In other words the successful connection is not transferred over.

NAT was a red herring and I believe the problem is indeed with specific Spotify servers becoming overloaded. When things are bad music will usually attempt to play before stuttering out.

A ZP wanting to access Spotify for the first time after boot makes a DNS enquiry and is given a set of SRV records. It then connects to one of the servers and apparently holds the connection ad infinitum, even if that server subsequently becomes overwhelmed.

Since the DNS records keep changing Spotify could well be updating them to manage load. This is fine for the standard Spotify client which tends to start and stop regularly (and in extremis can be restarted) but doesn't help for a long-lived client instance such as in the ZP. It seems to me that a simple idle timeout disconnect in the ZP might go much of the way towards improving the situation, along with a forced disconnect/reconnect if and when bandwidth subsequently degrades.

[jishi]

@Ratty

Yes, my observation is that it starts to work when dropping an relinking zone is solely based on the fact that I switch "Coordinator" zone, the zone in charge of the streaming.

However, the question is if all streaming traffic goes through Sonos elastic servers from Amazon, or if the actual streaming is directly from Spotify?

Hopefully Sonos is aware of the problems and are working on a fix. This happens to me on regular basis (one or a few times a week) but relinking the zones is usually sufficient for my needs atm.

[ratty]

Originally Posted by jishi

However, the question is if all streaming traffic goes through Sonos elastic servers from Amazon, or if the actual streaming is directly from Spotify?

Controller enquiries are evidently handled by a special server, but from what I can see the ZP stream is pulled from the same set of addresses as the regular Spotify client uses: 78.31.8.x (<female-name>.lon.spotify.com) in the UK.

Hopefully Sonos is aware of the problems and are working on a fix. This happens to me on regular basis (one or a few times a week) but relinking the zones is usually sufficient for my needs atm.

For my part, Sonos have received a number of detailed diagnostics. As for a resolution, well as we know such developments are rarely pre-announced.