Forum Replies Created
-
Posted in: Allo USB Bundle
-
25. August 2022 at 14:43 #52365
I checked, and indeed, if I just enter my username/password, librespot works as expected. Thanks!
23. August 2022 at 13:36 #52361Thanks for your response. I was under the impression that the authentication part of the process worked fine, since I could select the player in the Spotify app as expected and the log does say „authenticated as“. But maybe I also need to fill in details, I can try that.
Note that I have been working with the squeezeserver spotty plugin, which has been working fine so far, so this is not a blocking issue for me anymore. Maybe the downsides I remember from years ago are fixed there (or maybe the downside was that it was a bit tricky to switch between synchronized and non-synchronized playback, but I solved this nicely with multisqueeze to run two squeeze clients using the same audio device, one synchronized with other players and one independent).
17. Juli 2019 at 12:06 #46345Building 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
11. Juli 2019 at 22:58 #46295Ok, that cross-build did not work, at some point along the way the
alsa-syspackage refused to build without additional effort to makepkg-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.debThis 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).
11. Juli 2019 at 22:21 #46294Hm, I also *think* that either updating the plugin (using the beta url), or reinstalling spotify connect removes the
-C 5option from squeezelite, since I had to re-add that in two or all three installations just now.11. Juli 2019 at 22:13 #46293Cool, thanks for the superswift response and update 🙂
I’ve installed the beta plugin on a few boards and it works like a charm, excellent! I would suggest adding a bit more explanation to the discover option. Perhaps something like „When discovery is enabled, anyone on the local network can control the player. When it is disabled, it can only be controlled from the account set above.“?
Somewhat related, when I clicked the reinstall button in the Spotify Connect tab, I got this message: „Something went wrong in last Install Attempt – Deleting Progressfile“. I’ve seen this on all three pi’s I’ve done the update on, but I believe I’ve also seen it before the update, so it might be unrelated to this update.
9. Juli 2019 at 22:20 #46240Note, to really test that librespot does not authenticate without a username and password, also remove its
/tmp/credentials.jsoncache file. I suspect (but have not verified) that when restarting librespot after some local connection was made, it reuses the previous authentication from that file.9. Juli 2019 at 22:16 #46239Not that libreoffice does support access by other spotify clients under other spotify accounts on the same network, but this requires discovery to be enabled. See https://www.max2play.com/en/forums/topic/enable-discovery-for-spotify-connect-to-allow-other-accounts-on-the-network/ for details.
9. Juli 2019 at 3:46 #46208Great plugin. AFAICS you can also use it with just a button without all the rest of the circuitry, to safely shutdown the Raspberry pi (it will end up in a low power sleep mode rather than being completely off). If you use GPIO3 (pin 5) for this, you can even power it on again with the same button.
However, I noticed this plugin uses a bash script and wiringpi to read the button. It might be possible to simplify this using dtoverlays. See [url=https://www.stderr.nl/Blog/Hardware/RaspberryPi/PowerButton.html]this post[/url] I wrote about this a while back. The post is only about letting the kernel handle the shutdown pin, but I believe there is also a gpio-poweroff overlay that handles toggling a pin on shutdown (though the [url=https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README]docs[/url] suggest it might be tricky when the pin must be low to poweroff).
-
