Cannot run spotifyd with multiple IPs on the same interface

[nalves599]

Description Cannot launch spotifyd with discovery when there are 2 IPs (i.e. 2 IPv4 ) on the same interface. It gives the following error:

Message:  called `Result::unwrap()` on an `Err` value: DnsSdError(Os { code: 98, kind: AddrInUse, message: "Address already in use" })

To Reproduce

1. Run spotifyd --no-daemon and ensure it works. Close the program.
2. Add an IPv4 to your network interface (e.g. sudo ip add 192.168.1.123/24 dev enp1s0)
3. Run spotifyd --no-daemon again and it will get the error above.

Expected behavior If the Zeroconf server is already listening on all interfaces with 0.0.0.0 it should not try to bind to the other IP.

Logs

Click to show logs

<!-- PLEASE PASTE YOUR LOGS BELOW THIS LINE WHEN REPORTING BUGS. Make sure to run spotifyd using the `--verbose` flag -->
spotifyd --no-daemon --verbose
No config file specified. Running with default values
CliConfig { config_path: None, no_daemon: true, verbose: true, pid: None, shared_config: SharedConfigValues { username: None, username_cmd: None, password: None, password_cmd: None, use_keyring: false, use_mpris: None, dbus_type: None, on_song_change_hook: None, cache_path: None, no-audio-cache: false, backend: None, volume_controller: None, device: None, control: None, mixer: None, device_name: None, bitrate: None, audio_format: None, initial_volume: None, volume_normalisation: false, normalisation_pregain: None, zeroconf_port: None, proxy: None, device_type: None, autoplay: false, max_cache_size: None } }
Found user shell: Some("/run/current-system/sw/bin/bash")
No username specified. Checking username_cmd
No username_cmd specified
No password specified. Checking password_cmd
No password_cmd specified
No proxy specified
registering event source with poller: token=Token(2147483649), interests=READABLE
Using software volume controller.
no usable credentials found, enabling discovery
Using device id '3ad21dfd52db1f2f20d8a9815c37bc58c8d0b643'
registering event source with poller: token=Token(0), interests=READABLE | WRITABLE
Zeroconf server listening on 0.0.0.0:35523
registering event source with poller: token=Token(1), interests=READABLE | WRITABLE
deregistering event source from poller
The application panicked (crashed).
Message:  called `Result::unwrap()` on an `Err` value: DnsSdError(Os { code: 98, kind: AddrInUse, message: "Address already in use" })
Location: src/setup.rs:105

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
Shutting down discovery server
deregistering event source from poller
<!-- They have to be betwenn the `/summary` and the `/details` HTML tags, and inside the backticks '`' -->  

Compilation flags

• [ ] dbus_mpris
• [ ] dbus_keyring
• [x] alsa_backend
• [ ] portaudio_backend
• [ ] pulseaudio_backend
• [ ] rodio_backend

Versions (please complete the following information):

• OS: NixOS 23.11
• Spotifyd: spotifyd 0.3.5
• cargo: <!-- cargo --version -->

[ParetoOptimalDev]

I'm also affected by either this or perhaps #247. Perhaps this behavior or zerotier itself conflicts with tailscale?

[trames57]

I think I am affected by this also. I have a virtual machine bridge set up that has 2 IP addresses. Using discovery is important now that user/password is not working anymore. I have been trying both with the Spotify web client and the Spotify Linux client running. Also see #51 OS: arch linux Spotifyd: 0.3.5

Using ip -c a

2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vmbr01 state UP group default qlen 1000 link/ether d4:5d:64:28:82:35 brd ff:ff:ff:ff:ff:ff 3: vmbr01: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 0a:2e:28:78:f3:81 brd ff:ff:ff:ff:ff:ff inet 192.168.1.5/24 brd 192.168.1.255 scope global vmbr01 valid_lft forever preferred_lft forever inet 192.168.1.10/24 brd 192.168.1.255 scope global secondary vmbr01 valid_lft forever preferred_lft forever inet6 fe80::82e:28ff:fe78:f381/64 scope link proto kernel_ll valid_lft forever preferred_lft forever

EDIT: I am confirming that when I removed the 192.168.1.10 address, spotifyd --no-daemon did go into discovery mode and the device showed up in the Spotify client.

[eladyn]

I created a PR over at librespot-org/libmdns#58 which should fix this issue. Now all we have to do is wait for it to get merged, adapted in librespot and update to the new librespot version. But if someone has the time, any testing of this PR would be greatly appreciated. (Just do cargo run --example register on the PR)

[nalves599]

@eladyn Release 0.5.0 of librespot has been released which might fix this issue

[eladyn]

Oh, that's great to hear. I'll try to get to it during the weekend, though if someone else is willing to have a go at it until then, always do!

[nalves599]

We tried to upgrade librespot to release 0.5.0 but spotifyd seems not to work. You can check our changes here

[jakkul]

I'm affected by this. Removed the second address and now it runs. Official 0.4.1 release.

[eladyn]

@jakkul Would you be able to post logs of the application not working?

[jakkul]

my logs are exactly the same as in the first comment in this ticket.

Reproduction steps:

• make sure you have one IP on your linux host
• run spotifyd - everything runs OK
• kill spotifyd
• ifconfig eth0:0 192.168.168.183 netmask 255.255.255.0 (or something else, you need a second IP)
• run spotifyd - you'll get the errors
• deconfigure the interface or reboot your machine
• run spotifyd - everything runs OK