Yes, it requires a paid account.
Thanks for your effort!
The problem now disappeared by itself again, without me doing anything. That’s really strange
Oh. Dear. I really have no idea since I haven’t done any librespot development which, I believe, we’re getting from : GitHub - sailfish-spotify/librespot: Open Source Spotify client library ?
If that is the case, since it’s quite old and far behind upstream, I’d say it probably has a few bugs and it’s nigh on a miracle that it works at all. Sigh. There is a spotifyd daemon variant that might be easier to install (systemd unit) but I don’t have the time for it. For reference, as a user service, Running as systemd service - Spotifyd
I don’t think that the problem is with Librespot, because I tried it with this version you mentioned and with the newest version from GitHub - librespot-org/librespot: Open Source Spotify client library (which I built myself) and the same thing happened.
Ah, cool. Knowing that it’s not a library issue helps. I’ll have a look at how hutspot identifies itself. But it could be that it’s just storing the last known device which would be why you would see it even if librespot is not running. That’s what I’d do, pre-populate the list with last known devices.
Just to see I get it right, You have:
- Show devices page at startup
- Control Librespot on
- Enable Device Discovery on
It can be a simple network lag with discovery timing out, for instance, before librespot is up. But you’ve also tried librespot starting from CLI, right?
One question. You are letting hutspot start and stop librespot, correct?
It doesn’t matter if i start librespot from Terminal or via Hutspot, I’ve tried both. I also have all these options turned on. And when it works, everything works perfectly, but sometimes it doesn’t. And when it doesn’t work, it shows librespot running, but you can’t set it as active.
Yes, I let hutspot start and stop librespot.
Ok, thanks, that helps debug.
Ok, cool. Two persons with same settings does aid in debugging 
1 Like
If I can provied any further infos, just let me know. I also don’t hesitate to test anything for you
1 Like
Thank you for the idea nephros! In fresh sailfish install 4.5.0.21 I installed AllRadio and when I run it I got a white screen. When I started it from command line I got an error to which brought me here and after I installed mpris-qt5-qml-plugin ( pkcon install mpris-qt5-qml-plugin ) everything worked as expected
With the new rust version in community OBS I’m trying to build a newer librespot.
The build is not yet “reproducible” to be published to chum because the build might lock from time to time (investigating)…
Details from post 3 are:
The build I’ve come to is from librespot-git and it’s output in e.g. Index of /obs/home:/b100dian:/rust-packages/sailfish_latest_aarch64/aarch64 is librespot-0.4.2+master.20240716132332.6b78169-1.17.1.jolla.aarch64.rpm which is from 16-Jul-2024 (or a later one) not the 15-Jul one which is from librespot project.
The main novelty of the -git build is defaultuser instead of nemo and pulseaudio volume control.
Also this is version 0.4.2 of librespot. Not sure what version was before, but it was from 2019.
Also, “works on my phone” after I think some back and forth with credentials cache I can’t remember (I am sure I have removed Sailjail from hutspot though)
1 Like
Nice to hear!
But I wonder, what problems you have? Because I was able to build Librespot 0.4.2 with Cargo on device perfectly fine.
Are your problems only related to Chum/packaging?
Ah, I was focused on re-using the bits from the 2019 rpm/spec packages that I temporarily forgot you actually built on the device pretty recently. You’re right, it’s the same version as that. It just includes the systemd and pulseaudio policy files.
The problems on OBS are strictly related to virtualization. One is rust linking wrongfully with some x86 libs (solved) and another one is some race that sometimes locks up the build (linked in the previous post is a thread I started about this)
Out of curiosity does volume control work on your build? Because it didnt work out of the box for me so I changed the systemd env a bit.
If you build the official Librespot ( GitHub - librespot-org/librespot: Open Source Spotify client library ) from source with cargo, you don’t get any systemd-related stuff, just Librespot. Volume control works but only with the slider in Hutspot, not with the buttons of the device (but I assume this is normal)
By the way, you can also do cargo install librespot and it will work
Which reminds me of another difference: the cargo build needs to work offline in OBS:-D
@vlagged let me know if you get so far as to replace the hutspot I patched together. I don’t use spotify, so it’s difficult for me to do dev for that app. I’ve added you as maintainer for hutspot in chum testing so you could take over if you have the muse!
I cannot really help with the Rust-Stuff, but if you need someone who uses Spotify to test something, I’m always here to help