Sorry in advance for a long post, but I’ve been banging my head against the wall for a good while now, and I’m feeling rather confused.
I’ve been experimenting with Mopidy extension development in the past months, encouraged by the very approachable documentation which made getting started relatively painless. I’ve been mainly experimenting with the Mopidy-Beets extension, since I’m a big fan of beets, and found the Mopidy extension of it a bit lacking.
After getting my initial ideas realized, I wanted to try if I could get the album artwork visible according to the new paradigm. While I was able to get a method going using a virtual environment on my laptop, I’m having a hard time getting anywhere on my “production environment” using Mopidy as a service, even though my earlier fixes translated fine.
In a nutshell, it seems like that if I invoke Mopidy from CLI using
sudo -u mopidy /usr/bin/mopidy --config /etc/mopidy/mopidy.conf, my new method gets invoked expectedly, while when running Mopidy as a service the method does not get invoked under the same operating conditions, even though
sudo service mopidy status lists a very similar sounding command:
└─2543 /usr/bin/python3 /usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf
I’m very puzzled at this point and have been trying many different things to solve the issue. I installed my modified extension via
sudo python3 -m pip install ., and the modified source code is visible in
/usr/local/lib/python3.7/dist-packages/mopidy_beets. At some point I was thinking whether it’s a thing with apt vs pip installed Mopidy, but both
/usr/local/bin/mopidy invoke the method when running from the CLI, and swapping
/usr/local/bin/mopidy in the service file does not change anything. At this point I don’t know whether the problem is in Mopidy as a service using somehow different source code compared to the CLI version resulting in the method not getting invoked, or the modified extension appearing somehow non-modified in the service’d case. It’s weird, because my earlier fixes ran fine even when using service’d Mopidy, and I don’t see why this fix would be any different.
Here’s also partial output from
sudo mopidyctl deps:
Running "/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf deps" as user mopidy Executable: /usr/bin/mopidy Platform: Linux-5.10.103-v7+-armv7l-with-debian-10.13 Python: CPython 3.7.3 from /usr/lib/python3.7 Mopidy: 3.3.0 from /usr/lib/python3/dist-packages Mopidy-Beets: 4.0.1 from /usr/local/lib/python3.7/dist-packages requests: 2.22.0 from /usr/local/lib/python3.7/dist-packages idna: 2.6 from /usr/lib/python3/dist-packages chardet: 3.0.4 from /usr/lib/python3/dist-packages certifi: 2018.8.24 from /usr/lib/python3/dist-packages urllib3: 1.24.1 from /usr/lib/python3/dist-packages setuptools: 40.8.0 from /usr/lib/python3/dist-packages Pykka: 2.0.3 from /usr/lib/python3/dist-packages Mopidy: 3.3.0 from /usr/lib/python3/dist-packages
Looking forward to any fresh insights!