Legit upto date Docker image?


#1

Hi

I want to try Mopidy under Docker, and I am looking for a trustable and updated Docker image to give it a try.

Any recommendations?


#2

Hi. I’ve just been thinking the same. There isn’t an official image, as far as I can tell.

I was thinking about making one, but the problem is that everyone’s setup is different, so the amount of config that you can share is minimal. Pretty much something like this:

FROM python:2-jessie

RUN wget -q -O - https://apt.mopidy.com/mopidy.gpg | apt-key add -
RUN wget -q -O /etc/apt/sources.list.d/mopidy.list https://apt.mopidy.com/stretch.list
RUN apt-get update
RUN apt-get -y upgrade
RUN apt-get -y install mopidy

ENTRYPOINT ["mopidy"]

We could make something like that an official Mopidy image, and that would at least mean that people are starting off with the right version of Python, if nothing else.

People could then create a Dockerfile for their specific setup and use FROM mopidy.


#3

I also found this one on Github as an example, but of course it has a load of that person’s personal config, so can’t be reused.


#4

@jjok

I played around couple docker images from the hub but to be honest it was nothing but waste of time :frowning: It seems like most of the time people make it work for themselves and not update their documentation, or their setup is specific to their system that it does not work on any other, or their example commands were from other docket maintainers etc etc.

For instance they keep giving - “$PWD/media:/media:ro” without explaining where their shell is. What is $PWD? It can be any path on a Linux system. That is like the worst commandline example to be honest.

The whole point was to save time but I ended up wasting many hours trying to test couple images. I still cant get local media, install plugins, or even frigging get audio to work :frowning:

Anyway I like your suggestion of making a root official Mopidy image. I am not so technical to get this working. The biggest issue is making it clear and concise especially about how to mount your media and configs, making them editable etc which is where I lost most of my time.


#5

I think the real value in having a Docker setup would be to make it easy to upgrade. Currently it’s a real pain because some things are updated with apt, some things are updated with pip, and you might have some other extensions installed straight from GitHub or somewhere. I never really know if I’m using the latest version of any of my extensions.

With Docker, you’d just need to do a docker build and you get the latest version of everything. I think it’s going to take some real thinking about to come up with a way of doing it that works for everyone.

Maybe some kind of special config file, where you tell it which extensions you want and it knows whether to get them from apt, pip or git:thinking:


#6

I actually stopped testing other people’s half ass explained docker builds and build one myself from scratch using ubuntu:latest. Ubuntu tends to have the codecs better integrated than Debian.

I have everything I needed working, including Pulseaudio, media mounting, cron jobs for scan etc. I am thinking to share it once I am sure it would work for everyone.

It actually would be nice if Mopidy and extensions are built from scratch in the Docker build, but that seems too much of a work for me unless someone gives me proper Dockerfile lines for building it.

@jjok let me know if you want to collab on it to make it even better.

Here is my wishlist

  • Add Rompr (Apache+Mysql+Sqlite) as the main media manager. I find all other Mopidy frontends to be limited. Also some of them seems to integrate analytics which I personally do not enjoy.

  • Build Mopidy/Extensions from ground up

  • Add Webmin for admin panel

  • Snapcast integration


#7

Yeah. That’s exactly the problem. I don’t use any of that stuff, except Snapcast. So that would just be your own personal setup, rather than a general one.

With Docker you usually have one process running per container, so you could have a Snapserver container and a Snapclient container. Those may already exist, I haven’t looked into that yet.


#8

That repo has separate Dockerfiles for Snapcast server and client. Worth giving a go.


#9

I already have a snapcast server running on my desktop. So I wont install snapcast server on it. Given that Mopidy is using gst, it is going to output a fifo file, go integrate through pulse, so no snapclient either there since no pulse is in it.

My approach is to make one media server. I do not want to maintain multiple containers at the moment.


#10

I get where you are coming from with the whole one server vs multiple container, but containers allow to not pollute the host system with multiple dependencies. That being said, all the dockerized version of mopidy I have tried so far have been flaky, to the point where I think there isn’t a build on dockerhub that will satisfy all of us.


#11

Yeah I would not waste time with stuff on Docker site. I made one works for me, if anyone is interested in I can give my docker file for you to take a look.

I want a bit complete stuff so I cna distribute it, I do not want to create interdependencies with containers, that is not my job, I am not running a pipeline here.

Also all those one s I saw did not even get into scanning library in the container, none integrated it. Would not you want to scan your media files regularly? I can see where some people may not have local files, that is fine.


#12

I don’t play local files.


#13

sure, I do only do local :slight_smile: If all you need is online then your setup should as simple as cloning ubuntu from docker and installing Mopidy. I can see that being the base image.