mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1151] Librespot playback stops - Connection reset by peer (os error 104) #533
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#533
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dwedia on GitHub (Apr 12, 2023).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1151
Describe the bug
A clear and concise description of what the bug is.
Playback stops randomly. Sometimes after a few seconds, sometimes after a few hours
Librespot seems to crash and I have to reconnect from spotify. Sometimes I can reconnect at once, at other times a complete OS reboot is necessary
Gives these two errors in the log:
ERROR librespot_core::session] Connection reset by peer (os error 104)
WARN librespot] Spirc shut down unexpectedly
To reproduce
Steps to reproduce the behavior:
librespotwith '...' running Librespot through Raspotify, had the same issue (though much worse), when I used Volumio. both use Librespot for the actually spotify connection.Log
A full log so we may trace your problem (launch
librespotwith--verbose). Format the log as code.´
Apr 12 19:58:06 barry librespot[1552]: [2023-04-12T17:58:06Z ERROR librespot_core::session] Connection reset by peer (os error 104)
Apr 12 19:58:06 barry librespot[1552]: [2023-04-12T17:58:06Z ERROR librespot_connect::spirc] subscription terminated
Apr 12 19:58:06 barry librespot[1552]: [2023-04-12T17:58:06Z WARN librespot] Spirc shut down unexpectedly
Apr 12 19:58:06 barry librespot[1552]: [2023-04-12T17:58:06Z WARN librespot_core::apresolve] Ignoring blacklisted access point ap-gew4.spotify.com:4070
Apr 12 19:58:06 barry librespot[1552]: [2023-04-12T17:58:06Z WARN librespot_core::apresolve] Ignoring blacklisted access point ap-gew4.spotify.com:443
Apr 12 19:58:06 barry librespot[1552]: [2023-04-12T17:58:06Z WARN librespot_core::apresolve] Ignoring blacklisted access point ap-gew4.spotify.com:80
Apr 12 19:58:06 barry librespot[1552]: [2023-04-12T17:58:06Z WARN librespot_core::apresolve] Ignoring blacklisted access point ap-gue1.spotify.com:4070
´
Host (what you are running
librespoton):Additional context
Add any other context about the problem here. If your issue is related to sound playback, at a minimum specify the type and make of your output device.
@JasonLG1979 commented on GitHub (Apr 13, 2023):
Connection reset by peer (os error 104)means that Spotify has dropped the connection for any number of potential reasons. In a perfect world librespot would try to seamlessly reconnect without the user noticing if that's possible. Currently I think it may just restart Spirc which isn't seamless. In Raspotify if librespot crashes or exits the service restarts.In short on librespot's side there's nothing that can be done to prevent a 104, but it could be handled a little better maybe?
@dwedia commented on GitHub (Apr 18, 2023):
Thank you for the reply. Not the answer I was hoping for, but if the issue is on Spotify's end, there doesnt seem like there would be much to do about it =\
@tofublock commented on GitHub (May 11, 2023):
I experience this issue, but with an added wrinkle: My RPi3+HifiberryDAC+ running OSMC and raspotify had been working perfectly until I decided to upgrade raspotify a few months ago (if I'm not mistaken I upgraded from 0.31.3 to 0.31.6, since I had to redo my raspotify configuration and set up an asound.conf.)
Since then, I see frequent crashes and service reboots as described in the issue here, but haven't changed anything else.
Is there any way this could also be related to asound configuration or anything other than "bad network"?
@JasonLG1979 commented on GitHub (May 11, 2023):
If you're having a Raspotify issue this is the wrong place. File a bug report at the Raspotify repo and if it is a librespot issue we can file a bug here.
@tofublock commented on GitHub (May 11, 2023):
Sorry, all 104-related topics in the raspotify repo get referred back to librespot, so I thought I'd jump on this issue report directly. Will file it over there.
@HinzundKunz commented on GitHub (May 30, 2023):
I experience the same issue with Spot under Linux. I then have to end Spot manually via the task manager and restart.
Spot doesn't even see the problem and goes on playing stuff, but no sound is heard, and the pulseaudio applet says that no app plays any media.
Anyway, this is not a raspberry-only issue.
@roderickvd commented on GitHub (Jun 1, 2023):
Peers shutting librespot down is hardly a librespot problem. We could discuss how librespot handles such disconnections, which indeed is a problem, and is logged in separate issues.
@jkp commented on GitHub (Apr 10, 2024):
Seeing this very same issue and as others have reported, the lowest layer where there is control of this seems to be in
librespot. I understand that it feels like the client is doing the Right Thing™ but I'm pretty sure this isn't how things are supposed to work :) @roderickvd you mentioned other tickets which propose solutions...would you mind adding a link so folks can contribute to that line of enquiry?(also speaking here as an ex-Spotify developer I may be able to poke some old friends at the mothership to help debug the issue and ask for advice on what the client should really be doing?)
@roderickvd commented on GitHub (Apr 10, 2024):
See #609.
Help from the mothership would be awesome! If they'd be willing to help, then I'd like them to focus on other stuff first. Because reconnection handling is just a problem with
librespot, that wasn't architected to that and is hard to fix now. It's not a problem on the server side or the understanding of the API.Do let us know if there are Spotify devs willing to help us with a thing or two. For example with the reporting of tracks that were played and the obfuscated keys in the new HTTP API are two parts that are really not understood by us yet. And you know this project has always tried to do the right thing to combat piracy -- we're here for the music.
@jkp commented on GitHub (Apr 11, 2024):
Nice! I'll have to reach out to a few folks and see if I can drum up any interest (there's one particular person I know who was pretty much the architect behind a full rewrite of the player stack who recently finished up at Spotify - assuming PTSD isn't too strong he might be willing to help out :))
The player/playback stack (including Connect and the Web APIs) was a thing I worked on directly for about five years (I moved on to something new in 2017) so I do have a fair bit of familiarity myself...but likely the details are hazy now. But if there are specifics I might be able to take a look (if I can find some time).
@kingosticks commented on GitHub (Apr 11, 2024):
If possible, I'd specifically like to know about shuffle/repeat modes which I think at least of which isn't working properly, and echo @roderickvd's request for reporting (we're keen for the correct artists to get paid), and also clarify which keymaster client IDs we should be using (we seemed to have a bunch), and if playback using just an access_token is possible (I would really like to get #1098 working).
Sorry, that snowballed. Very keen for any details you have.
@jkp commented on GitHub (Apr 12, 2024):
When it comes to reporting of tracks: I don’t think I’m breaking any NDAs to say that (in my day….) anything past 30 seconds has to be counted and the way to register something as played is with log messages (so you’ll need to reverse engineer the logs of a genuine client to figure out the format).
The caveat here is that I have read there have been some tweaks to counteract stream fraud however I’d imagine that any correction happens downstream.
One thing I think plays in favour of building third-party clients is that even very old Spotify devices still work - having worked on the platform team building SDKs I can say that they are extremely generous about backward compatibility which I can tell you can prove extremely challenging at times!
Sent from Proton Mail for iOS
On Wed, Apr 10, 2024 at 20:41, Roderick van Domburg @.***(mailto:On Wed, Apr 10, 2024 at 20:41, Roderick van Domburg < wrote:
@JCBird1012 commented on GitHub (Jun 24, 2024):
So, I encountered this issue myself using the fork
vollibrespotinHiFiBerryOS(see https://github.com/hifiberry/hifiberry-os/issues/519 and https://github.com/ashthespy/Vollibrespot/issues/17) - and I was curious to see if this was still happening on0.5.0-dev- I'm still seeing disconnects.librespotestablishes a new connection, but the Spotify Connect session does not get resumed, and playback (sometimes) stops within a few seconds of the disconnect, but always after the current song is finished.Here's some log output (for brevity, I haven't attached logs running with
--verbose, but that output isn't much more helpful) -Something that's interesting to me - the session gets terminated consistently after a few minutes - even with no activity (i.e. no audio playing + no active Spotify Connect session). Not sure much can be done if Spotify's terminating the connection themselves.
I initially suspected this might be related to the work done in #1129, but that's probably a red herring since this still happens in
v0.4.2before that was merged.@roderickvd commented on GitHub (Jun 24, 2024):
Thanks for the debugging. It’s a known architecture flaw, and unfortunately a hard one at that.
Whether a song is playing or not does not matter, because a Spirc session is always connected and notices the hang up.
@JCBird1012 commented on GitHub (Jun 24, 2024):
I tested
librespot-javafor the heck of it to see if it's affected by this same issue - it looks like it is (on the surface), but it appears it gets handled much more gracefully. The Spotify Connect session on the controlling device never gets interrupted (+ it can continue controlling after the disconnection happens in the logs), and audio never stops playing. In the half-hour or so that I've played with it, I haven't seen it have the same behavior I see inlibrespot(except in a few rare circumstances such as the controlling device changing networks).I suspect they're re-using the existing session and just re-connecting (There's a TODO to do something similar in
session.rs)github.com/librespot-org/librespot@cdff6da1f8/core/src/session.rs (L264)Here's what their logs look like on initial connect -
and on re-connect -
@hamishfagg commented on GitHub (Aug 8, 2024):
FWIW I seem to have found a workaround which is to connect to spotify through a US VPN.
I'm not sure why connections from US IPs are treated differently, but it sure seems like they are.
@JCBird1012 commented on GitHub (Aug 8, 2024):
Huh - that’s interesting. Good find!
I’ve got to get around to re-testing again to see if there’s change in behavior (since it’s been a while) + especially considering I’ve been in the US (and presumably connecting to US servers) this entire time.
This is a strange and elusive issue, it seems.
@jkp commented on GitHub (Aug 8, 2024):
What is the algorithm used to choose an access point?
Sent from Proton Mail for iOS
On Thu, Aug 8, 2024 at 03:22, Jonathan Caicedo @.***(mailto:On Thu, Aug 8, 2024 at 03:22, Jonathan Caicedo < wrote:
@roderickvd commented on GitHub (Aug 8, 2024):
Spotify provides a couple based on geo DNS, in random order. We pick the first one that we can connect to.
@jkp commented on GitHub (Aug 8, 2024):
Ok. It’s a hell of a long time since I had any exposure to this side of things at all but reading the previous comment it strikes me that the obvious thing to look for is whether the library connects to an AP in the wrong region. Years and years ago AP addresses were stored as a DHT in DNS - is it still the same way? (I imagine it must be supported to enable to older devices to run)
Sent from Proton Mail for iOS
On Thu, Aug 8, 2024 at 08:29, Roderick van Domburg @.***(mailto:On Thu, Aug 8, 2024 at 08:29, Roderick van Domburg < wrote:
@roderickvd commented on GitHub (Aug 8, 2024):
DHT? I don’t know about that.
It just queries
apresolve.spotify.comand relies on Spotify’s infrastructure to provide some hostnames, which it should based on geographic location. The library does not contain any intelligence beyond that.I believe that even two equal host names will resolve to different IPs when resolved in different parts of the world.
See: https://github.com/librespot-org/librespot/blob/dev/core/src/apresolve.rs
@roqueeee commented on GitHub (Sep 4, 2024):
I'm getting this error after switching to
librespot 0.5.0-dev 2ea7436yesterday because0.4.2stopped working. Never had any issues with0.4.2for almost two years.This is an excerpt from my logs. It appears that
librespotreconnects to the AP succesfully afterConnection reset by peer (os error 104)but never resumes playback and the Spotify Connect connection to my PC or phone is also lost:I can manually reconnect and resume playback after this error without having to restart the service. So the AP reconnection at least seems to be successful.
@RSKriegs commented on GitHub (Sep 4, 2024):
I also began to receive these after switching to Librespot dev from Raspotify, basing on older comments it seems to be expected. Raspotify manages to handle it by design, but it uses other fork and I am not sure if settings tweaks on compiled Librespot could fix it with current version. Would be happy to hear any other solutions.
@noahhaon commented on GitHub (Sep 19, 2024):
Seeing this very frequently now on 0.5.0 during playback using Spotify Connect. Would be great if librespot had the option for resuming the session and playback like raspotify does, as this behavior makes automated usage of librespot quite flaky.
The AP I get typically is
ap-gew4.spotify.com:4070if that is of any benefit.@Eirikr70 commented on GitHub (Sep 29, 2024):
Same problem here. Disconnections happen several times an hour, with
ap-gew1.spotify.com:443@star-glider commented on GitHub (Oct 2, 2024):
I'm now seeing this problem as well, almost certainly related to Raspotify's switch to this librespot source. It's pretty inconsistent, and I haven't been able to figure out any pattern to the disconnections. I'm running it on two devices: a RPi4 that's connected via Ethernet and a Zero 2W that's wireless; they behave similarly.
@kingosticks commented on GitHub (Oct 2, 2024):
@roderickvd shall we close this issue and concentrate everyone at https://github.com/librespot-org/librespot/issues/1340
Edit. Oh, wow, it already is closed and yet people still post here over the more updated one. Let's lock it??