Spotify connect plugin cannot change to different track

Max2Play Home 2016 (en) Forums Max2Play Add-ons Spotify connect plugin cannot change to different track

This topic contains 1 reply, has 1 voice, and was last updated by  matthijskooijman premium 4 days, 21 hours ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • 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 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 🙂

    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
    $ 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).

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.

Register here