-
Notifications
You must be signed in to change notification settings - Fork 655
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Playlist playback stopped after a few hours with a broken pipe (os error 32) error / non recoverable websocket/TLS error (using Dealer) #1419
Comments
Is it 100% reproducible for you? |
If I understand the problem correct, the problem isn't directly the pipe error and more the random stopping of the playback? Could you try #1420 and report back?. |
It's only happened once so far over the past 2 days. Will post here if I get another repro.
Will do. |
Looks like the disconnect happened again after a few hours of playback running #1420. It seems to be keeping track of the session id now but fails to resume playback when reconnecting with a client and hitting play.
|
Hmm, if it fails to resume playback then there might be a different underlying problem that seems to be dealer independent. Error wise it seems points to network issues. Do you perhaps have a very specific network setup? |
Nope I'm running fairly standard. The Pi Zero 2W is connected to my ISP's WiFi router. This might indeed be something which is independent from the dealer change ... I was already getting some disconnects previously but I do not have any "WARN librespot_core::dealer] Websocket connection failed: IO error: peer closed connection without sending TLS close_notify" before the switch - which I guess might just be due to new logging. In case it's helpful, here's another occurrence from this afternoon. This time the broken pipe error message isn't output on the first reconnect but does appear on the second. Playback did resume correctly when I reconnected a client whereas in the two previously shared examples playback wouldn't restart.
|
Oh that is an "expected" warning... That warning is printed when we close the dealer... So it did what we told it to do, but for some reason it communicates to us that its connection failed. I tried to fix it at the beginning but never found a solution or the actual cause. The error later for the What is more concerning from my perspective are these error messages:
Anyhow, I see the problem with these error because they easily distract from the actual problem.
So it doesn't automatically continue playing? That's a bummer. |
Correct. It stops playing which was already happening previously mostly with os error 107 errors. Since updating to dealer those have most disappeared except once when trying to recover from one of the symptoms I was describing earlier it seems. I don't know if this is really correlated. Looking at the past month or so of logs matching "os error" maybe it's completely unrelated. Feel free to close if this is not actionable ... or suggest things I could be doing to diagnose better.
Update to 72b6ad9 here
|
Interesting, will keep it open for now as these errors are printed as actual errors in the log, and so long as they appear as errors we should probably investigate them. If they appear to be unavoidable then they should be downgraded to a warning I would say. But I'm also open to other approaches. |
Just experienced what appears to be the same issue. Everything has been working fine for me for weeks, but my Internet connection just dropped out and when it came back I started getting a similar problem albeit with no messages about the Websocket failing. However when I press Ctrl+C to terminate librespot, that's when I start seeing similar messages:
Unfortunately for me, closing and restarting librespot didn't change anything - same error I also see the 'end of stream' error but I think that's because it isn't decrypting it, so trying to play the encrypted stream results in that error.
I still get this error even if I wipe the cache folder, although it's still able to download the song again into the cache folder without any problems. Weirdly, in the time it took me to write up this message (while leaving librespot closed) the problem fixed itself. I just reloaded it and now it's playing fine. So perhaps when the connection drops out (rather than librespot cleanly exiting) Spotify still has some kind of link to the old client, and this causes it to get confused? Next time it happens to someone else it would be interesting to see if their Internet connection just dropped out, and if closing librespot for a few minutes before restarting it also fixes the problem. It would also be interesting to note whether your Internet connection came back with the same or a different IP address (mine came back with the same IP). |
@Malvineous I frequently run into the same What does fix the issue though is restarting the whole device the librespot player is running on. Will try only closing and restarting (with and without waiting time) the application next time to see if that fixes the issue, too. |
For the record my router also reported being continuously connected due to the type of outage. You'd probably have to run a continuous ping test (perhaps to Spotify's servers) and after you see the problem, stop the ping test and check the final output to see if any packets were dropped. If so, the connection dropped out somewhere between you and Spotify. If you had no lost ping packets then the problem may not be related to a connectivity issue. |
Description
Playlist playback stopped after a few hours with a broken pipe (os error 32) error
Let me know if more diagnostics can help.
Version
72b6ad9 (post #1356 Dealer merge)
How to reproduce
Steps to reproduce the behavior in librespot e.g.
librespot
with librespot -c ~/.cache/librespot --cache-size-limit 64G -n "Pi Zero" -b 320 --device hw:CARD=Set,DEV=0 --device-type avr --backend alsaLog
Host (what you are running
librespot
on):The text was updated successfully, but these errors were encountered: