dtcooper / raspotify

A Spotify Connect client that mostly Just Works™

Home Page:https://dtcooper.github.io/raspotify

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Setting up dns-sd failed

pimvh opened this issue · comments

Compatible Device

  • I'm running Raspotify on a compatible Device

Compatible OS

  • I'm running Raspotify on a compatible OS

Latest Version

  • I'm running the latest version of Raspotify

Due Diligence

  • I have done my due diligence

What happened?

Hi!

Thanks for the great library. I've been trying to get raspotify to work again, after upgrading to debian bullseye, but have been running into same issue again and again.

I've added the relevant log line below, but there seems to be an issue in the underlying librespot library.

I've look around and this issue seems related/relevant, so I've followed the steps from there:

cargo build --release --features with-dns-sd

For compilation I had to install cargo. During compiling I had to install librust-alsa-sys-dev and install libavahi-compat-libdnssd-dev. Respectively:

curl https://sh.rustup.rs -sSf | sh
sudo apt install librust-alsa-sys-dev libavahi-compat-libdnssd-dev

After doing this, the issue is still there. Have you encountered this issue before or do you know of a solution? Might this be IPv6 related?

I did not include the syslog, as it did not yield any useful info related to this issue.

Oh and I am running this on a RaspberryPi4:

Linux raspberrypi 5.15.32-v7l+ #1538 SMP Thu Mar 31 19:39:41 BST 2022 armv7l GNU/Linux

No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye

Relevant log output

Mar 30 21:57:23 raspberrypi librespot[495]: [2022-03-30T20:57:23Z ERROR librespot] Discovery Error: Setting up dns-sd failed: No such device (os error 19)
Mar 30 21:57:23 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE

The librespot binary that is packaged in Raspotify is not compiled with the with-dns-sd feature (as you already know). Questions about librespot compilation and the use of features not included in the packaged binary are out of the scope of this project. If you want help compiling libresot you should ask for help there.

This issue is invalid.

Thanks for the pointers.

However, I only recompiled the librespot underlying library, because the error message produced by raspotify pushed me in that direction and I thought it might lead me to a fix for that issue (which I could share with the community). I do not actually want to recompile that software by hand. From what I understand raspotify is a great wrapper around the librespot library.

I was asking for a fix for the issue in raspotify (see the relevant log line above). What do you think might be the issue?

Trouble shooting an issue with the packaged binary is one thing. Trouble shooting issues with features not included in the packaged binary is another.

The above log message is caused by a feature not included in the binaries I build here.

Dear Jason, thanks for your clear reply. This indicates to me that I am using your repository in a way you have not intended it.

The goal of this package of it is to run the installation script on a fresh debian distro, and it works out of the box right? What am I doing wrong?

What am I doing wrong?

It's really hard to say since you haven't given me any real solid info about the problem that led you to building librespot yourself and then coming here to ask for support for a feature not present in the librespot binary that ships with this package.

You're putting the cart way before the horse.

Dear Jason, thanks for your reply. The issue that started me to recompile raspotify was the output in logging (from journalctl -u raspotify), see below:

Mar 30 21:57:23 raspberrypi librespot[495]: [2022-03-30T20:57:23Z ERROR librespot] Discovery Error: Setting up dns-sd failed: No such device (os error 19)
Mar 30 21:57:23 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE

Syslog doesn't really show anything useful:

May 30 16:19:34 raspberrypi systemd[1]: raspotify.service: Consumed 6.518s CPU time.
May 30 16:21:02 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
May 30 16:21:02 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
May 30 16:21:12 raspberrypi systemd[1]: raspotify.service: Scheduled restart job, restart counter is at 1.
May 30 16:26:18 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
May 30 16:26:18 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
May 30 16:26:28 raspberrypi systemd[1]: raspotify.service: Scheduled restart job, restart counter is at 1.

Does this give more insight into the issue?

If was not able to find anything else to go on, but if you have other logging sources of interest that might be useful for further triage, please point them out.

Are you trying to run Raspotify in some type of container maybe?

I don't know?

Otherwise maybe try uninstall everything avahi-* and reinstalling Raspotify. librespot's default mDNS implementation is self contained and there can be issues sometimes running 2 mDNS implementations on the same machine.

Only do this if you're sure you don't need avahi for anything else:

If You Do This and it Breaks Your System You get to Keep all the Pieces.

sudo apt purge avahi-* -y && sudo apt autoremove --purge -y

Then reboot and see if that helps.

Dear Jason,

Yeah I also find this little to go on. After uninstalling avahi, the issue remains (at least we now now it had nothing to do that).

No I am not running raspotify from a container.

I'll continue the search. If I find anything useful I'll report back. Suggestions are welcome.

@pimvh I've been having the same issue you described here.
@JasonLG1979 This happened with the packaged version from the apt-repository, no custom compiled version. I'm on Raspbian 11, up-to-date packages at this time, RPi4.

In my case the problem was a wireguard interface on my system that was routing all the traffic through that interface, meaning the peer-configuration in the wireguard-config contained Allowed IPs = 0.0.0.0/0.
This somehow caused the dns-sd-component not being able to register and librespot crashing.
I don't see this as a direct issue with raspotify or librespot, more of a combination of the this software and how wireguard interfaces/routing works. As soon as i changed AllowedIPs in the wireguard-config to restrict it to some address-ranges raspotify/librespot started working flawlessly again.
You probably don't want to make the librespot-service available through your tunnel anyway.

Just wanted to leave this information here in case anybody else has a similar setup.

Thanks for sharing. It might be something network related then. I am not running wireguard, but this helps my investigation.

Just leaving this here for anyone who comes across this in the future. All traces from the mdns errors have saidly been flushed from my syslogs, so I can't really do any detailed triage, but it suddenly started working again. I think @koeniglorenz you are right, I didn't notice at first, but after excluding local IPs from my wireguard config this issue suddenly disappeared. If anyone is experience this issue it is probably networking related (probably not mDNS itself).

You should probably try to refresh/reload whatever network stack or VPN you are running, and see whether it is configured correctly.

If this issue pops up again in the future, and I have logging, I will be sure to document it more thoroughly. Weird interaction though.

I also encountered this issue on a fresh install of Raspbian Bullseye 64bit and Raspotify 0.41.0~librespot.v0.4.1.

I don't have wireguard installed nor did I try recompiling librespot.

After sudo systemctl restart networking I'm was able to start the raspotify daemon successfully.

On a reboot (without calling systemctl manually) the daemon restarts itself a few times:

$ journalctl -u raspotify
-- Boot 58324cd5933c46e3b0211ba9d2d37c72 --
Jul 02 10:43:29 raiel systemd[1]: Started Raspotify (Spotify Connect Client).
Jul 02 10:43:31 raiel librespot[569]: [2022-07-02T08:43:31Z WARN  librespot] Could not initialise discovery: Setting up dns-sd failed: No such device (os error 19).
Jul 02 10:43:31 raiel librespot[569]: [2022-07-02T08:43:31Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible.
Jul 02 10:43:31 raiel systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
Jul 02 10:43:31 raiel systemd[1]: raspotify.service: Failed with result 'exit-code'.
Jul 02 10:43:41 raiel systemd[1]: raspotify.service: Scheduled restart job, restart counter is at 1.
Jul 02 10:43:41 raiel systemd[1]: Stopped Raspotify (Spotify Connect Client).
Jul 02 10:43:41 raiel systemd[1]: Started Raspotify (Spotify Connect Client).
Jul 02 10:43:41 raiel librespot[1109]: [2022-07-02T08:43:41Z WARN  librespot] Could not initialise discovery: Setting up dns-sd failed: No such device (os error 19).
Jul 02 10:43:41 raiel librespot[1109]: [2022-07-02T08:43:41Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible.
Jul 02 10:43:41 raiel systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
Jul 02 10:43:41 raiel systemd[1]: raspotify.service: Failed with result 'exit-code'.
Jul 02 10:44:11 raiel systemd[1]: raspotify.service: Scheduled restart job, restart counter is at 2.
Jul 02 10:44:11 raiel systemd[1]: Stopped Raspotify (Spotify Connect Client).
Jul 02 10:44:11 raiel systemd[1]: Started Raspotify (Spotify Connect Client).

This works, but maybe a tweaked configuration could avoid the restarts? Perhaps it's something about service dependencies? With a bit of luck that might also ensure raspotify can start without needing to manually restart the networking service.

fwiw I wouldn't consider this an unintended use - probably just something that more and more users will encounter as they upgrade to bullseye.

Raspotify is already set to start after the sound and network target.

Wants=network.target sound.target
After=network.target sound.target

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Wants=

@Robsteranium your problem seems to be that the network target is failing at startup for whatever reason. That has nothing to do with Raspotify.

I encountered the same problem (error message in logs about dns-sd failing and cannot connect) and seemed to be this same networking startup issue. I was using the latest 32 bit raspberry pi OS, then installed raspotify and it failed with dns-sd failing. Fix was to go to Raspberry Pi configuration and turn on "Network at boot" (wait for network during boot sequence).

OK I'm locking this. The initial issue has nothing to do with the binary built for Raspotify and the other questions and comments are not even directly related to the initial issue.