Installation problem, Debian, LocalBackend caused an exception

[ausserirdischesindge]

Hi!
Long time mpd user, wanted to try out Mopidy, but no luck (tried it on two different machines), probably I am doing something wrong.

Mar  4 11:18:14 pix mopidy[416285]: INFO     [MpdSession-11] mopidy_mpd.session New MPD connection from [::1]:56182
Mar  4 11:18:14 pix mopidy[416285]: ERROR    [Core-7] mopidy.core.library LocalBackend backend caused an exception.
Mar  4 11:18:14 pix mopidy[416285]: Traceback (most recent call last):
Mar  4 11:18:14 pix mopidy[416285]:   File "/usr/lib/python3/dist-packages/mopidy/core/library.py", line 17, in _backend_error_handling
Mar  4 11:18:14 pix mopidy[416285]:     yield
Mar  4 11:18:14 pix mopidy[416285]:   File "/usr/lib/python3/dist-packages/mopidy/core/library.py", line 146, in get_distinct
Mar  4 11:18:14 pix mopidy[416285]:     values = future.get()
Mar  4 11:18:14 pix mopidy[416285]:   File "/usr/lib/python3/dist-packages/pykka/_threading.py", line 45, in get
Mar  4 11:18:14 pix mopidy[416285]:     _compat.reraise(*self._data['exc_info'])
Mar  4 11:18:14 pix mopidy[416285]:   File "/usr/lib/python3/dist-packages/pykka/_compat/__init__.py", line 29, in reraise
Mar  4 11:18:14 pix mopidy[416285]:     raise value
Mar  4 11:18:14 pix mopidy[416285]:   File "/usr/lib/python3/dist-packages/pykka/_actor.py", line 193, in _actor_loop
Mar  4 11:18:14 pix mopidy[416285]:     response = self._handle_receive(envelope.message)
Mar  4 11:18:14 pix mopidy[416285]:   File "/usr/lib/python3/dist-packages/pykka/_actor.py", line 299, in _handle_receive
Mar  4 11:18:14 pix mopidy[416285]:     return callee(*message.args, **message.kwargs)
Mar  4 11:18:14 pix mopidy[416285]:   File "/usr/lib/python3/dist-packages/mopidy_local/library.py", line 108, in get_distinct
Mar  4 11:18:14 pix mopidy[416285]:     return set(schema.list_distinct(self._connect(), compat_field, q))
Mar  4 11:18:14 pix mopidy[416285]:   File "/usr/lib/python3/dist-packages/mopidy_local/schema.py", line 230, in list_distinct
Mar  4 11:18:14 pix mopidy[416285]:     return list(map(operator.itemgetter(0), c.execute(sql, params)))
Mar  4 11:18:14 pix mopidy[416285]: sqlite3.OperationalError: no such table: search

I installed Debian Packages (tried various versions), now:

||/ Name           Version      Architecture Description
+++-==============-============-============-================================================================
ii  mopidy         3.2.0-1      all          extensible music server
ii  mopidy-doc     3.2.0-1      all          extensible music server - documentation
ii  mopidy-local   3.2.0-1      all          Mopidy extension for playing music from your local music archive
ii  mopidy-mpd     3.1.0-1      all          Mopidy extension for controlling Mopidy from MPD clients

but trying older (or upstream versions) did not help either. Probably some configuration snafu I consistently reproduce

mopidy.conf is

[local]
enabled = true
media_dir = /audio

[mpd]
enabled = true
hostname = ::

Any idea how to investigate further? Any ideas?

Thanks in advance,
Ralph

[kingosticks]

Did you do a local scan?

[ausserirdischesindge]

Yes, I did. Upon trying again, I noticed that the configuration file /etc/mopidy/mopidy.conf was not really picked up, some kind of user/session based vs. system wide misconfiguration or permission problem or something.

I think, I have it playing now, but now I am fighting to get it to talk to snapcast’s fifo

[kingosticks]

How you run Mopidy impacts what configuration file is used. This is explained at Running — Mopidy 3.2.0-5-gc36524a0 documentation

A fifo is not the only way to integrate with snapcast and the other methods (tcp and alsa) are reportedly more reliable. See snapcast/configuration.md at master · badaix/snapcast · GitHub

[ausserirdischesindge]

Thanks, I got it to run. It was a systemctl setting: sysctl fs.protected_fifos=0
that did it for me. The fifo in /tmp cannot be written to, even if permissions should work in principle, if this is not set (group permissions are basically ignored). At least on my machine.

The different ways to run mopidy were a bit unintuitive to me.

[kingosticks]

Any improvement to that documentation is very welcome. I literally cannot think how to make it clearer but that’s probably because I’m too familiar with the process.

[ausserirdischesindge]

I do not fault your documentation, once I realized what was going on, everything was quite clear, really. I do think the documentation of the debian packages could be improved, or maybe after decades of installing stuff in Debian I am a bit spoiled.

I did expect the Debian package to ask me debconf questions about the different and de facto incompatible ways to install mopidy. It did not occur to me that running it in a session made sense (to me mpd and similar tools are headless daemon services running somewhere I certainly do not want to log in), of course other people probably see it differently, and nothing is wrong with that. Maybe I was not attentive, and klicked it away, but I think this debconf question did not appear at all unless requested manually (just like you describe in your docs).

I did look for a README.Debian or similar, explaining to me, why the config file in /etc/mopidy was not senisbly picked up.

In the end your docs describe exactly what is going on, I just looked at the wrong place (Debian /usr/share/doc, etc.).

