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 |
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 |
|
I ran into this on a Raspberry Pi running raspotify. I've been able to use it to play music from Spotify without problems, but all of the sudden I started getting this error when trying to play tracks - and tracks just skipped ahead immediately all the time: The output of If I block Yay! |
|
Had the same problem, can verify that @bjorgvino solution worked. Thanks! EDIT: Stopped working sep 4th |
|
@bjorgvino 's solution worked for me! Many thanks! |
|
@bjorgvino 's solution worked for me also! Thanks a lot.. The fix stoppped working today 04. September. ap.spotify.com doesn't seem to be reachable anymore |
|
Are you all using zeroconf to authenticate ? |
|
I can answer my own question: no, it's not directly due to authentication method. Please correct me if I am wrong, but it's presumably because you're all using v0.4.x. This problem doesn't exist for me in the dev branch, but does in the master branch. |
|
Yeah I'm using the latest release, 0.4.2. No authentication. It's just that the first access point doesn't seem to work for me (and others it seems), perhaps because of the port, or something completely different, and the fallback logic doesn't seem to kick in... i.e. it doesn't try the other access points. Btw what I posted was not in any way "my solution", I just tried stuff already suggested in this thread and reported back how it went.. |
|
It would only try the other access points it connecting fails. In the cases here, connection and authentication are seemingly work fine, it's the subsequent requesting of audio data that fails when using certain access points. I appreciate not your solution, I was just trying to work out if further investigation was required. But given this all works in the latest code (that obtains audio data a different way), the answer is no. |
|
Understood. Perhaps a new release is in order then? |
|
Blocking |
|
It worked for me until this morning. I'm getting the same error with the ap.spotify.com fallback |
|
Then you'll have to switch to the real fix. which is to compile using the dev branch. |
|
#972 (comment) workaround does not work for me: restart |
I did this two days ago because of the zeroconf thing but as of this morning it stopped working again. Overriding the DNS entry also didn't work this time. But blocking apresolve.spotify.com did the trick! |
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: