No music when using Spotty in Denmark

[lektoren]

Since last week, I can't hear music via Michael Herger's plugin "Spotty" for LMS.

It seems to be a local problem for Danish users - pls check this support thread:

[Announce] Spotty 4.0 - integrate local library with your Spotify collection (LMS 8+) - Page 92 (sli...

Spotify works in pc and phone apps, but in Spotty I can now only browse music, see cover art, but there is no music.

Please look into it.

Kind regards ,

Lars

Plan: Premium

Country : DK

Device

Raspberry Pi

Operating System

Max2play running LMS server

[Vasil]

Hi!

On the Community, we can't provide support for third party integrations that use the Spotify API. The best course of action would be for the developers involved to reach out to our devs if they need any assistance with the API.

[mherger]

Plan

Premium

Country

Denmark

Device

librespot

Operating System

many (Linux, macOS, Windows)

My Question or Issue

I fully understand that Spotify doesn't support 3rd party players. But this isn't a 3rd party player problem. As you'll see below it's a Spotify system not working correctly. Maybe it's more obvious with this 3rd party player, but the problem is in the infrastructure.

librespot uses http://apresolve.spotify.com to get a list of endpoints to which to connect. This list is country/region specific. And right now the one returned in Denmark (and some other places) returns a few hosts which are not working correctly:

{

"ap_list": [

"ap-gew4.spotify.com:4070",

"ap-gew4.spotify.com:443",

"ap-gew4.spotify.com:80",

"ap-gae2.spotify.com:4070",

"ap-gew1.spotify.com:443",

"ap-guc3.spotify.com:80"

]

}

ap-gew4.spotify.com seems to be in trouble. If librespot chooses to use that host, then playback will fail. If it's forced to use one of the others (or a user changes his /etc/hosts file to make the host name point at a working system) things are fine.

So obviously this isn't a librespot problem, but one system out of many not working correctly on Spotify's end. Hopefully this is helpful for Spotify's engineers to fix that one system and make some of their paying customers happy again. Thanks!

[kongsted]

Spotify - as both "lektoren" and "mherger" is mentioning there is a problem, and we cannot see that it's the developer there can do anything about it.

When I'm accessing http://apresolve.spotify.com/, I'm getting the same DNS-names as mherger.

When trying to resolve the DNS-name ap-gwe4.spotify.com, I'm getting:

With that IP-address, it's failing.

On one of the communities for the third parties, they're suggesting to edit the "hosts-file", so another IP-address is resolved.

https://github.com/librespot-org/librespot/issues/972

When changing the setting, so the DNS-name "ap-gew4.spotify.com" is pointing to "104.199.65.124", then the player starts working.

Meaning the server we get resolved from the DNS-name (34.158.0.131) seems to behave different that the other server.

At least I'm having a daughter, there will be happy for the workaround, but I would like to have it fixed correctly. 🙂

Here from Denmark (and maybe other places?), we would appreciate, if the case could be investigated, please.

Br,
Anders

[mherger]

Anders - I'm suggesting a different workaround. Instead of fiddling with he hosts file (which could potentially have a negative impact on things other than librespot), you can change a parameter in librespot to force using its fallback setting (which seems to work). Just add "--ap-port=12321" to the librespot startup parameters. This will cause librespot to fail to look up the hosts, and fall back to a default value which seems to be working.

See my response in that thread you linked (https://github.com/librespot-org/librespot/issues/972#issuecomment-1061063974).

[xfui_h-91qau]

Having exactly the same issue in Norway using the Spotify Connect client in an Ultimate Ears Megablast speaker.  Definitely an issue with the server(s) behind 34.158.0.131.

I can obviously not change the behaviour of the client running on that speaker.  But  in addition to the suggested DNS fix, I've found that simply blocking 34.158.0.131 in my firewall makes the client fall back to the next server.  Which works.  So that's another hacky and ugly workaround...

It's been like this for months now.  Initially I assumed that this was a serious problem which would be picked up by system monitoring and fixed by Spotify.  But it doesn't look like they.re monitoring their systems.  Or these forums.

[xfui_h-91qau]

This problem is not related to third party integrations.  It's a problem with the Spotify service.  Which we pay for.  For whatever reason.  Reading your REFUSAL to fix a reported service problem I am having some problems understanding why I do that....

Please escalate this report to someone understanding that difference between service problems and client issues. Thanks.

FWIW, the service fails with any Spotify Connect client. E.g the Ulimate Ears integrate in their Megablast product.  Is that supported, or is it another "third party integration"?  If it is, then you might consider if you're not actually depending on those third party integrations....

Please provide a list of the Sotify Connect clients you support, if any, and I'll provide a bug report for it.

Or maybe you don't support ANY clients?  It certainly looks that way from your reply

[444444444]

Seems to work now without any modifications?