Tagged: spotify connect librespot bug
10. Juli 2019 at 9:04 #46242
I have been using the spotify connect plugin (The max2play one, not spotty in LMS) and noticed that it is not possible to change tracks while playing. If I select a different album or track in the spotify app, it just restarts the currently playing track. What does work is disconnecting, changing tracks and reconnecting, or pressing the next/prev track options.
I’ve just compiled the latest librespot master version (), based on the steps documented in the plugin’s
install.shscript (thanks for that!), which indeed works as expected again. I used a stretch image so had to use rustup, but when using the buster image you can probably just install rust from apt instead (which has 1.34, which is more than the 1.30 required according to librespot docs).
As also predicted by the install script, this build does not work on the zero (and probably not older pis too). It seems this is because those have an Armv6 chip, while the rpi3 (where I compiled librespot) has an armv7. Raspbian is still entirely compiled for armv6 (which also runs on armv7) for compatibility, but it seems that rust by default looks at the CPU to detect the system type (rather than the existing userspace code).
This is probably easiest to fix by compiling librespot on a rpi zero rather than a rpi3. The resulting build *probably* works on all rpis. I suspect the same holds if you install rust from apt on Debian buster. Alternatively, you can also tell cargo to use a different architecture. I could not find any meaningful armv6 target in
rust -print target-list, but according to this changelog debian uses armv5te-unknown-linux-gnueabi, so I did that as well.
I tried passing this target to
rustup-init, but it did not like that. Instead, I used the
rustupcommand installed by the previous
rustup-initcommand to add the extra architecture (which installs the
stdpacakge for that arch) and then explicitly selected it with cargo.
rustup target add armv5te-unknown-linux-gnueabi
cargo build --release --features=alsa-backend --target armv5te-unknown-linux-gnueabi
This build is still running, so I can’t tell you yet whether it actually works 🙂11. Juli 2019 at 22:58 #46295
Ok, that cross-build did not work, at some point along the way the
alsa-syspackage refused to build without additional effort to make
pkg-confighappy for cross-compiling, probably since it links against a system library. Since I didn’t want to go there, I instead tried compiling on a rpi zero (which should compile for armv6 and also run on armv7 I hope), and compile using the Debian-supplied rustc on Buster (which I assume is also armv6 since it runs on the zero too).
On the rpi zero, I had to re-run
rustup-init, since the files I previously downloaded on the rpi3 did not run (segfault). After this, the build ran fine, though it did take *long* (In total probably somewhere between 4-8 hours, at some points it was crunching on a single package for so long it seemed to be stuck, but it would just be slow it seems).
On buster, using the Rasbpian-supplied rustc package, things compiled faster (since this could run on a rpi3), but took a lot more effort to get it to work (or at least to figure out a workaround). I ran into problems compiling the typenums rust package, which I traced back to a misoptimization in the LLVM backend (see this bug I reported for details). Until that bug is fixed in Raspbian, a workaround is needed. Fortunately, it is simple, just install libllvm7 from Debian rather than Raspbian:
$ wget http://ftp.de.debian.org/debian/pool/main/l/llvm-toolchain-7/libllvm7_7.0.1-8_armhf.deb
$ sudo dpkg -i libllvm7_7.0.1-8_armhf.deb
This is only needed on the rpi that compiles librespot, not for running.
The architecture used (in both approaches) is apparently
arm-unknown-linux-gnueabihf, so that’s slightly different from what I manually picked above.
Both approaches resulted in a binary that works on both zero and rpi3, and did not have the track-changing problem I started this for. The librespot compiled on the rpi zero on Stretch also worked on Buster, but the one compiled on Buster did *not* work on stretch (due to the older libc version). So, if you want to support a newer spotify plugin also on existing stretch installs, it must be compiled on older hardware to get rustup to build for the right architecture. Or maybe investigate cross-compiling after all (which might have been less work in hindsight, but I’m not going to *also* dive into that :-p).
You must be logged in to reply to this topic.