[Desktop] IPv6 support for the desktop client

[Furry13]

Resubmitting  the same idea as:

https://community.spotify.com/t5/Closed-Ideas/Desktop-Support-IPv6-end-to-end/idi-p/1240314

https://community.spotify.com/t5/Closed-Ideas/Desktop-Desktop-client-IPv6-support/idi-p/1667179

https://community.spotify.com/t5/Closed-Ideas/Other-IPv6-Support/idi-p/4469460

submitted previously by @sdstrowes

It would be highly desirable to make sure that the desktop client can work on Ipv6-only networks as they are becoming operation reality (a number of large entrerprise networks like Cisco and Microsoft have piloted IPv6-only corporate networks).

As it's been mentioned in the previosuly posted incarnations of this idea, the mobile client works just fine and Fastly supports IPv6.

Thanks!

[jhealy1024]

I manage a residential network for a school.  We're piloting IPv6-only connections with NAT64 as the fallback for legacy services.  The Spotifly desktop client doesn't support this configuration (unable to log in, gives a "proxy error" message).  It seems like you have to go out of your way to PREVENT something from working with NAT64 at this point, so that's very frustrating.

All my students who use Spotify are going to be annoyed when we roll this out, but I plan to tell them to write to customer service and let them know exactly whose fault this is!

[exponentialverteilt]

The Spotify app seems to have at least a hardcoded DNS or worse, hardcoded IPs in the source code. It's absolutely not understandable that it takes so long to fix this. Their web app (open.spotify.com) works fine from IPv6-only networks. Just the "native" clients, except iOS, seem to have no IPv6 support.

[tiljes]

@exponentialverteilt

Nope, the desktop client just uses a different endpoint and only queries for A records. If you use the --experimental-network switch you can see it is using another endpoint and that it also does AAAA queries. So neither hardcoded DNS nor hardcoded IPv4. Rather old socket creation: gethostbyname instead of getaddrinfo I suspect.

[exponentialverteilt]

@tiljes

I just tried the --experimental-network switch. In a NAT64 environment, the app works fine. However in IPv6 only, the app starts and playlists can be played. But individual songs cannot be played. Probably some last remaining IPv4-only endpoints. But at least, it's progress.

Edit: I just reread the thread and it seems it's not progress but probably the same situation like 2 years ago.

[desertbaker13]

Still having the same issue where playlists won't play on an IPv6-only network with fully functional NAT64/DNS64. This seems to be a 5 year old issue. Any status??

[tiljes]

@desertbaker13

No, unfortunately nothing has changed 😞

Still the only way is to use the Experimental network switch.

[timstp]

There may be some improvement here.  I just re-tested on Mac OS 12.7.2 with Spotify 1.2.30.1135.g02fef27

- Turned off IPv6 and re-launched the client, cleared the cache.  Everything seems to work as expected.  This environment is NAT64 at the edge, so as long as the client does IPv6 properly, everything works.  This is a big win.

-For experimentation's sake, I changed my DNS to Google's public DNS which I'm assuming does not do DNS64.  Relaunched the client, everything still works.

Finally, there is some progress here!

[tiljes]

@timstp

I don't see any improvement? Spotify still requires IPv4 sockets.

Where did you disable IPv6? On your Mac or on your router? As the problem is when you only have IPv6 at your computer.

[timstp]

I disabled IPv4 on the Mac network control panel.  As far as I know, this version of Mac OS does not have the CLAT enabled.  Just to verify that, I tried pinging an IPv4 host, and I get "no route to host", since there are no IPv4 routes beyond the local host.

What OS are you on?  Is it possible that there is a code difference between what we are testing?

[tiljes]

Windows 10 and Linux. Yes, there could indeed be a code difference!

Are you.sure everything works? I often had the problem that I could play already cached songs, but nothing new.