[Support] knex666 - Mopidy

[knex666 28]

5 hours ago, GooseGoose said:

 

 

and my snapserver post arguments:

snapserver -s pipe:///data/snapfifo-test1?name=Test1&sampleformat=44100:16:2 -s pipe:///data/snapfifo-test2?name=Test2&sampleformat=44100:16:2

 

i have also tried:

snapserver -s pipe:///data/snapfifo-test1?name=Test1&sampleformat=44100:16:2 snapserver -s pipe:///data/snapfifo-test2?name=Test2&sampleformat=44100:16:2

 

but the snapcast player on my phone only seems to pick up the first pipe file. Is this how i should be trying to do multiple streams?

 

I am also getting a weird issue with the second instance of mopidy3 where i click play and the audio works perfectly but it looks like it skips all of the songs on the front end. Do you know what would be causing this? 

 

cheers

 

You cannot use the -s pipe multiple times. just use 2 snapcast container with a different adress.

 

The Issue: Are you running Spotify? I had some troubble with a non valid configuration / authorisation with Spotify that endet like this.

 

Cheers

 

[GooseGoose 1]

11 hours ago, knex666 said:

 

You cannot use the -s pipe multiple times. just use 2 snapcast container with a different adress.

 

The Issue: Are you running Spotify? I had some troubble with a non valid configuration / authorisation with Spotify that endet like this.

 

Cheers

 

ahh cool, thanks! I will try that.

 

nah this is just using the local files, and the same config as the instance that works (with the audio stream changed)

[CellDweller 2]

On 4/14/2020 at 1:46 PM, knex666 said:

What is aadbbd6bbef9 in the config?

You should be fine without spotify etc.

Already know Mopidy, trying to setup this container, and it is a little bit harder than normally. But i saw this commend, en saw i had the same "aadbbd6bbef9" in de config.

 

This originates from github is you copy the mopidy.conf. Easly to be looked over. Can this be fixed for other users?

https://github.com/maschhoff/docker/blob/master/mopidy/mopidy.conf

[knex666 28]

7 hours ago, CellDweller said:

Already know Mopidy, trying to setup this container, and it is a little bit harder than normally. But i saw this commend, en saw i had the same "aadbbd6bbef9" in de config.

 

This originates from github is you copy the mopidy.conf. Easly to be looked over. Can this be fixed for other users?

https://github.com/maschhoff/docker/blob/master/mopidy/mopidy.conf

Thank you very much! I change that file. Dont know where this did come from.

[pinion 4]

I have this setup but it appears it is completely ignoring my config at /mnt/cache/appdata/mopidy/mopidy.conf.

 

When I shell into the container and run mopidy config I see configuration options that aren't in my current config. It's as if it's using a cahced config that you setup.

[knex666 28]

I have this setup but it appears it is completely ignoring my config at /mnt/cache/appdata/mopidy/mopidy.conf.
 
When I shell into the container and run mopidy config I see configuration options that aren't in my current config. It's as if it's using a cahced config that you setup.

Use /mnt/user/appdata that folder is configured to be mounten.

Cheers.

Gesendet von meinem Redmi Note 8 Pro mit Tapatalk

[pinion 4]

I'm sorry, I actually am using that specific folder in my config.

[GooseGoose 1]

On 9/30/2020 at 5:33 AM, pinion said:

I'm sorry, I actually am using that specific folder in my config.

To get it to do a local scan with the config in appdata i had to run:

docker exec -it Mopidy mopidy --config /etc/mopidy.conf local scan

 

Or when I used knex666's mopidy 3 container it picked up the config correctly

[taifleh 0]

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