Suddenly unable to play any tracks #972
Comments
|
Where about on this planet are you located? I've received a few similar reports from users in the past few days. |
|
Just in case you are gathering stats/data: |
|
Same here (via Spotty integration in Logitech Media Server) (also Denmark) |
|
@jesperll - you're not JesperDB who's been reporting this similar issue to me, are you? That then would be three Danish users. It's hard to believe this was a coincidence... |
|
I am from Austria @michaelherger, so maybe the problem is in europe. |
|
Also saw similar channel errors from DK.. |
No, that's me and I'm also in Denmark :) I have the same issue here: |
|
FWIW: A similar issue seem to happen if I try using Console log with However, if I start librespot with |
|
Put simply, we can't do anything about channel errors. They sometimes hit the Spotify infrastructure and then go away after some time. The panic is due to trying to reload a track that couldn't be loaded the first time. This is fixed in There is no difference in authentication to the Spotify infrastructure between zeroconf and command line, all that matters is the way it receives the credentials (either from the command line or over the LAN). From there it authenticates against Spotify in the same way. It's more likely that the time you logged in with command line credentials, you connected to an access point that didn't suffer from channel errors. You can check the access point in your (verbose) logs when librespot first connects. I'm closing this as this is not something we can do anything about. |
|
I do agree in general. But we could in theory provide an API to control what access point is used rather than always taking the first (or last, whatever it is, I find the comment there confusing). I am not saying that should then also be exposed to librespot application users (yet another program option) but it could. |
|
Just sharing info, in case it's helpful: |
|
i am seeing same thing here. also in denmark. skips all tracks in playlist - happend on 2 pi's at the same time. All tracks get skipped and from journalctl -f i can see the error. |
|
Would everybody mind sharing
Though there have been reports from Germany and Austria, too, I strongly believe this is either a geographical thing, or some network having issues or blocking things. |
|
Of course! :) ISP: Hiper A/S (Bought by TDC, so they probably run on their network now) {"ap_list":["ap-gew4.spotify.com:4070","ap-gew4.spotify.com:443","ap-gew4.spotify.com:80","ap-guc3.spotify.com:4070","ap-gae2.spotify.com:443","ap-gew1.spotify.com:80"]}I just did the test again and the client still does the skipping. |
|
You will also want to lookup those host names and report their IP. Same names could result in different IPs depending on geography, I’m not sure. |
|
ap-gew4.spotify.com: 34.158.0.131 |
|
From The Netherlands (Ziggo) I get the same IP addresses for those hosts. My {"ap_list":["ap-gew1.spotify.com:4070","ap-gew1.spotify.com:443","ap-gew1.spotify.com:80","ap-gew1.spotify.com:4070","ap-guc3.spotify.com:443","ap-gae2.spotify.com:80"]}
|
|
Interesting, mine chooses the ap-gew4: And then starts skipping with these in the log: |
|
I just tried to force the That works!! Sooo.... Is Spotify having an issue? Or are Spotify changing something? |
|
Ha, you beat me to it! I wanted to test the opposite (using Yes, I believe there's a problem with that one host. |
|
That's annoying... Have you experienced this before? In that case: how long does this normally last? I'd rather not do this trick on my music streamer, but if it's normally a problem that takes a long time to fix, I might need to :) Thanks for your time guys! |
|
I don't think it's a common problem. But it's probably still worth trying to report to Spotify? And should librespot be smarter and not only rely on the first element in the list? |
|
I was thinking the same thing. Maybe there's some indicator that can be used to drop a host and try the other. |
|
Channel errors are not new. If you use GitHub search on this project you will find a number of reports them. How long they'll last, only Spotify could say. Programmatically detecting channel errors is not difficult, you literally see |
|
Nice that there is something to detect it by :) |
|
i know it is not a beautiful solution but i can confirm that i works. as morphar suggested. :) thanks for the tip. But instead of doing in all the pi's /etc/hosts we have implemented the redirect in our dns - 104.199.65.124 ponting to ap-gew4.spotify.com |
|
Still no go. |
|
Totally weird. I just connected to that AP manually and no problems here. But off to bed now... |
Yep, I don't know what to say? |
|
I have 2 other librespot devices both running |
|
I don't know either. I tried both on Linux and macOS, both successful. Can you try v0.5.0 on those other devices, see if that matters or if it sticks to a certain OS? |
I already did. It didn't matter as they are all Linux, my desktop runs Fedora, my server runs Debian and and my Pi Zero v2 runs RaspberryPiOS. It must be some kind of geo location blocking thing? I'm looking for a free proxy that's compatible with librespot, as in is http(s)://Host:Port and not IP:Port. Librespot errors out if you try to use a IP:Port proxy. |
|
I would consider not being able to use a IP:Port style proxy a bug or at least a missing feature if you already have http(s)://Host:Port support. I will look into that and see what I can do. |
|
As a temporary workaround here, can you use an entry in /etc/hosts to do this? |
Tried that already also. No dice. Where 104.199.65.124 is the IP to ap-gew1.spotify.com and 2600:1901:1:5ca:: is the IP to gew1-spclient.spotify.com. |
|
I even tried connecting to my phone via a hotshot so my IP was different. |
|
Sorry, maybe I misunderstood what you were trying to do, but I meant you could add an entry for the free hostname-only proxy you are trying to use in order to avoid the geo-restiction. |
I tried setting up a proxy via GNOME's network settings but none of them actually worked that I could find. I have never really had to mess with proxies and I just googled setting a proxy in /etc/hosts and everything I read says that you can't redirect to specific ports in /etc/hosts so that's not very useful. |
|
I was talking about a workaround for
/etc/hosts Then use proxy http://foo.com:Port with librespot, which it should like, but you'll actually have a connection to some.proxy.you.only.have.an.ip.for. Years ago when I tried random free proxies on the net, they never worked. Alternatively there are some free VPN services these days, that should Just Work. |
The only free VPN's I can find are IPV4 only and *-spclient.spotify.com seems to be IPV6 only. I even tried to power cycle my modem to get a different IP from my ISP which worked in the sense that I got a different IP, before my IP said I was in New York City, New York no I'm apparently now I'm in Hamilton Missouri. I ofc are in neither of those places,lol!!! But that was no good either. |
|
Well as a workaround I just tried to use my Spotify creds and that worked without a hitch. |
|
I feel kinda stupid because I didn't try that sooner 🤦♂️ but it still doesn't solve the problem of zeroconf auth not working. |
|
Still don't have a clue what's going on. Maybe you can sprinkle some traces around the Mercury sending code, to see the difference in request we're making depending on whether you're using zeroconf or command-line authentication? |
Hey! Are you having trouble getting an access token via hm://keymaster... or something else? Why not (as an experiment) try to take it from login5 endpoint? (since it returns noy only the login credentials but also the token, but don't know what scopes it has since no information provided). |
What if I just have a Facebook login? 🥲 |
what is workaround? macOS 11.6 |
I don't think this is related to the subject of this issue. But on Mac, just use Rodio instead of PortAudio. I don't know about this Homebrew recipe but Rodio should be the default backend anyway. Or specify |
|
I've encountered this problem (I think) and don't know if it's better to create a new GH issue. I installed the "0.5.0-dev" version yesterday and listened to a couple hours until it stopped and nothing I tried worked - changing backend, editing The content of I'm starting librespot with |
|
Weird. Have you tried blacklisting |
|
If I point it to If I block but when I try to play anything I get the same error, with a different URL: |
|
FWIW I'm having the same issue, though I'm unable to modify |
and others
I am using LibreSpot with the JACK Audio backend, and it worked perfectly, but since a few days I can't play any tracks. I didn't change any configurations on my side, so I assume there is a problem with spotify like it already occured here: #510
Setup
Custom compiled with
--no-default-featuresand--features jackaudio-backendrunning as a user service on a Raspberry Pi.Used Arguments:
LibreSpot allows connections from any device just fine, but can't play any song, no matter of its length. Mots of the time it just skips every song after a few seconds without any audio played, but sometimes it also crashes completely.
Logs:
The text was updated successfully, but these errors were encountered: