Which version of librespot does raspotify use?

[NePoCz]

Hi thanks for the great project and sorry for perhaps a stupid question - but what version of librespot does raspotify use? In the link to "a fork (...of librespot)" at the beginning of the readme, the link points to the "raspotify" branch of your librespot fork, which is more thank 200 commits behind current dev branch of librespot & has some raspotify specific commits. But looking at build.sh, it downloads and builds the default (i.e. dev) branch of your librespot fork, right? And this one is almost up to date, but without any raspotify-specific commits - so is there a reason why to use a custom fork at the moment? Or is the "raspotify" branch still used for builds?

[JasonLG1979]

Dev is what will someday become librespot 0.5. It is currently not really stable or ready for regular use and there's no telling how long it will be until it is.

The fork is based on the old API branch which is the current stable librespot release, but being as though dev is the default branch it's going to be behind dev.

The fork is mostly dependency updates. I switched to the fork because upstream librespot is more than happy to just let the current stable librespot version rot.

I put in PR that bumped the dependencies and I got way, way to much pushback so I said piss on it and forked it. At some point after 0.5 is released I will revisit.

Edit: The build script checks out the raspotify branch. That is what is built.

[JasonLG1979]

Does it actually work as intended? Because honestly I'm not even sure how to use the option? I don't run Raspotify in any sort of container and I really don't have any experience with containers beyond using them to build things.

[JasonLG1979]

I ask because the behavior is different than dev when feeding it a random valid looking IP. In dev discovery shuts down if the IP is not actually valid. With this backport it binds to 0.0.0.0. So I want to make sure that it's just falling back to that and not just ignoring IP's all the time.

[NePoCz]

I dont run raspotify in container either, but the problem for me was, that as I have many running containers (and hence many docker "veth..." interfaces created), mdns doesnt work properly - probably cant really bind to all 15+ interfaces or doesnt detect default one properly. Thats where this option comes in handy, as I can specify my home network interface and discovery works fine again.
Previously, the only option was to use dns-sd, but that created other problem... So yes, I think it works as intended
Edit: yes both scenarios seem to work as intended. If I have too many interfaces and raspotify isnt discoverable, then selecting interface fixes that. And when I stop all containers (i.e. raspotify is discoverable even without the interface set), then supplying random IP still works, so it must fall back to 0.0.0.0

[JasonLG1979]

Sounds good. In any event it doesn't seem to break the default behavior so if any wrinkles show up we can fix them later.

[JasonLG1979]

Done. I just released 0.43.11 which includes the backport.