-
Notifications
You must be signed in to change notification settings - Fork 639
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. |
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: