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
• alsa_backend
• portaudio_backend
• pulseaudio_backend
• rodio_backend

Versions (please complete the following information):

• OS: NixOS 23.11
• Spotifyd: spotifyd 0.3.5
• cargo:

[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)