Mopidy stuck without listener


I’ve setup Mopidy in a Docker container:

FROM debian:stretch-slim

RUN apt-get update && apt-get install -y \
    wget \
    gnupg \
 && rm -rf /var/lib/apt/lists/*

RUN wget -q -O - | apt-key add - \
        && wget -q -O /etc/apt/sources.list.d/mopidy.list

RUN apt-get update && apt-get install -y \
    mopidy \
    mopidy-spotify \
    mpc \
 && rm -rf /var/lib/apt/lists/*

EXPOSE 6600 6680

RUN mkdir -p /root/.config/mopidy

CMD ["mopidy"]

I start it by mounting my sound device into the container:

docker run -it --name mopidy --rm -v $PWD/mopidy.conf:/root/.config/mopidy/mopidy.conf --device /dev/snd mopidy 
docker exec mopidy mpc add spotify:artist:URI
docker exec mopidy mpc play

At which point further mpc commands fail by timeout. So I started the container with ‘-vvvv’ option and noticed these lines being spammed over and over again:

DEBUG    2018-12-23 09:18:55,657 [1:Dummy-8] spotify.session
  Audio buffer stats requested, but no listener
DEBUG    2018-12-23 09:18:55,657 [1:Dummy-8] spotify.session
  Music delivery of 2048 frames, 0 consumed

Yesterday I had it working when I also had Mopidy-Moped installed but that was just for testing purposes as I’d rather run it headless once I move it to my Raspberry Pi (currently developing in a Debian Virtualbox).

So I’m wondering if by removing Moped I also removed the last listener and now cannot play music anymore. If this is the case, can I install a different (headless) listener for this to work?

Those debug messages are OK, they are not the issue. And the listener is this sense isn’t anything to do with any frontends or being headless (which refers to not having a display attached and so is independent of having a webclient frontend installed). I wouldn’t like to speculate where the issue is when running docker inside virtualbox - that’s a lot of layers.

If you’re trying to connect to the host IP address using port 6600 or 6680 you’ll need to forward those ports into the container using -p 6680:6680 in the run command.