Spotify connect plugin cannot change to different track

[matthijskooijman premium]

matthijskooijman premium

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.

This issue is reported upstream, but also already fixed in librespot master. Apparently the problem is due to some changes in the spotify server side, which is why this used to work originally.

I’ve just compiled the latest librespot master version (), based on the steps documented in the plugin’s install.sh script (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 rustup command installed by the previous rustup-init command to add the extra architecture (which installs the std pacakge 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 🙂

[matthijskooijman premium]

matthijskooijman premium

11. Juli 2019 at 22:58 #46295

Ok, that cross-build did not work, at some point along the way the alsa-sys package refused to build without additional effort to make pkg-config happy 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).

[flysurfer Moderator]

flysurfer Moderator

17. Juli 2019 at 11:47 #46343

Thanks again for your detailled information!

I will update the spotify connect plugin with the latest librespot sources (been waiting for the bugfix for playlist change) and compile it on the stretch image as you suggested. I’d rather use the PI 4, but we need to support the Stretch Images… Building a toolchain to compile downwards compatible on the PI 4 with buster might take me much longer than just using the PI 3.

Hopefully the new binary will be available later today 🙂

All the Best
Stefan

[matthijskooijman premium]

matthijskooijman premium

17. Juli 2019 at 12:06 #46345

Building a toolchain to compile downwards compatible on the PI 4 with buster might take me much longer than just using the PI 3.

If you compile on the rpi3 (with rustc from rustup), that does mean the binary will not run on the rpi zero, right? Any plans to update that binary as well?

One alternative that sprung to mind would be to combine both of my approaches by installing the rustc package from Buster on a Stretch system. If that works dependency-wise (which might be tricky), that will probably result in a binary that works on Stretch and Buster.

Also, if you’re thinking of cross-compiling from a pi4, it might be more interesting to look at cross-compiling this on a regular x86 system, which could be a *lot* faster. There’s probably some tutorials for this, though I haven’t investigated yet.

In the meanwhile, the problem with libllvm7 in Buster seems to be figured out (maybe even fixed already, haven’t checked). See https://github.com/rust-lang/rust/issues/60019#issuecomment-512073512

[flysurfer Moderator]

flysurfer Moderator

17. Juli 2019 at 12:42 #46346

Hi,

that does mean the binary will not run on the rpi zero

that’s correct. Last time I also compiled it on the Zero… which took very long. I will do this later, after confirming that it works on the Pi 3.

[flysurfer Moderator]

flysurfer Moderator

18. Juli 2019 at 11:00 #46364

Ok – the updated version of librespot is now available for all Pi versions (including zero) and image versions (stretch + buster).

The correct binary is downloaded from our server during installation the spotify connect plugin.

Just tested it and it runs fine.

Thanks matthijs!