starred/librespot
1
0
Fork 0
mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00
Code Issues 95 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #1161] Address in use (os error 98) only on dev #537

New issue
Closed
opened 2026-02-27 19:31:10 +03:00 by kerem · 4 comments
kerem commented 2026-02-27 19:31:10 +03:00
Owner
Copy link

Originally created by @dejanzelic on GitHub (May 5, 2023).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1161

Describe the bug

When starting a build from the dev branch I get the following error:

[2023-05-05T01:41:37Z WARN  librespot] Could not initialise discovery: Attempt to create entity that already exists { Address in use (os error 98) }.
[2023-05-05T01:41:37Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible.

The error makes it sound like the port is in use and zeroconf can't start. I found this: https://github.com/librespot-org/librespot/issues/1111 issue which complained about a similar problem. If this is the issue, I should be able to change the port with the --zeroconf-port argument. However, if I add this with any open port, I still get the same error.

The reason I believe this might be a bug is because v0.4.2 works without a problem (and so does v0.3.1). I only get this error on the dev branch.

To reproduce

I get this error only when running the service in my kubernetes cluster. The container has host level network access and I do see avahi-daemon is running in another service. But what I don't understand is v0.4.2 doesn't have this issue in the same environment. While I know my problem is localized, I'll do my best to provide as much information as I can to reproduce.

Here is the deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spotify
spec:
  replicas: 1
  selector:
    matchLabels:
      name: spotify
  template:
    metadata:
      labels:
        name: spotify
    spec:
      hostNetwork: true
      containers:
      - name: office-spotify
        image: registry.gitlab.com/dejandayoff/librespot:dev
        imagePullPolicy: Always
        env:
        - name: NAME
          value: "Office"
        - name: INIT_VOLUME
          value: "100"
        - name: MQTT_HOST
          value: mqtt.custom.domain.tld
        command: ["/entrypoint.sh"]

The Kubernetes environment is fairly default install of k3s with metallb (however, metallb isn't in use for this container)

Log

/app # librespot --verbose
[2023-05-05T01:56:27Z INFO  librespot] librespot 0.5.0-dev VERGEN_IDEMPOTENT_OUTPUT (Built on 2023-05-05, Build ID: nfFiwYuI, Profile: release)
[2023-05-05T01:56:27Z TRACE librespot] Command line argument(s):
[2023-05-05T01:56:27Z TRACE librespot]          verbose
[2023-05-05T01:56:27Z DEBUG librespot_core::session] new Session
[2023-05-05T01:56:27Z DEBUG librespot_discovery::server] Zeroconf server listening on 0.0.0.0:33135
[2023-05-05T01:56:27Z WARN  librespot] Could not initialise discovery: Attempt to create entity that already exists { Address in use (os error 98) }.
[2023-05-05T01:56:27Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible.

I can confirm that nothing else is running on port 33135

/app # ss -tulpn
Netid      State       Recv-Q      Send-Q             Local Address:Port              Peer Address:Port      Process
udp        UNCONN      0           0                        0.0.0.0:60469                  0.0.0.0:*
udp        UNCONN      0           0                      10.0.2.14:7946                   0.0.0.0:*
udp        UNCONN      0           0                        0.0.0.0:68                     0.0.0.0:*
udp        UNCONN      0           0                        0.0.0.0:8472                   0.0.0.0:*
udp        UNCONN      0           0                        0.0.0.0:5353                   0.0.0.0:*
udp        UNCONN      0           0                              *:38685                        *:*
udp        UNCONN      0           0                              *:5353                         *:*
tcp        LISTEN      0           4096                   127.0.0.1:6444                   0.0.0.0:*
tcp        LISTEN      0           128                      0.0.0.0:22                     0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:10256                  0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:10249                  0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:10248                  0.0.0.0:*
tcp        LISTEN      0           4096                   10.0.2.14:7472                   0.0.0.0:*
tcp        LISTEN      0           4096                   10.0.2.14:7946                   0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:10010                  0.0.0.0:*
tcp        LISTEN      0           128                         [::]:22                        [::]:*
tcp        LISTEN      0           4096                           *:10250                        *:*

Host (what you are running librespot on):

  • OS: Ubuntu and Raspberry Pi OS
  • Platform: RPi CM4 and RPi 4

Additional context

I'm running librespot with remote pulseaudio.

I know this is the dev branch and I shouldn't expect it to work. However, I really need the session_connected events which is only available on dev. Any chance I can get an eta on when that will be released?

Any help is appreciated!

Originally created by @dejanzelic on GitHub (May 5, 2023). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1161 **Describe the bug** When starting a build from the dev branch I get the following error: ``` [2023-05-05T01:41:37Z WARN librespot] Could not initialise discovery: Attempt to create entity that already exists { Address in use (os error 98) }. [2023-05-05T01:41:37Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible. ``` The error makes it sound like the port is in use and zeroconf can't start. I found this: https://github.com/librespot-org/librespot/issues/1111 issue which complained about a similar problem. If this is the issue, I should be able to change the port with the `--zeroconf-port` argument. However, if I add this with any open port, I still get the same error. The reason I believe this might be a bug is because v0.4.2 works without a problem (and so does v0.3.1). I only get this error on the dev branch. **To reproduce** I get this error only when running the service in my kubernetes cluster. The container has host level network access and I do see avahi-daemon is running in another service. But what I don't understand is v0.4.2 doesn't have this issue in the same environment. While I know my problem is localized, I'll do my best to provide as much information as I can to reproduce. Here is the deployment: ``` apiVersion: apps/v1 kind: Deployment metadata: name: spotify spec: replicas: 1 selector: matchLabels: name: spotify template: metadata: labels: name: spotify spec: hostNetwork: true containers: - name: office-spotify image: registry.gitlab.com/dejandayoff/librespot:dev imagePullPolicy: Always env: - name: NAME value: "Office" - name: INIT_VOLUME value: "100" - name: MQTT_HOST value: mqtt.custom.domain.tld command: ["/entrypoint.sh"] ``` The Kubernetes environment is fairly default install of k3s with metallb (however, metallb isn't in use for this container) **Log** ``` /app # librespot --verbose [2023-05-05T01:56:27Z INFO librespot] librespot 0.5.0-dev VERGEN_IDEMPOTENT_OUTPUT (Built on 2023-05-05, Build ID: nfFiwYuI, Profile: release) [2023-05-05T01:56:27Z TRACE librespot] Command line argument(s): [2023-05-05T01:56:27Z TRACE librespot] verbose [2023-05-05T01:56:27Z DEBUG librespot_core::session] new Session [2023-05-05T01:56:27Z DEBUG librespot_discovery::server] Zeroconf server listening on 0.0.0.0:33135 [2023-05-05T01:56:27Z WARN librespot] Could not initialise discovery: Attempt to create entity that already exists { Address in use (os error 98) }. [2023-05-05T01:56:27Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible. ``` I can confirm that nothing else is running on port 33135 ``` /app # ss -tulpn Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process udp UNCONN 0 0 0.0.0.0:60469 0.0.0.0:* udp UNCONN 0 0 10.0.2.14:7946 0.0.0.0:* udp UNCONN 0 0 0.0.0.0:68 0.0.0.0:* udp UNCONN 0 0 0.0.0.0:8472 0.0.0.0:* udp UNCONN 0 0 0.0.0.0:5353 0.0.0.0:* udp UNCONN 0 0 *:38685 *:* udp UNCONN 0 0 *:5353 *:* tcp LISTEN 0 4096 127.0.0.1:6444 0.0.0.0:* tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:10256 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:10249 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:10248 0.0.0.0:* tcp LISTEN 0 4096 10.0.2.14:7472 0.0.0.0:* tcp LISTEN 0 4096 10.0.2.14:7946 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:10010 0.0.0.0:* tcp LISTEN 0 128 [::]:22 [::]:* tcp LISTEN 0 4096 *:10250 *:* ``` **Host (what you are running `librespot` on):** - OS: Ubuntu and Raspberry Pi OS - Platform: RPi CM4 and RPi 4 **Additional context** I'm running librespot with remote pulseaudio. I know this is the dev branch and I shouldn't expect it to work. However, I really need the `session_connected` events which is only available on dev. Any chance I can get an eta on when that will be released? Any help is appreciated!
kerem 2026-02-27 19:31:10 +03:00
  • closed this issue
  • added the
    bug
         label
kerem commented 2026-02-27 19:31:11 +03:00
Author
Owner
Copy link

@dejanzelic commented on GitHub (May 5, 2023):

This might be related but the --zeroconf-interface option doesn't do anything:

/app # librespot --verbose --zeroconf-interface="10.0.2.14" --zeroconf-port 1234
[2023-05-05T02:21:38Z INFO  librespot] librespot 0.5.0-dev VERGEN_IDEMPOTENT_OUTPUT (Built on 2023-05-05, Build ID: nfFiwYuI, Profile: release)
[2023-05-05T02:21:38Z TRACE librespot] Command line argument(s):
[2023-05-05T02:21:38Z TRACE librespot]          verbose
[2023-05-05T02:21:38Z TRACE librespot]          zeroconf-interface "10.0.2.14"
[2023-05-05T02:21:38Z TRACE librespot]          zeroconf-port "1234"
[2023-05-05T02:21:38Z DEBUG librespot_core::session] new Session
[2023-05-05T02:21:38Z DEBUG librespot_discovery::server] Zeroconf server listening on 0.0.0.0:1234
[2023-05-05T02:21:38Z WARN  librespot] Could not initialise discovery: Attempt to create entity that already exists { Address in use (os error 98) }.
[2023-05-05T02:21:38Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible.
<!-- gh-comment-id:1535616938 --> @dejanzelic commented on GitHub (May 5, 2023): This might be related but the `--zeroconf-interface` option doesn't do anything: ``` /app # librespot --verbose --zeroconf-interface="10.0.2.14" --zeroconf-port 1234 [2023-05-05T02:21:38Z INFO librespot] librespot 0.5.0-dev VERGEN_IDEMPOTENT_OUTPUT (Built on 2023-05-05, Build ID: nfFiwYuI, Profile: release) [2023-05-05T02:21:38Z TRACE librespot] Command line argument(s): [2023-05-05T02:21:38Z TRACE librespot] verbose [2023-05-05T02:21:38Z TRACE librespot] zeroconf-interface "10.0.2.14" [2023-05-05T02:21:38Z TRACE librespot] zeroconf-port "1234" [2023-05-05T02:21:38Z DEBUG librespot_core::session] new Session [2023-05-05T02:21:38Z DEBUG librespot_discovery::server] Zeroconf server listening on 0.0.0.0:1234 [2023-05-05T02:21:38Z WARN librespot] Could not initialise discovery: Attempt to create entity that already exists { Address in use (os error 98) }. [2023-05-05T02:21:38Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible. ```
kerem commented 2026-02-27 19:31:11 +03:00
Author
Owner
Copy link

@eladyn commented on GitHub (May 5, 2023):

The discovery feature of librespot is using two different ports:

  • the zeroconf port (the one you can set the port for): this used to accept connection requests from Spotify clients that want to use the device
  • the mdns port: This is used to advertise on the network, such that Spotify clients can see the device. This has to be 5353.

So your problem is presumably that - as your ss output suggests - you have a different service running on 5353 and handling mdns communication. So you'll need to find out what this other service is and stop it in order to use the discovery feature (or use the dns-sd feature instead, if the other service is avahi).

Hope this helps!

Edit: The 0.0.0.0 in your second comment is hardcoded and only applies to the HTTP server listening for the connection requests, while the zeroconf-interface applies only to mdns traffic.

<!-- gh-comment-id:1536456918 --> @eladyn commented on GitHub (May 5, 2023): The discovery feature of `librespot` is using two different ports: - the zeroconf port (the one you can set the port for): this used to accept connection requests from Spotify clients that want to use the device - the mdns port: This is used to advertise on the network, such that Spotify clients can see the device. This has to be **5353**. So your problem is presumably that - as your `ss` output suggests - you have a different service running on 5353 and handling mdns communication. So you'll need to find out what this other service is and stop it in order to use the discovery feature (or use the `dns-sd` feature instead, if the other service is avahi). Hope this helps! Edit: The `0.0.0.0` in your second comment is hardcoded and only applies to the HTTP server listening for the connection requests, while the `zeroconf-interface` applies only to `mdns` traffic.
kerem commented 2026-02-27 19:31:11 +03:00
Author
Owner
Copy link

@dejanzelic commented on GitHub (May 5, 2023):

Thanks for the response @eladyn!

I'm compiling now with-dns-sd to try that. But I stopped the avahi-daemon and am still getting the same issues:

/app # ss -tulpn
Netid      State       Recv-Q      Send-Q             Local Address:Port              Peer Address:Port      Process
udp        UNCONN      0           0                        0.0.0.0:8472                   0.0.0.0:*
udp        UNCONN      0           0                      10.0.2.13:7946                   0.0.0.0:*
udp        UNCONN      0           0                        0.0.0.0:68                     0.0.0.0:*
tcp        LISTEN      0           4096                   10.0.2.13:7472                   0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:6444                   0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:10256                  0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:10249                  0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:10248                  0.0.0.0:*
tcp        LISTEN      0           4096                   10.0.2.13:7946                   0.0.0.0:*
tcp        LISTEN      0           128                      0.0.0.0:22                     0.0.0.0:*
tcp        LISTEN      0           4096                   127.0.0.1:10010                  0.0.0.0:*
tcp        LISTEN      0           128                         [::]:22                        [::]:*
tcp        LISTEN      0           4096                           *:10250                        *:*

/app # librespot --verbose
[2023-05-05T16:15:29Z INFO  librespot] librespot 0.5.0-dev VERGEN_IDEMPOTENT_OUTPUT (Built on 2023-05-05, Build ID: nfFiwYuI, Profile: release)
[2023-05-05T16:15:29Z TRACE librespot] Command line argument(s):
[2023-05-05T16:15:29Z TRACE librespot]          verbose
[2023-05-05T16:15:29Z DEBUG librespot_core::session] new Session
[2023-05-05T16:15:29Z DEBUG librespot_discovery::server] Zeroconf server listening on 0.0.0.0:46373
[2023-05-05T16:15:29Z WARN  librespot] Could not initialise discovery: Attempt to create entity that already exists { Address in use (os error 98) }.
[2023-05-05T16:15:29Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible.
<!-- gh-comment-id:1536484365 --> @dejanzelic commented on GitHub (May 5, 2023): Thanks for the response @eladyn! I'm compiling now with-dns-sd to try that. But I stopped the avahi-daemon and am still getting the same issues: ``` /app # ss -tulpn Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process udp UNCONN 0 0 0.0.0.0:8472 0.0.0.0:* udp UNCONN 0 0 10.0.2.13:7946 0.0.0.0:* udp UNCONN 0 0 0.0.0.0:68 0.0.0.0:* tcp LISTEN 0 4096 10.0.2.13:7472 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:6444 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:10256 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:10249 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:10248 0.0.0.0:* tcp LISTEN 0 4096 10.0.2.13:7946 0.0.0.0:* tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.1:10010 0.0.0.0:* tcp LISTEN 0 128 [::]:22 [::]:* tcp LISTEN 0 4096 *:10250 *:* /app # librespot --verbose [2023-05-05T16:15:29Z INFO librespot] librespot 0.5.0-dev VERGEN_IDEMPOTENT_OUTPUT (Built on 2023-05-05, Build ID: nfFiwYuI, Profile: release) [2023-05-05T16:15:29Z TRACE librespot] Command line argument(s): [2023-05-05T16:15:29Z TRACE librespot] verbose [2023-05-05T16:15:29Z DEBUG librespot_core::session] new Session [2023-05-05T16:15:29Z DEBUG librespot_discovery::server] Zeroconf server listening on 0.0.0.0:46373 [2023-05-05T16:15:29Z WARN librespot] Could not initialise discovery: Attempt to create entity that already exists { Address in use (os error 98) }. [2023-05-05T16:15:29Z ERROR librespot] Discovery is unavailable and no credentials provided. Authentication is not possible. ```
kerem commented 2026-02-27 19:31:11 +03:00
Author
Owner
Copy link

@dejanzelic commented on GitHub (May 5, 2023):

I was able to get this to work by using your suggestion @eladyn and compiling using the feature with-dns-sd. I had to make a couple more changes to my set up. For starters, I had to add the avahi package to my container and start the avahi-daemon before I start librespot.

I then added this to my Docker build:

sed -i 's/#enable-dbus=yes/enable-dbus=no/g' /etc/avahi/avahi-daemon.conf

I also had to mount /var/run/dbus from the host to the container.

With these changes in place, librespot starts, I'm able to connect, and I get the new events!

I'm going to close this issue since my problem is resolved.

<!-- gh-comment-id:1536911805 --> @dejanzelic commented on GitHub (May 5, 2023): I was able to get this to work by using your suggestion @eladyn and compiling using the feature `with-dns-sd`. I had to make a couple more changes to my set up. For starters, I had to add the `avahi` package to my container and start the `avahi-daemon` before I start librespot. I then added this to my Docker build: ``` sed -i 's/#enable-dbus=yes/enable-dbus=no/g' /etc/avahi/avahi-daemon.conf ``` I also had to mount `/var/run/dbus` from the host to the container. With these changes in place, librespot starts, I'm able to connect, and I get the new events! I'm going to close this issue since my problem is resolved.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
dev
v0.8.0
v0.7.1
v0.7.0
v0.6.0
v0.5.0
v0.4.2
v0.4.1
v0.4.0
v0.3.1
v0.3.0
v0.2.0
v0.1.6
v0.1.5
v0.1.3
v0.1.2
v0.1.1
v0.1.0
Labels
Clear 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

Mirrored from GitHub Pull Request

  
question

   
reverse engineering

   
wiki

   
wontfix
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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#537
No description provided.