mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #1486] Snapserver + Librespot stop working after ~1-2 hours, requiring a restart #672
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#672
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 @roldengarm on GitHub (Apr 12, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1486
Description
I'm runing Snapserver + Librespot. It was working fine until a week or so ago, when I enabled Music Assistant. I've now disabled Music Assistant, but the problem exists.
It works fine for 1-2 hours, but then I can no longer play music from an Android Spotify client. Snapserver shows up, but it disconnects immediately
Version
The latest version from git
Log
Below logs from Snapserver at the time the problem happens.
After a restart, with the same song, the logs are:
So, it seems that when it fails, it does not authenticate anymore? As there are no authentication logs in the first one.
Host (what you are running
librespoton):@kingosticks commented on GitHub (Apr 12, 2025):
Can you please fill out the issue template more fully.
@photovoltex commented on GitHub (Apr 13, 2025):
It's also a shame that snapserver seems to remove the log level of each log entry... So a standalone reproducible solution would be ideal, otherwise this might just be an issue from snapserver or spotify changing some internal handling? Did you perhaps change something on your network setup in recent times?
@photovoltex commented on GitHub (Apr 13, 2025):
Could you also take a look at #1481, some others also seem to have issues when using snapcast (don't know if that is the same, but I would assume so). I don't think this is the same issue, but maybe correlated.
@roldengarm commented on GitHub (Apr 13, 2025):
@kingosticks @photovoltex thank you for the replies, and sorry for not providing sufficient information.
It's a HP ProDesk 600 G3
It's hard to reproduce the issue as standalone, as it happens after hours / overnight. If really required, I can do another test, but for now I've reproduced the issue with librespot running from snapserver. See logs below.
It worked fine yesterday, then overnight I tried again, and on the first attempt from Spotify it disconnected when selecting the Librespot device from my Android device (around 8:04). However this time the second time it worked, around 8:06.
The one thing I've changed recently on my network is to remove one PiHole DNS server from my network, and upgraded to PiHole v6 on the server that also runs Snapserver + Librespot.
Yes it's the same product, thanks. Snapcast = snapserver + snapclient, i.e. snapserver runs on one server and snapclient on clients to output audio.
I think it's indeed a different issue.
@roldengarm commented on GitHub (Apr 14, 2025):
Quick update, I just tried connecting again, and even after trying 4 times it doesn't work; it disconnects quickly after selecting it in the Android app. Please see the librespot logs here: https://pastebin.com/QHrqtmSB
After switching a song, the same problem exists, but I see other things in the logs, it has some service unavailable logs.
https://pastebin.com/NDt0sAy6
@kingosticks commented on GitHub (Apr 14, 2025):
Are you able to reproduce this with a non-android Spotify client?
@roldengarm commented on GitHub (Apr 14, 2025):
Unfortunately currently only have Android devices in the house with which we do all music. For some reason it has stopped showing up on Spotify Web, but I hardly use that. I could try installing Spotify desktop on a Windows machine if that's important.
@photovoltex commented on GitHub (Apr 15, 2025):
When you play music on librespot and are logged in, with the same account, in the web-player, it should show up as device.
The mobile and desktop clients have some minor and major behavior differences. I would suspect hasn't anything to do with that, but it would be worth a try I would say.
@roldengarm commented on GitHub (Apr 16, 2025):
@photovoltex @kingosticks interesting. When I connect from Spotify on Windows, it works fine, ie it does not disconnect. When I open the Android app, it then also shows as connected.
However, when I disconnect, I can't connect again from the Android app.
Hope this helps with your investigation.
@roldengarm commented on GitHub (Apr 17, 2025):
@photovoltex @kingosticks As a trial I've deployed Snapserver + Librespot in a docker container and then it seems to work fine.
Unsure why it doesn't work well when directly running from the host.
@photovoltex commented on GitHub (Apr 18, 2025):
Interesting, thanks for letting us know. So the whole issue might be platform/environment dependent then?
@roldengarm commented on GitHub (Apr 19, 2025):
Yeah perhaps @photovoltex but this way I have less control over the software installed.
Any idea why it doesn't work well directly on the host? Did you have a chance to check the logs I uploaded?
@ReasonableHippo commented on GitHub (Apr 20, 2025):
I have the same issue. Can't connect from android client with the
[2025-04-20T09:14:08Z ERROR librespot_connect::spirc] could not parse session_update: Invalid state { Unknown enum variant name: WIFI_BROADCAST_CHANGED at 1:11 }messages, but it works from the web interface. If the web-player is open, i can also control from android.
Its version 0.6.0 running in a docker container on armv7l
@497e0bdf29873 commented on GitHub (May 7, 2025):
I have the same issue, running librespot standalone on Armbian on an Orange Pi 5b. It just disappears and has to be restarted. Here are the relevant logs. In particular, 15:00:09 seems relevant. 19:24:19 is already a restart after it had disappeared.
@photovoltex commented on GitHub (May 8, 2025):
@497e0bdf29873 I think yours is a different issue and not directly related to this issue. In your case you actually seem to have a log message that seems to indicate an issue with the websocket where it might not recover correctly.
@photovoltex commented on GitHub (May 8, 2025):
@roldengarm
I did skimp over them but didn't see any log entry that would indicate a major issue. Perhaps you could describe in detail what you mean by "you can't connect anymore"?
Some questions that would help with the issue:
@roldengarm commented on GitHub (May 8, 2025):
The issue was that it would immediately disconnect. It would stay visible.
However, since a week or so it's been running fine and I haven't been able to reproduce the issue.
@ReasonableHippo commented on GitHub (May 10, 2025):
i can also confirm that the issue resolved itself
@497e0bdf29873 commented on GitHub (May 14, 2025):
Yes, my issue also seems to have resolved, so I suppose it was Spotify dropping connections. For a permanent solution, librespot should be better at handling such drops.
@roldengarm commented on GitHub (May 23, 2025):
The issue seems to have come back, slightly different this time. It disconnects when I pause a track or when I minimise the Spotify app and come back. It also sometimes takes two tries to connect. @photovoltex
@dengyuihui commented on GitHub (Aug 16, 2025):
Librespot，Whether there is an interface to control the playback of up-down songs, etc.