librespot: Spotify does not detect Librespot as a device

Hi, I have been using Librespot for a few months now without any issues. Starting this month (October) though, none of my Librespot instances show up in Spotify.

I am running Librespot in Docker containers on a Raspberry Pi 4, but I also tried a direct cargo install librespot on my laptop with no success.

I have made no changes to my home network and I have tried with various combinations of Wi-Fi 2,ghz, Wi-Fi 5ghz and just everything wired together via Ethernet cable. I see no errors in Librespot’s logs (besides ones about the Avahi demon when running inside a container).

Versions tried: 0.1.6 (this one was previously working) 0.2.0 (ditto) 0.3.1

Any tips on how to debug this?

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 77 (39 by maintainers)

Most upvoted comments

Great stuff @dubo-dubon-duponey, your input and documentation is highly appreciated.

@itwasonlyabug I’m fine with keeping this issue open. Although I have no idea what’s going on, I do find it interesting that shairplay works and librespot doesn’t. So if there’s a chance that librespot can be improved in this regard, then that’s worth pursuing.

@roderickvd I shared notes / experiences about these topics ^ on the wiki: https://github.com/librespot-org/librespot/wiki/librespot,-mDNS,-networking-and-containers in the hope that could help people who have issues related to containers / mDNS.

I hope this was the appropriate thing to do, but evidently feel free to do whatever you need with that page.

@itwasonlyabug ^

@itwasonlyabug network host is likely problematic if your host also has avahi installed. Multiple mDNS stacks on the same ip will compete / not play well with each other.

Can you try to use macvlan instead of host? (or make sure your host does not have any mDNS stack running - eg: avahi)

And also make sure you use your version of librespot that does not use avahi (simplifies your problem).

For macvlan, if you are not familiar, see https://docs.docker.com/network/macvlan/ - something in the line of:

docker network create -d macvlan \
  --subnet=192.168.0.0/24 \
  --ip-range=192.168.0.128/25 \
  --gateway=192.168.0.1 \
  -o parent=eth0 my-macvlan

And I honestly have no idea how long the tokens are good for?

The new-api branch has a new caching token provider that automatically refreshes tokens 10 seconds before they expire. It also reveals when the expiry time is. This is something that Spotify sets and isn’t guaranteed to be any set value in the future.

Just wanted to say I’m not dead

Well that’s always good to hear 😆 Thanks for the update.

Just wanted to say I’m not dead - having some difficulties with the cabling, but will be able to test this in the next couple of days.

@roderickvd

From a cursory look & quick traffic sniffing, it seems to me that librespot uses aggressively short TTL (60 sec), and also does not appropriately set the cache flush bits on records.

For comparison, shairport sync uses a 75 minutes TTL, and does set the cache flush bit on all records but PTR. So does Sonos (and also macOS).

Please take what I say with a grain of salt, as I’m not that familiar with the spec, but to me, very short TTLs like that are much more likely to trip multicast storm control with some gear, and lack of cache flush bit will very likely append multiple conflicting IN records for eg on restart (albeit given the short TTLs…).

I do not know if @itwasonlyabug problem is related to that ^ (we may get an answer when they will have run through my tests above ^, or if they can tcpdump), and again I’m not 100% comfortable with these topics, but I thought I would still point these two facts out.

@dubo-dubon-duponey

0.24 is the “unmodified” dockerfile I sent in the coment above

So, 0.24 appears to use librespot 0.1.6 which is quite old. I would just try with 0.3.1.

and 0.25.1 is the modified (with avahi) that I shared above.

This one forces librespot to use avahi, which IIRC does require dbus (which you disabled).

Avahi works fine withOUT dbus if you are interested in resolution only - but (again IIRC) publishing with dnssd-dev does require dbus.

This is one of the reason avahi (in a container) is usually a bad idea. Just to annonce a single service, you have to spin up two different daemons (and the dbus one requires root IIRC).

Summarizing:

  • in containers, just stay away from avahi as much as you can
  • simplify your problem by using / building JUST librespot, 0.3.1, and nothing else
  • do not use networking bridge (obviously…) neither host networking - use macvlan (or ipvlan if you prefer)

Let me know if it still does not work, there are more things we can try.

@itwasonlyabug

I’ve been (and still am) running librespot in containers successfully (currently running 0.3.1).

  1. can you copy the exact command you use to start your container? specifically, what networking mode you are using

  2. also, personal opinion: just avoid avahi - it’s messy in containers and definitely a source of issues when multiple instances share the same ip - you do not need avahi to use librespot

Can you give me some idea how to get some more logs out of Librespot … All I can see is librespot starting and Zeroconf listening but no idea where the connection breaks. I can hit Zeroconf/Librespot on the port it picks, but this isn’t logged in Librespot.

There would be no logs from librespot as far as it’s concerned it’s advertised itself as a service. If there are no logs than no connection is being made.

breadcrumbs what the path fro Device A to Device B is so I can try to unwrap this?

I believe that avahi has a GUI app. I have never used it but maybe that will help.

Nothing in librespot has changed as far as discovery in a very long time, 6 months or so from the looks of things. (https://github.com/librespot-org/librespot/tree/dev/discovery)

If it worked forever but than stopped working clearly something has changed on your side that you have not found yet. Other devices can interfere with mdns. What new devices have you added to your network?