I know it doesn't explain why (some) others have gotten their connection to work and some not. But I've had these issues on and off in the past as well. And now I decided to do some troubleshooting of it, and I think I may have found an issue which probably affects more people that just myself. (And I should perhaps mention that I work as a networking professional and have specialized in WiFi specifically the past 16 or so years (and with that comes a lot of LAN and IP network troubleshooting which is more generic.) The problem I've found is that when the Spotify app (I'm running iOS 13.3.1 on an iPhone 😎 does a search for the speaker(s) it sends a multicast DNS request on the local LAN to address 220.127.116.11 on UDP port 5353 (multicast DNS, mDNS) asking for _spotify-connect._tcp.local However, it does so with an IP TTL of only 1. And though the thought behind doing so (which most likely is to limit it to only the local subnet), is good, it overlooks the real meaning of the IP TTL and what the RFC for Internet Protocol says. The problem arrises in certain networking devices which are having different smart mechanisms to deal with mDNS (aka Bonjour). In my case I have access points from Aerohive Networks, which are enterprise class access points with something they call a “Bonjour Gateway” which is meant do help intelligently re-advertise certain select services across VLANs, based on configurable policy. However, even if not doing any re-advertising they still inspect the IP header (even in bridge mode) to inspect and decide if there is a Bonjour Gateway policy that requires them to do something. This inspection does, in accordance with RFC 791 (Internet Protocol, IP) require them to decrease the TTL before forwarding since they “process the IP header”. (It says about the Time-to-live field: “This field is modified in internet header processing.” and “If the field contains the value zero, then the datagram must be destroyed” (which is what happens before forwarding the packet). The limitation to advertise only on the local subnet is dealt with through the destination IP address, which falls in the 18.104.22.168/24 subnet, which according to RFC 5771 disallows the traffic to be forwarded off-link (the local link network). Further more, it’s worth noting that mDNS queries issued by Apple apps have an IP TTL of 255 (AirPrint, Airplay etc) and searches for Google Chromecast (not sure what piece of software triggers it in my case, but I see it in my wireless packet capture from my iPhone) has an IP TTL of 2. The ONLY queries observed with an IP TTL of 1 are those for Spotify Connect. I have also generated my own traffic to test my theory, and whenever I generate traffic to 22.214.171.124 with UDP port 5353 and IP TTL of 1 it does not get repeated out in the BSSID by the AP, but if I change the destination IP or the UDP port it does (which indicates that it’s the Bonjour Gateway functionality specifically). Also, if I change the IP TTL to 2 with the same test method, it get repeated (even if the payload is rubbish). I think that Aerohive are not the only ones that do mDNS inspection, and therefore I suspect that more people are hit by this without even knowing that they have such a feature. So in conclusion: If Spotify developers could just increase the IP TTL for these Spotify Connect discovery datagrams to 2 (or why not just do like Apple and set it to 255? (as explained above, the IP TTL is _not_ the way to limit traffic propagation to link local network only) this would likely eliminate the problem for at least some of the users.
Por una parte Spotify no reproduce la música desde el Bose SoundTouch y por otra parte ya no me salen enseña en la app de Stotify las bocinas Bose que antes si eran opción de reproducir en, que puedo hacer, esto era algo sumamente simple
I can't access Spotify via my Bose soundwave 4 system and speakers. Was fine til a couple of weeks ago. Tried rebooting, reinstalling apps, unplugging devices, unplugging router, logging in and out of account still, get the above page/ message. Help!
I have been using my Bose Soundtouch system to play Spotify for years. I don't do that often but I do. At recent try, when I clicked on a song, the app just go to a blank player and get stuck. I noticed I can't find my Cinemate from the Spotify app in "Device Available" tab as well. I can still play other web base service using my Soundtouch App. I can safely say that it's a Spotify issue. Please look into that for us. Thanks.
If you've already tried some troubleshooting but you're still having troubles, it would be really helpful sharing the details @Xenia requested here so we can get this reported with the right folks.
Keep in mind we'd recommend including as many details on what's exactly happening as possible (for example, the exact steps you take when this happens) - this helps the teams investigating better reproduce this on their end.
We'll be keeping an eye out for your replies, thanks!
Help others find this answer and click "Accept as Solution".
If you appreciate my answer, maybe give me a Like.
"Kindness is the language which the deaf can hear and the blind can see." - Mark Twain
Device details (build/model/OS): iPad Gen 6 iOS 14.0
Speaker model + firmware version: Bose Soundtouch 10 software version 25.0.0; Soundtouch app version 26.0.1
Troubleshooting steps you tried so far. I followed the guidance on that post. I’ve reinstalled Spotify, restarted iPad a few times. Reconnected the speaker.
I recall seeing a Spotify update during the week to the iPad app. This loss of speaker has happened after that, though no idea if that has caused any change or not.
It’s been fine for ages, it’s stopped appearing within the last few days.
Also, I see you have marked the thread as solved based on a post a couple up where someone describes what they tried. Solved does seem a bit extravagant based on one person and a post that perhaps many, myself included, won’t even understand.
Having posted the message above I just did a further check on the Soundtouch app on iPad. Amazon music service - plays fine on Soundtouch 10 speaker. Deezer music service - plays fine on Soundtouch 10 speaker. Spotify music service - doesn’t play at all.
Maybe I need to swap my music service, it’s not a lot of use paying premium for silence.
@xenia anything you can add based on previous posts and info supplied?
As I have all my SoundTouch devices (SoundTouch 130, SA-5 and a SoundTouch Wireless adapter) in my cottage, I'm not able to test with the SoundTouch app since it doesn't present the services until it has contact with at least one compatible speaker.
BUT, after the fix to the bug I reported back in May got fixed (and it seems it's fixed in your version on the iPad as well) I've not had any problems.
As a wireless networking professional I can imagine that many of the problems reported in this thread are down to the network. There's often a lot of focus on the two peers in the playing: the app on the phone/table and the speaker. But the fact of the matter is that the networking infrastructure has a significant role in this as well. And though you would think that a wifi network is a wifi network, they can differ quite a bit as well.
It's not too uncommon by wifi vendors (whether it's access points (bridging devices) or routers/gateways (combined routing/NAT:ing and bridging)) to try to optimize traffic by filtering out traffic that is considered potential network hogs, and this often includes multicast traffic and/or broadcast traffic.
Since I can't look at how the SoundTouch device does discovery for the other services (the Spotify discovery is Spotify specific) I can't give the answer right now. But it could be that it uses broadcast traffic either to the global broadcast or local broadcast address (255.255.255.255 or 192.168.1.255 (if your network is 192.168.1.0/24)), and that the router/AP filters traffic for multicast but not for broadcast. What I do notice is that when using the Deezer app itself, it uses regular AirPlay discovery with mDNS. But Bose's app could use something else. (And theoretically there could be other things that affect the method chosen.)
Ideally one would do wireless packet captures to record the traffic and see what's actually sent and received. But this of course requires more skills than operating the Spotify app.
But until I get around to doing a more comprehensive guide on how to record wireless traffic (not promising one, but I'm tempted to do one based on all the problems people have, and the fact that wireless packet captures are really the best way to troubleshoot things like this) I would look in the wireless router or access point admin interface and look for any kind of broadcast or multicast suppression. You can also check if different radio interfaces(2.4GHz (802.11b/g/n/(and maybe even 802.11ax, since that supports 2.4GHz as well) and 5GHz (802.11a/n/ac/ax) are not segregated/isolated. If you have the same SSID (network name) on both radios there's no real way of controlling which channel your phone and speaker connect to. Of course, the segregation scenario is not likely to apply if other music services do work from the app. (But could be applicable for those struggling to get connection at all.)
Have the same issue here with Bose Wireless Adapters, they drop from Spotify and the Bose App. Once I connect on my LAN cabled PC, they're fine again. But I cant play anything from the Bose App, or Spotify until I reconnect when on the LAN. Very annoying!