Could someone tell me the difference between running mopidy from the command line and running it as a service? Is it the same program, simply using a different configuration file, or is mopidy installed in two different places?
Hi! Welcome to the exciting world of Mopidy!
First, all of the below applies mostly to Linux and BSD, and to a lesser extent, macOS. I have no idea if mopidy even works properly on Windows and certainly, configuring it as a service is going to be quite different.
For the most part, running mopidy as a service or as a user is the same, the only difference is in how the application is launched. There are some additional differences in what that software is allowed or able to do depending upon whether it’s a service or a user launched application as well, but they’re subtle and have to do with the multi-user nature of linux. If you’re going to use mopidy, you should figure out how you want to run it and stick with that approach. Mixing the two options is not recommended without careful planning.
In general, I think I’d recommend running mopidy as a service. It starts with the system and sends all its logs to the system and requires no intervention by the user once it’s configured properly. It can be beneficial to figure out your configuration by running it locally (as a user-land application, not a service) when initially setting up Mopidy. This approach does require some additional knowledge of how to debug a running service should you run into problems, but for the most part that’s just systemctl and journalctl on most modern linuxes.
I guess another potential reason you might want to run mopidy as a user is if you don’t have full administrative rights on a particular machine, or if you don’t want to mess with system-level python changes (especially on MacOS where it has a funny notion about how it installs python). You might prefer to run a local, user provided version of python rather than the one on your system for safety reasons - I think most of the major package managers like apt (and yum and now dnf) all use the system’s python to maintain the packages in your distribution and modifying that can cause issues.
Hopefully this helps and isn’t totally confusing. I’m happy to expand on anything that doesn’t make sense.
Let us know how you make out with your installation.
Many thanks. After a few false starts I have got mopidy running in userland, apart from some error messages from pykka, but they don’t seem to affect it working.
I am using mopidy-dleyna to stream from the Serviio DLNA server on my desktop.
Nearly ready to switch to mopidy as a service. I guess it’s just a matter of
sudo systemctl enable mopidy
sudo systemctl start mopidy
woo! well done.
you’ll want to copy your mopidy.conf file to /etc/mopidy, creating that directory if you don’t have it first, then run your systemctl commands.
I’m pretty sure the mopidy.service file and user gets created at installation so you should just have to enable it as you’ve said.
good luck!
Hmm. Not quite there!
sudo systemctl status mopidy shows one little problem:
Feb 09 15:50:15 pi3 mopidy[487]: PermissionError: [Errno 13] Permission denied: ‘/var/lib/mopidy/http’
Mopidy is running as user ‘mopidy’, but how to give ‘mopidy’ the correct permissions to that folder?
The Mopidy Debian package should handle all of this for you, did you install Mopidy some other way? All the files and folders in /var/lib/mopidy should already be owned by mopidy:audio. I guess you’ve already done a web search and seen that changing the permissions of a folder and files within can be done with chown
:
sudo chown --recursive mopidy:audio /var/lib/mopidy/http
But like I said, all those files and folders should already have the correct permission so this is odd.
I have to confess I did go through a variety of installation attempts when I couldn’t get things working initially, which would explain my permissions problems. As well as the pip install, I did apt install mopidy, but I think that pulled an older version.
I should really start over and re-install.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.