mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1102] Spotify API does not list Librespot as device after some time of no playback #512
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#512
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 @jcv8-dev on GitHub (Jan 16, 2023).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1102
Describe the bug
Some time (haven't measured) after playback has stopped, the spotify get-available-devices api endpoint stops listing the librespot player as a device. Only after starting playback via the desktop app on the librespot player (it still shows up there) it shows up again in the api response. I can't tell if the fault is on spotify's end or with librespot or my configuration.
To reproduce
Steps to reproduce the behavior:
librespot --name "Librespot" -b 320 -c /tmp --enable-volume-normalisation --initial-volume 30 --device-type speaker -v -u username -p "password"Log
Never had the terminal open when it happened, might add later if needed.
Host (what you are running
librespoton):@roderickvd commented on GitHub (Jan 16, 2023):
Please add a verbose log.
@jcv8-dev commented on GitHub (Jan 16, 2023):
This is the log from before the device disappears in the api response. Currently waiting for it to disappear again, will add extra log entries then.
@jcv8-dev commented on GitHub (Jan 17, 2023):
I tried using the e-mail address of my spotify-account instead of the username and the error did not occur over one day. I will report back if that was not the solution.
@roderickvd commented on GitHub (Jan 17, 2023):
If it pops up again, let's try and see if that way of authentication matters. For my own listening I always use zeroconf-based authentication, not username-based, I wonder if that makes a difference.
@jcv8-dev commented on GitHub (Jan 17, 2023):
Ok, it happened again, but since I run librespot as a service, i don't have any logs on hand. Is it practical to redirect the output (stdout i guess) to a file?
This is what
systemctl status librespotgave me after the player disappeared from the api (i have the librespot command in a .sh file that also containspulseaudio -D):@roderickvd commented on GitHub (Jan 18, 2023):
We indeed still need that log. And am still interested if it’s different if you authenticate using Connect (zeroconf).
Note that most zeroconf problems are network related, can you rule that out?
It’s also possible that we need to send some ping message that we don’t know about. Is it different between 0.4.x and dev?
The cannot bind message is probably harmless, and probably that it cannot bind to an IPv6 address. Correct?
@jcv8-dev commented on GitHub (Jan 19, 2023):
Switched to zeroconf and set up a automation in Home Assistant that notifies my when the player does not show up anymore.
couldn't parse packetpretty much lines up with the first notification and the rest of the log messages shows up all day. Yes, i have disabled IPv6 on my network.@roderickvd commented on GitHub (Jan 19, 2023):
And is it now still happening to you with zeroconf?
@jcv8-dev commented on GitHub (Jan 19, 2023):
Yes
@jcv8-dev commented on GitHub (Jan 20, 2023):
I finally found the culprit: Librespot becomes unavailable everytime my isp assigns me a new IP address (usually once a day). Librespot still shows up in the spotify app, because it also scans the local network (thats what i guess at least).
Edit: look at the correlation between "librespot shows up" (top) and the ip address from my router (bottom) imgur
@kingosticks commented on GitHub (Jan 20, 2023):
Good digging. So if you are playing music when librespot's IP changes, the regular outgoing status messages from librespot will fail at some point (server can't ack), librespot will notice and presumably reconnect. I'm surprised there are no log messages about this in your workinh situation.
When not playing music, librespot doesn't send anything so there's nothing to fail. Although it will stop receiving Ping messages from the server, I don't think we notice. The Dealer in dev does have code to check for regular websocket pings from the server and you'd expect that to trigger (and log); unless the Dealer is only alive when librespot is the active device / playing?
I didn't look what the stable branch does.
@jcv8-dev commented on GitHub (Jan 20, 2023):
Just messed arround with requesting new ip addresses through my router and can confirm the change of the ip address does not affect librespot while it is active. When it is not active ("is_active": false in the api response), it disappears.
I guess the easiest (temporary?) fix for me would be to write a simple (bash)script that detects a change of the ip address and just restarts librespot.
@kingosticks commented on GitHub (Jan 20, 2023):
You could also try the dev branch. I think the websocket connection that uses will notice the server pings have stopped and hopefully do something about it.
@jcv8-dev commented on GitHub (Jan 20, 2023):
I think I am using the dev branch. At least the readme in my librespot folder is the one from dev. I don't actually remember which one i ended up running as i tried both when I had issues getting audio output.
@kingosticks commented on GitHub (Jan 20, 2023):
Oh, I see. The original log shows v0.4.2 which is the master (stable) branch.
@roderickvd commented on GitHub (Jan 20, 2023):
dev hasn’t hooked up the dealer yet. That’s actually the next huge piece of work that should be for 0.6 I think.
@kingosticks commented on GitHub (Jan 20, 2023):
We should add something like
github.com/librespot-org/librespot-java@c3473bda8a/lib/src/main/java/xyz/gianlu/librespot/core/Session.java (L1437-L1442)@roderickvd commented on GitHub (Jan 21, 2023):
Yes that might work!
@T-vK commented on GitHub (Jun 8, 2023):
Why was the issue closed? Has it been resolved?
@roderickvd commented on GitHub (Jun 9, 2023):
Yes, by #1129 as mentioned above.
@nullr0ute commented on GitHub (Jun 9, 2023):
Might be useful to tag a new release to make that more clear?
@kingosticks commented on GitHub (Jun 9, 2023):
It would be useful if someone could verify it in this context. If you're hitting the issue that should be easy to do.
@T-vK commented on GitHub (Jun 10, 2023):
@roderickvd Thank you.
Can anyone explain in more detail in what way it has been fixed? Does it automatically reconnect now? Or does it exit now when the connection is dropped or throw an error? Are there new flags?
Can anyone provide an example on how to launch librespot in a way that it stays connected or automatically reconnects when it loses the connection? :)
@kingosticks commented on GitHub (Jun 10, 2023):
There are no flags, the detection happens automatically in the latest code. You need to test and see if your issue here is fixed. If it's not, we'll reopen the issue. That's how this works.
@T-vK commented on GitHub (Jun 10, 2023):
When the automatic detection happens, does it just print an error or quit or does it automatically reconnect as well?
I'm just asking because if it doesn't reconnect automatically, I'd have to write some wrapper code in order to test it.
@roderickvd commented on GitHub (Jun 10, 2023):
Let’s not confuse this with automatically reconnecting after loss of network or peer disconnection. That’s not this.
This sends pings when the player is idle, so the server knows we’re alive and doesn’t disconnect us.
Other than that: what @kingosticks said.
@T-vK commented on GitHub (Jun 11, 2023):
I see, sorry for the confusion.
A new release tag would be greatly appreciated. Is there anything in particular that needs to be done first?
@eladyn commented on GitHub (Jun 11, 2023):
Well, it also makes sure that
librespotregularly receives those pings and otherwise invalidates the session. Usually, it should then try to reconnect with the last credentials. (not preserving the playback state, however)