Open Gadgetoid opened 2 weeks ago
I have pivoted the service to a user service, so you will need to start/stop/status with:
systemctl --user start mopidy
systemctl --user stop mopidy
systemctl --user status mopidy
This allows the user Mopidy session to access the default user pipewire audio sink without any additional configuration fiddling. The downside, aiui, is that you need an active user session.
Config files have also been moved to $HOME/.config/mopidy
, defaults.config
is intended to be a basic functional Mopidy config, and mopidy.config
contains the Pirate Audio customisations.
@Gadgetoid so if an active user session is needed for a user service, does this mean we need to auto log in the user for non-interactive use?
Ok - so it was easier to just make changes and put them in a gist: https://gist.github.com/vinnybad/52aa2339c444000aa3b5e10595a15ad8
Also - I dug a bit and found that these lines were missing in /boot/firmware/config.txt
:
dtoverlay=hifiberry-dac
gpio=25=op,dh
Once I did this and restarted the device (something we should consider adding into the script, or at least adding output asking the user to restart), audio started flowing.
I still see errors like this in the mopidy user service though:
Nov 12 00:14:04 rpiz-music mopidy[616]: WARNING 2024-11-12 00:14:04,050 [616:FileBackend-3 (_actor_loop)] mopidy.file.library
Nov 12 00:14:04 rpiz-music mopidy[616]: Failed looking up file:///home/pi/Music/Compilations/Blah: gst-resource-error-quark: "/home/pi/Music/Compilations/Blah" is a directory. (5)
Not sure what that's about...but it plays 🎉
@vinnybad thanks for an amazingly thorough review on this.
I was also seeing those "blah" "is a directory" errors, looks like a red herring but coincided with my playback not only not working but hanging mopidy 🤦
Do you mind if I grab your changes into a new commit on this branch and set you as the author?
@Gadgetoid so if an active user session is needed for a user service, does this mean we need to auto log in the user for non-interactive use?
Yeah, I'm not super happy about this, but the alternative was making configuration changes to Pipewire that I didn't understand, and which might have knock-on effects. These changes, in fact, absolutely hosed my audio and caused the Mopidy lockups.
I'm very much inclined to believe that the less config we mess with, the better.
Do you mind if I grab your changes into a new commit on this branch and set you as the author? @Gadgetoid sounds good to me.
HI @Gadgetoid , if you want a user to be able to run their "--user" systemctl services without logging in, do:
loginctl enable-linger
⚠️ Note: This branch and install.sh are highly experimental and may do horrible things to your system that I haven't anticipated. Use with care.
⚠️ Because life is short, this script will set Mopidy to run as the user you install with, you should run
./install.sh
and notsudo ./install.sh
With a "mopidy" user configured I would get permissions denied errors trying to start the systemd unit, I couldn't find a workaround to this with a half hour of prodding. If anyone's got some ideas I'm all ears.
I have split out the Pirate Audio specific config using
/usr/share/mopidy/conf.d/pirate-audio.conf
, I'm not actually sure this is working yet!