Hi knex666
I’m a fairly experienced user, but I still had trouble getting this to work. This post has gotten longer than I intended it to, but I think we both can learn something from it.
I will list the problems I experienced, when I set up this container.
In the Unraid setup the description of the field “config“ is misleading, because the path is actually mounted to (container: /etc/mopidy.conf) instead of (container: /mopidy.conf)
The path that is mentioned in the field “config“ now is (container: /mopidy.conf), which, in the container, is a directory. If that’s intended, you should call it "/mopidy.conf.d"
Running `ps aux` in the container reveals that Mopidy is run with two config files. These are (container: /etc/mopidy.conf) and (container: /mopidy.conf), which, again, is a directory. I'm not sure if that really works, but if it does, see point above.
The description of the field “Host Path 2“ is also misleading, because the path is mounted to a directory (container: /tmp/) instead of (container: /tmp/snapfifo)
mounting the FIFO for Snapcast on a share results in an open file handle on the spinning hard drives, if appdata is located on one. In consequence, they won’t be able to be spun down. If appdata is located on an SSD-cache, then the SSD will be worn out, because of data being written to it continuously. The appropriate place to mount a FIFO is /tmp, which should result in a FIFO in ram.
I set the Host path to (host: /tmp/snapcast/) for this container and for the Snapcast container
Then, if i try to set Snapcast to enabled in the Iris-UI, it tells me that i have to modify the config file, maybe you could hint at this in the XML:
Snapcast has to be enabled as an option to iris.
Or you just set it to enabled in the image. As long as no host and port are set, one can still disable Snapcast from UI.
[iris]
snapcast_enabled = true
Running the library scan from iris-ui fails, because some script there seems to be depending on sudo, which isn’t installed in this container-image
Running the library scan from within the container `mopidy --config /etc/mopidy.conf local scan` scans my library fine, but none of the frontends care.
The default library for this plugin is a JSON file, that isn’t persisted. The File is only read on start of Mopidy.
Let’s use [local] library = sqlite, so library updates are reflected immediately
Since the images default config sets local-sqlite as active anyway, i don’t see a reason not to make this a default too
Of course, that sqlite DB isn’t mounted to any unraid share, so all changes are dropped, when mopidy restarts.
mount (container: /var/lib/mopidy/.local/share/mopidy/local-sqlite/) to /mnt/user/appdata/mopidy/sqlite/ and finally the local db works
oh but then, of course, something always seems to be deleting the sqlite database, when redeploying the container from unraid.
That really isn’t so bad, if the collection is small enough, but for big collections it could be bothersome.
MPD plugin is set to listen to 127.0.0.1 only per default. i think it should be set to 0.0.0.0 per default. One can still choose not to expose the port within docker.
Regarding Snapcast docker:
snapcast-docker always throws these two errors when starting:
2020-12-22 10-16-58 [Err] Error reading config: [json.exception.parse_error.101] parse error at 1: syntax error - unexpected end of input; expected '[', '{', or a literal
2020-12-22 10-16-58 [Err] Failed to create client: Daemon not running
While debugging all this, i also noticed that there are some old logs left over from before image creation. You might wanna get rid of these.
root@9cedf0bbf4a4:/# ls -l /var/log/mopidy/
total 24
-rw-r--r-- 1 root root 21987 Feb 25 2019 mopidy.log