mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #509] zeroconf device shows but crashes when try to connect #322
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#322
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 @jgabriel98 on GitHub (Jul 25, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/509
when i run librespot with the following command:
librespot --name 'Smarthome' --backend pipe --bitrate 160 --disable-audio-cache --enable-volume-normalisation --linear-volume --initial-volume=100 --device /tmp/snapfifo --verbosei get this error:
Probably the relevant log part:
the full log with backtrace:
the librespot just stopped working for no obvious reason, before i could connect with n problems, but after two days this new behavior came and wont fix even if i resintall or recompile it.
Running on a raspberry pi 4, with raspbery OS.
@ashthespy commented on GitHub (Jul 26, 2020):
This hasn't got anything to do with zeroconf :-)
The error seems to stem from the your pipe
/tmp/snapfifonot being accessible (the "Permission denied" error) due to proabbly permissions. Try checking if your binary has the read/write permissions to the pipe.You could confirm by piping to
/dev/nullinstead and checking everything works (minus the sound of course)@jgabriel98 commented on GitHub (Jul 26, 2020):
as told by @ashthespy , the problem was with pipe.
Found out that in some cases shairport-sync was creating the pipe before snapcast snapserver, and it seems that shairport-sync pipe is not very friendly.
manually starting snapserver before shairport-sync solved the issue.
i will try to make the snapserver.service and shairport-sync.service services coordinate themselves, and update here any discoveries