mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1437] Connection problems when requesting client token #648
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#648
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 @dbischof90 on GitHub (Jan 11, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1437
Description
A cross-compiled
librespotclient forbullseyedoesn't successfully run with a zeroconf backend.Version
librespot 0.6.0-dev 7003e98onarmhfHow to reproduce
Steps to reproduce the behavior in librespot e.g.
bookworkincontrib/Dockerfilewithbullseyeand removearmsel./librespot --name "MyLibrespotPlayer" --backend alsa --zeroconf-backend avahi --verboseLog
Nothing happens afterwards.
Host (what you are running
librespoton):Additional context
The error persists with all zeroconf backends. The speaker can be found without problems. The internet is reachable from the device.
@photovoltex commented on GitHub (Jan 11, 2025):
Does librespot work on a different device in your network? And could you alternatively try to use oauth as authentication? (see here for help on the topic https://github.com/librespot-org/librespot/wiki/Options#authentication)
@dbischof90 commented on GitHub (Jan 12, 2025):
I installed it on my laptop via
cargoand ranlibrespot --cache ./librespot_cache --enable-oauth --oauth-port 0 --verbose. On my laptop that worked! On my other device the output wasand then nothing. It seems it can't connect to the server but doesn't log that...
@photovoltex commented on GitHub (Jan 12, 2025):
What a weird behavior... Did a different version of librespot work before or is your first time using librespot on that device?
Could you ping
spotify.comon the device and see what happens?@dbischof90 commented on GitHub (Jan 12, 2025):
Sure!
I think I used librespot years ago, only now I wanted to pick it up again and try it on my media computer - there it's the first time.
So that works too. I can also ping
clienttoken.spotify.com.Is my release method maybe wrong and I am missing some dynamic libs whose output is dropped silently? I compiled via docker as written in the notes and then just copied the binary over to my device.
The (I think only relevant) other big difference is that the Vero V is still running on Bullseye, not Bookworm, but I'd be surprised if libc6 had changed that much.
@kingosticks commented on GitHub (Jan 13, 2025):
What's your CPU usage like when it seems to get stuck? I had an issue reported in my downstream project which looks a bit like this and it seemingly came down to the version of gcc used but we never really got to the bottom of it.
@dbischof90 commented on GitHub (Jan 13, 2025):
Oh you're onto something there! The process brings a single core to run at a constant 100% once I try to connect to librespot from a Spotify client!
@kingosticks commented on GitHub (Jan 13, 2025):
https://github.com/mopidy/mopidy-spotify/issues/402 is this issue in question. I provide armv6 compatible armhf builds using the raspberry pi toolchain. This binary seems to hang, similarly to yours, when run via arm32v7/Bullseye Docker on a CoreElec system (armlogic??).
Instead, if it's compiled using that same Docker container with normal gcc then the problem goes away. I think we concluded it wasn't a Docker issue because my provided binary works fine under Docker on a different armhf machine. So perhaps a compiler compatibility problem with the hardware. One other thing maybe relevant to you is this is also with Bullseye.
@dbischof90 commented on GitHub (Jan 14, 2025):
This is interesting - thank you for the input. I'm not so sure it's worth the deep dive - I know that the migration to >=bookwork in OSMC should start soon so in ~6-12 months that might not be so relevant anymore. I'll glue together a Docker image and virtualize until I can run native then.
@kingosticks commented on GitHub (Jan 14, 2025):
Fair enough. Just to confirm and for anyone else that finds themselves here
@dbischof90 commented on GitHub (Jan 14, 2025):
Just to mention, not that I wouldn't want to, it's just that I feel I'm neither familiar enough with the hardware nor the compiler to provide more than uneducated guesses - if there is an interest in debugging and solving that I am very happy to play the tool for the job. The current guess seems to be that it is not too unlikely that it could be Bullseye on that hardware.
That factor should go away if I use a Bookworm base image on Docker, right. I'll report the result of that here.
@kingosticks commented on GitHub (Jan 14, 2025):
I have no idea!
with-vorbisandwith-tremorfeatures #1057