Mopidy Discourse

Config and initscripts for multiple mopidy servers

I’m a recent convert to Mopidy from long time MPD use for a whole house audio system with multiple sources and multiple floors and rooms. I have an old-school centralized system, with all sources in one place (soundcards in an ubuntu server in the basement) and connected to a sound processor and amplifier that in turn is connected to long speaker runs throughout the house.

Very little seems to have been written about passing audio sources to multiple sinks in the same server, or even running multiple servers. I have decided to do the latter, duplicating /etc/init.d/mopidy and its corresponding /etc/mopidy/mopidy.conf into separate server identities. Each server identity is associated with a unique stereo soundcard output (alsasink) and a unique user (so multiple people can use their own spotify and soundcloud accounts, and maintain their own playlists).

So my question is how much (if any) of the config data and/or resources created /used by the mopidy daemon (e.g. cache_dir, data_dir, debug_file…) can be shared concurrently by multiple mopidy servers? (I’m assuming I should duplicate all resources accessed at runtime.)

…and, of course, please let me know if you know a better way to accomplish what I’m doing.

Thanks for your attention, and for writing this great software!

To clarify, I’ll be running 4 mopidy servers (version 1.1.1) on a single ubuntu server (14.04.3 LTS), named mopidy1al, mopidy1ed, mopidy2al, mopidy2ed. mopidyN* are both assigned to the same alsasink, corresponding to the sound card providing audio to the Nth floor of a house. mopidy*U contain one of the two roommates’ (al and ed) login credentials for soundcloud/spotify/etc. Separate sources per floor is a requirement bc Al and Ed like to have separate listening parties on each floor sometimes.

If multiple outputs per server were supported and runtime changeable, and if multiple (spotify/soundcloud) users were supported and runtime changeable, the above kludgery wouldn’t be necessary. Not to nag, but just to further point out what I’m doing, so someone might better see how to make suggestions for a better way or see something I’ve misunderstood.

Further description of my servers’ configuration and restatement of my question:


  • DESC=“Al’s Downstairs Mopidy music server”
  • NAME=mopidy1al
  • CONFIG_FILES="/usr/share/mopidy/conf.d:/etc/mopidy/mopidy1al.conf"


  • [core] cache_dir = /var/cache/mopidy1al
  • [core] data_dir = /var/lib/mopidy1al
  • [local] data_dir = /var/lib/mopidy1al/local
  • [local] media_dir = /media/raid/audio
  • [logging] config_file = /etc/mopidy1al/logging.conf
  • [logging] debug_file = /var/log/mopidy1al/mopidy-debug.log
  • [http] port = 6680 # (unique port for each server)
  • [http] zeroconf = Al’s Downstairs Mopidy HTTP server on $hostname
  • [m3u] playlists_dir = /var/lib/mopidy1al/playlists
  • [spotify] al’s spotify credentials
  • [soundcloud] al’s soundcloud credentials

mopidy1ed, mopidy2al, mopidy2ed are configured analogously.


  • Is the separation of cache_dir, data_dir, logging conf, playlists_dir required for multiple concurrent servers?
  • Any problems with multiple servers pointing to the same [local] media_dir?
  • Can 2 mopidy servers concurrently pipe audio to the same alsasink? I know gstreamer will allow this, but not sure if I’m missing any setup steps…
  • Other problems you see with my approach?

Thanks again.

Yes, the split is needed at least for some of the dirs. For example, two instances of Mopidy-Spotify/pyspotify/libspotify cannot share the same libspotify cache, which is located in the core/cache_dir.

None at all. The local/media_dir is just read from.

I don’t know, but I would guess so.

No, I think this should work.

One tip to minimize the duplicated configuration is to in the init script set:


That way, you can keep any common configuration in /etc/mopidy/mopidy.conf and only override the configs that varies from server to server in /etc/mopidy/mopidy1al.conf.

I love what you are doing here, OP. I’m in a similar boat of wanting multiple mopidy instances on a single machine.

Question: how do you start multiple instances as a service ?

Can each user access their own instance through the web client ? I’m not seeing how each instance could have its own web interface ???

Each instance is started separately by separate init script, and as jodal says above, each instance requires its own configuration files and dirs for some of the functions (implies we need to do this for cache_dir, data_dir, logging conf, playlists_dir, but mot media_dir bc it’s r/o).

I have dropped this task since I last wrote here, but will soon (next 2 weeks) get back to updating and testing my multi-mopidy-server configuration and will share it with you.

In the meantime, I’m curious to learn more about your setup. I read elsewhere that you are using 2 12-channel amps. I’m curious what amp you’re using.

I think you have more zones than I do, and are planning to use mopidy exclusively for all switching/routing (1 sound card per zone). If (when?) that takes you to a dead-end due to lack of mopidy support for dynamic output selection, might I recommend you consider using a professional audio dsp processor/mixer to separately perform switching/routing/mixing?

For example, I have 7 zones (rooms) in my condo, spanning 3 physical floors. My ubuntu server has 3 sound cards, 1 for each floor (group of zones) which is plenty since zones within a group are not really acoustically isolated. You’d never want to send different sources to different zones on the same floor, bc they bleed into each other and it wouldn’t make sense. I have 3 mpd/mopidy servers, one per floor/group. I use a Biamp Audia in between the ubuntu server and my B&K 12 channel amp. The 3 audio sources from the ubuntu server can be routed to any of the 12 speakers (and do EQ, delay, leveling, metering…) using the Audia’s interface.

The moral of the story is that I would encourage you to simplify wherever possible. Ask yourself whether you really need 12 independent sources for your house. The dsp/processor is of course optional, but if you’re a tinkerer, and have a few hundred bucks and some time to spare, you will get more power and flexibility using a dsp.

As for your questions about users… it is not clear to me what you are trying to accomplish. I’ll assume you’re not talking about permissions or security, and are simply talking about multiple clients accessing the servers. mpd (and mopidy) support concurrent connection to multiple clients. Each server binds to a distinct port, and your clients need to know which port to connect to for the audio source it is trying to control. I, e.g., use ports 6600-6602 for my mpd servers. 6600 is basement, 6601 is first floor, 6602 is 2nd floor.

Picking up this thread, as it seems to be the solution to what I want to achieve. I want different users in the house to listen to their own spotify in whatever rooms they like. So I plan to steer ownership of the room through Home Assistant, want to use snapcast for syncing different rooms / devices - and now I learned I need a Mopidy instance per user, mainly to be able to hook different spotify accounts in.

I am planning to use a RaspPi3b as server that should run n Modipy instances and the Snapserver. Then in each room I have a snapclient hooked to the central server.

First: Is this sane or are there better options?

Second: How do I practically set up multiple Modipys? I assume this can be done through systemd - but I have no clue about the actual doing. If I understand everything correctly, this thread just tells me about the config files, not how to actually run this on the RasPi.

Also any hints to practical guides / best-practices is highly appreciated! Thanks in advance!