I might have to add, that having this hodge podge of various tutorials (how to integrate mopidy with homeassistant, how to integrate mopidy with snapcast, tutorials on integrating all three, having the music archve on a vanilla debian machine, docs on that etc.) certainly did not help. Probably if I had read mopidy and snapcast documentation completely beforehand would have helped.

Thanks for this great software, together with the snapcast multi room backend and homeassistant it really renewed my interest in Linux music software. I have lots of fun thinking of displays littered around the house showing the current playing track, light switches skipping to the next title etc.

[kingosticks]

@ausserirdischesindge

I did expect the Debian package to ask me debconf questions about the different and de facto incompatible ways to install mopidy

Not sure I follow. The way the Debian package is installed should work fine regardless of if you run Mopidy as a headless service (the usual way) or if you run it as a regular user program. There shouldn’t be any compatiblity issue. Can you expand what you mean so we can improve this?

@ausserirdischesindge

I might have to add, that having this hodge podge of various tutorials (how to integrate mopidy with homeassistant, how to integrate mopidy with snapcast, tutorials on integrating all three, having the music archve on a vanilla debian machine, docs on that etc.) certainly did not help. Probably if I had read mopidy and snapcast documentation completely beforehand would have helped.

Yes! Lots of people get into this situation. At the top of all these tutorials if they could just say something like

I wrote this tutorial on my own and it seemd to work. I’ve no idea if anything I have written is actually correct. It’s also probably out of date. Go read the official docs and check!

But then these tutorials and articles do help people find the project in the first place so it’s a double-edge sword.

[ausserirdischesindge]

@kingosticks

Not sure I follow. The way the Debian package is installed should work fine regardless of if you run Mopidy as a headless service (the usual way) or if you run it as a regular user program. There shouldn’t be any compatiblity issue. Can you expand what you mean so we can improve this?

Well I installed it, by just doing a “apt install mopidy” (or something), without getting any errors. Then I (based on my previous being used to mpd and because of various tutorials) wanted to configure my library and have the directory scanned, I did a “mopidy local scan” instead of a “mopidyctl local scan” and there it seems permission problems hit me (scanning the directory as root?) and not getting /etc/mopidy/mopidy.conf being used also hit me Stuff did not work, and I got weird python stack traces.

To me getting the error message from my first posting here is kind of an incompatibility. Yes, if you did the same thing to e.g. an smtp server, it probably would fail in a similar way, but then with most smtp servers there is only one way (systemwide as a daemon) to run them and various wrapper scripts take care about the user not stomping about permissions in a stupid way Yes, of course, you can call this user stupidity, not “two incompatible ways to use the software” and of course you are right. Basically what I am saying is: Why am I not presented with the “dpkg-reconfigure mopidy” debconfig question upon installation, why do I have to find out about it by getting errors?

Now I understand the hard place you are in, in respect to documenting and preconfiguring. Software like mopidy is underlying plumbing, that has lots of moving parts and flexibility, and there is really not “one right way” to use it, and taking away flexibility is not an option at all. Everybody comes from a different starting point. I would probably still be running mpd, if it were not for the home assistant integration, that just works for mopidy, not for mpd. Others probably could not care less about the way I run this software and are not interested in homeassistant at all (but Volumio-like setups or whatever).

So sorry for my verbose ramblings, I don’t know what to suggest either, except maybe for item b) but I will try to

a) get the Debian packager to maybe document slightly more prominently that mopidy can be run both as a system service or a user process (and you really have to decide about that or acknowledge this so you do not botch permissions).

b) get it somewhere into documentation that if you want to run the mopidy+snapcast combo, and want to use a fifo (don’t know if this is preferable, but it is what most documentation suggests it that way, some documentation says it gives less latency than tcp) that you have to do the fs.protected_fifos = 0 setting in /etc/sysctl.conf on modern(?) kernels.

c) Try to get the dead links on Snapcast | snapcast fixed
(like https://mjaggard.github.io/snapcast/doc/player_setup.md#mpd ). Not your problem at all, but small things like this make you go nuts, when you feel a bit lost in installing software anyway,

I’ve also found another problem in my setup, but I will start a seperate posting for this, my ramblings are already more incoherent than they should be.

Again thanks for your patience!
Ralph

[kingosticks]

@ausserirdischesindge

mopidyctl local scan

When interacting with the service via mopidyctl it needs to be sudo mopidyctl. Or did you just omit that here for brevity?

EDIT: ohhhh, you did sudo mopidy local scan. Right, now I am with you. Yes, permission fun will follow there. We can’t really stop people from running mopidy as root. Maybe we could enforce that a config file is always explicitly specified when running mopidy as root user.

[kingosticks]

@ausserirdischesindge

c) Try to get the dead links on Snapcast | snapcast fixed

I’d go one step further with this one and ask for it to be taken down. It’s actually an out of date fork of the real repo! You should be looking at GitHub - badaix/snapcast: Synchronous multiroom audio player

@ausserirdischesindge

b) get it somewhere into documentation that if you want to run the mopidy+snapcast combo, and want to use a fifo (don’t know if this is preferable, but it is what most documentation suggests it that way, some documentation says it gives less latency than tcp) that you have to do the fs.protected_fifos = 0 setting in /etc/sysctl.conf on modern(?) kernels.

Yes, I think we need to add a snapcast section to go alongside icecast etc in our “Advanced Setups” documentation. It’s kind of annoying keeping that stuff up date since it’s not our software.

I’m still not sure what more to do about a). if you read the Install documentation you can easily follow through to the Running documentation, it is explicitly linked. I guess we could add that the service is the preferred option for most. And put it first.