I am running Arch with Gnome 3.22.1 and just installed Mopidy with the intention to listen to my Spotify lib.
I can run Mopidy fine as my user or system service. I can also easily connect to Spotify. Everything works as far as listening to music goes.
However, I also wanted to control Mopidy through the MPRIS interface. I installed the extension as is from the AUR package, but it did not work. I keep getting the following error:
WARNING MPRIS frontend setup failed (org.freedesktop.DBus.Error.NotSupported: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead)
I am running Gnome in X11, not Wayland, in case enyone is wondering. I have checked and the DBUS_SESSION_BUS_ADDRESS is correctly set. It is configured by Systemd by default. The service depends on dbus.service and runs as the mopidy user which also has this variable. I do not see anything wrong with my config. I have plenty of other services that use D-BUS and they all seem to work fine.
Do you get the error when running Mopidy as your user? Is it possible that the Mopidy service (running as user mopidy) doesn’t have access to your (user) session dbus?
I just tried running as user. If run as user the MPRIS extension works. How do I make it work as a service then? The default config seems to not handle it.
This is Ubuntu specific I think, as I do not have such a Systemd service. In any case, I have tried a few other fixes exactly along this line of thought and nothing has worked.
Hm, I’m not sure how you can send dbus messages between different users.
Did you check that your user has this, or that the mopidy service has this as well. For me, I have this set when logged in as a user, but it is not set for mopidy when running that as a systemd service.
I tried setting it for mopidy explicitly, but then I get a permission error:
Failed to connect to bus: org.freedesktop.DBus.Error.AccessDenied: Failed to connect to socket /run/user/1000/bus: Permission denied
I don’t know if you can allow this in some way or do some kind of authentication.
But what I think should work is running mopidy as a user service instead of a system service. Then mopidy would be run as your own user, and should have permission.
I have thought about if we should include a user service, so it would be easier to run it this way. One problem with the user service is if multiple users are trying to use the service with the same port. But since it’s useful for single-user machines, and you can configure the port to be other than the default, it should be much of a problem. We should still include the system service either way.
I think the mopidy user does not have the bus address set, because it is a nologin user. Otherwise, all other login users have the same DBUS as far as I can tell.
I agree that a user service would solve this problem. Could post an example here so that I can test?
Here is a minimal example. Not sure if you should have more (like specifying dependencies), but this should work for testing at least.
[Unit]
Description=Mopidy music server
[Service]
ExecStart=/usr/bin/mopidy
[Install]
WantedBy=default.target
Note that it will use the config from ~/.config/mopidy/mopidy.conf instead of from /etc/mopidy/mopidy.conf. You could specify the etc config file, but that wouldn’t really make sense for a user config.
Put the content in ~/.config/systemd/user/mopidy.service and run systemctl --user start mopidy.
This works. Should we also include the proper dependencies? I’m not sure which ones apply specifically to the user service.
Also, to be honest, I think I would much prefer a user service for my personal machine. This would also help users that listen to music on company/managed machines - they can have a service that would respect personal config without needing to modify system files.
I was wondering - can I leave the user service enabled? My concern is battery life and stability in case no internet connection. Does mopidy handle this gracefully when run as a background service?