Music Player Daemon

Related articles
/Tips and tricks
/Troubleshooting
Music Player Daemon
(MPD) is an audio player that has a server-client architecture.
MPD
plays audio files, organizes playlists and maintains a music database, all while using  very few resources. In order to interface with it, a separate
client
is needed.
mopidy
is an alternative to MPD written in
Python
. It is not a complete MPD replacement—its advantage is that it has plug-ins for playing music from cloud services like Spotify, SoundCloud, and Google Play Music.
Installation
Install
the
mpd
package.
Configuration
MPD is able to run in
#Per-user configuration
or
#System-wide configuration
mode (settings apply to all users). Also it is possible to run multiple instances of MPD in a
#Multi-MPD setup
.
The way of setting up MPD depends on the way it is intended to be used: a local per-user configuration is easier to set up and may prove more adapted on a desktop system. The system-wide setup might be better suited for a always-on audio server with multiple users but a shared MPD instance.
In order for MPD to be able to playback audio,
ALSA
, optionally with
PulseAudio
or
PipeWire
, must be set up and working. The
#Audio configuration
section thereafter describes the parameters needed for
ALSA
,
PulseAudio
or
PipeWire
.
MPD is configured in the file
mpd.conf(5)
which can be located in various paths depending on the setup chosen (system-wide or per-user). In short, the two common locations used are:
~/.config/mpd/mpd.conf
in per-user configuration mode, this is the first location searched,
/etc/mpd.conf
in system-wide configuration.
These are some of the most commonly used configuration options:
pid_file
-  The file where MPD stores its process ID
db_file
- The music database
state_file
- MPD's current state is noted here
playlist_directory
- The directory where playlists are saved into
music_directory
- The directory that MPD scans for music
sticker_file
- The sticker database
Per-user configuration
MPD can be configured per-user. Running it as a normal user has the benefits of:
Regrouping into one single directory
~/.config/mpd/
(or any other directory under
$HOME
) all the MPD configuration files.
Avoiding unforeseen directory and file permission errors.
Configure the location of files and directories
In user mode, the configuration is read from
$XDG_CONFIG_HOME/mpd/mpd.conf
.
We will assume here
$XDG_CONFIG_HOME
equals the
default
of
~/.config
.
To build the user configuration, the
MPD configuration example
included in the package is a good starting point, copy it using the following lines:
$ mkdir -p ~/.config/mpd
$ cp /usr/share/doc/mpd/mpdconf.example ~/.config/mpd/mpd.conf
A good practice is to use this newly created
~/.config/mpd/
directory to store, together with the configuration file, other MPD related files like the database or the playlists. The user must have read write access to this directory.
Then edit the configuration file in order to specify the required and optional files and directories:
~/.config/mpd/mpd.conf
# Recommended location for database
db_file            "~/.config/mpd/database"

# If running mpd using systemd, delete this line to log directly to systemd.
log_file           "syslog"

# The music directory is by default the XDG directory, uncomment to amend and choose a different directory
#music_directory    "~/music"

# Uncomment to refresh the database whenever files in the music_directory are changed
#auto_update "yes"

# Uncomment to enable the functionalities
#playlist_directory "~/.config/mpd/playlists"
#pid_file           "~/.config/mpd/pid"
#state_file         "~/.local/state/mpd/state"
#sticker_file       "~/.config/mpd/sticker.sql"
If playlists are enabled in the configuration, the specified playlist directory must be created:
$ mkdir ~/.config/mpd/playlists
If
state_file
is set, the specified directory must be created:
$ mkdir -p ~/.local/state/mpd
MPD can now be started (an optional custom location for the configuration file can be specified):
$ mpd
[config_file]
In order to build the database file, MPD must scan into the
music_directory
defined above. To request this task, one of the MPD
clients
must be used. For example with
mpc
the command is:
$ mpc update
or alternatively one can set the option
auto_update
to
"yes"
in the configuration to refresh the database whenever files are changed in
music_directory
.
Audio configuration
By default, no audio outputs are configured, which leads MPD to perform auto-detection using
ALSA
. However, it is possible to configure outputs manually; MPD even supports the ability to emit to more than one at once.
All audio outputs accept a
name
setting, which is displayed by MPD clients in output control dialogs. (
Full list of common settings
)
The exact
ALSA
device can be indicated with the
device
option; devices can be listed using
aplay --list-pcm
from the package
alsa-utils
. (
Full list of ALSA-specific settings
)
~/.config/mpd/mpd.conf
audio_output {
        type          "alsa"
        name          "
ALSA sound card
"
        # Optional
        #device        "
iec958:CARD=Intel,DEV=0
"
        #mixer_control "PCM"
}
The following configures a
PulseAudio
output (
list of specific settings
). Sink identifiers can be obtained with
pactl list short sinks
.
~/.config/mpd/mpd.conf
audio_output {
        type            "pulse"
        name            "
PulseAudio output
"
        # Optional
        #sink            "
alsa_output.pci-0000_c1_00.6.analog-stereo
"
}
The following configures a
PipeWire
output (
list of specific settings
). Target identifiers can be obtained with
pw-cli ls Node
as the
node.name
property; audio outputs can be identified by the
media.class = "Audio/Sink"
property (or obtained via
pactl list short sinks
, if available).
~/.config/mpd/mpd.conf
audio_output {
        type            "pipewire"
        name            "
PipeWire output
"
        # Optional
        #target          "
bluez_output.F4_9D_8A_B4_8D_37.1
"
}
Note
It may not be possible to change which output MPD is emitting to via tools like
pavucontrol
unless
some
target is specified.
Listen on Unix domain socket
Running MPD on an IPC socket instead of the network stack can be advantageous for performance and security if MPD is going to be used locally only.
To do this, set the bind_to_address to either a variable or an absolute path. MPD will fail when using a relative path.
~/.config/mpd/mpd.conf
bind_to_address "$XDG_RUNTIME_DIR/mpd/socket"
Then export the environment variable
MPD_HOST="$XDG_RUNTIME_DIR/mpd/socket"
Autostart with systemd
The
mpd
package provides a
user service
file. The service starts the process as user, there is no need to change permission nor use the
user
and
group
variables in the MPD configuration file.
Start/enable
the user unit
mpd.service
(i.e. with the
--user
flag).
Note
The configuration file is read from
~/.config/mpd/mpd.conf
, see
systemd#Editing provided units
if you would like to indicate a custom configuration file path.
Autostart on tty login
To start MPD on login add the following to
~/.profile
or another
autostart file
:
# MPD daemon start (if no other user instance exists)
[ ! -s ~/.config/mpd/pid ] && mpd
Scripted configuration
The
mpd-configure
tool creates a MPD configuration optimized for
bit perfect
audio playback, without any resampling or conversion, using the ALSA interface hardware address (hw:x,y).
System-wide configuration
Note
Users of PulseAudio with a system-wide MPD configuration have to implement a
workaround
in order to run MPD as its own user!
The default
/etc/mpd.conf
keeps the setup in
/var/lib/mpd
which is assigned to user as well as primary group MPD.
Music directory
The music directory is defined by the option
music_directory
in the configuration file
/etc/mpd.conf
.
MPD needs to have execute permission on
all
parent directories of the music collection and also read access to all directories containing music files. This may conflict with the default configuration of the user directory, like
~/Music
, where the music is stored.
While there are several solutions to this issue, one of these should be most practical:
Switch to the
#Per-user configuration
mode instead
Add the
mpd
user to the user's group and grant group execute permission to the user directory. This way the
mpd
user has permission to open the user directory:
# gpasswd -a mpd
user_group_name
$ chmod 710 /home/
user_directory
Store the music collection in a different path, either:
by moving it entirely,
with a bind mount,
or with
Btrfs#Subvolumes
(you should make this change persistent with an entry to
/etc/fstab
).
The MPD configuration file must define only one music directory. If the music collection is contained under multiple directories, create symbolic links under the main music directory in
/var/lib/mpd
. Remember to set permissions accordingly on the directories being linked.
To exclude a file - or files - from the update, create a file called
.mpdignore
in its parent directory. Each line of that file may contain a list of shell wildcards. Matching files in the current directory and all subdirectories are then excluded from subsequent updates.
Note
MPD is capable of reading music files within some archive file formats, and will add those during an update if they are in the music directory; tar is known to be an exception.
Start with systemd
MPD can be controlled with
mpd.service
using systemd
. The first startup can take some time as MPD will scan your music directory.
Test everything by starting a client application (
ncmpc
is a light and easy to use client), and play some music!
Socket activation
mpd
provides a
mpd.socket
unit. If
mpd.socket
is enabled (and
mpd.service
is disabled), systemd will not start MPD immediately, it will just listen to the appropriate sockets. Then, whenever an MPD client attempts to connect to one of these sockets, systemd will start
mpd.service
and transparently hand over control of these ports to the MPD process.
If you prefer to listen to different UNIX sockets or network ports (even multiple sockets of each type), or if you prefer not to listen to network ports at all,
edit
the
mpd.socket
unit appropriately
and
modify
/etc/mpd.conf
to match the configuration (see
mpd.conf(5)
for details).
User id startup workflow
MPD should never run as
root
; you may use the
user
option in the configuration to make MPD change its user id after initialization. Do not use this option if you start MPD as an unprivileged user.
To describe how MPD drops its superuser privileges and switch to those of the user set in the configuration, the steps of a normal MPD startup are listed thereafter:
Since MPD is started as
root
by systemd, it first reads the
/etc/mpd.conf
file.
MPD reads the
user
variable in the configuration, and changes from
root
to this user.
MPD then reads the rest of the configuration file and configures itself accordingly. Uses of
~
in the configuration file points to the home user's directory, and not root's directory.
Multi-MPD setup
Running an Icecast server
For a second MPD (e.g. with
Icecast
output to share music over the network) using the same music and playlist as the one above, simply copy the above configuration file and make a new file (e.g.,
/home/username/.mpd/config-icecast
), and only change the
log_file
,
error_file
,
pid_file
, and
state_file
parameters (e.g.
mpd-icecast.log
,
mpd-icecast.error
, and so on). Using the same directory paths for the music and playlist directories would ensure that this second MPD uses the same music collection as the first one, e.g. creating and editing a playlist under the first daemon would affect the second daemon as well. Users do not have to create the same playlists all over again for the second daemon. Call this second daemon the same way from
~/.xinitrc
above - but be sure to have a different port number, avoiding a conflict with the first MPD daemon.
Satellite setup
The method described in
#Running an Icecast server
works, but at least in theory could lead to issues with the database, when both MPD instances try to write to the same database file concurrently. MPD has a
satellite mode
where one instance can receive the database from an already running MPD instance.
In your
config-icecast
add this, where host and port reflect your primary MPD server:
database {
    plugin "proxy"
    host "localhost"
    port "6600"
}
Clients
A separate client is needed to control MPD. See a long list of clients at the
mpd website
. Popular options are:
Command-line
mpc
— Command line user interface for MPD server written in C.
https://www.musicpd.org/clients/mpc/
||
mpc
Console
clerk
— MPD client using
Rofi
.
https://github.com/carnager/clerk
||
clerk-git
AUR
gomp
— MPD client inspired by ncmpcpp with builtin cover-art view and LastFM integration.
https://github.com/aditya-K2/gomp
||
gomp-git
AUR
inori
— MPD client with a folding library view and effective searching.
https://github.com/eshrh/inori
||
inori
AUR
mmtc
— Minimal mpd terminal client that aims to be simple yet highly configurable.
https://github.com/figsoda/mmtc
||
mmtc
AUR
ncmpc
— Ncurses client for MPD written in C++.
https://www.musicpd.org/clients/ncmpc/
||
ncmpc
ncmpcpp
— Almost exact clone of
ncmpc
, written in C++ with some additional features (tag editor, search engine).
https://rybczak.net/ncmpcpp/
||
ncmpcpp
ncmpy
— Curses-based MPD client written in Python.
https://repo.cykerway.com/ncmpy
||
ncmpy
AUR
nncmpp
— Yet another MPD client. It is in effect a simplified TUI version of Sonata.
https://git.janouch.name/p/nncmpp/
||
nncmpp-git
AUR
pms
— Highly configurable and accessible ncurses client written in Go.
https://github.com/kimtore/pms
||
pmus-git
AUR
rmpc
— A configurable MPD client inspired by ncmpcpp and ranger with album art support via various graphics protocols.
https://rmpc.mierak.dev/
||
rmpc
vimpc
— Ncurses based MPD client with vi-like key bindings.
https://github.com/boysetsfrog/vimpc
||
vimpc-git
AUR
Graphical
Ario
— Very feature-rich GTK3 GUI client for MPD, inspired by
Rhythmbox
.
https://ario-player.sourceforge.net/
||
ario
Cantata
— Unmaintained high-feature, Qt5 client for MPD with very configurable interface.
https://github.com/CDrummond/cantata
||
cantata
AUR
CoverGrid
— GTK3 GUI client focusing on albums instead of single tracks.
https://www.suruatoel.xyz/codes/mcg
||
mcg
AUR
Euphonica
— Libadwaita MPD client with visualiser, wikis and synced lyrics.
https://github.com/htkhiem/euphonica
||
euphonica-git
AUR
MPD Plasma Widget
— Plasmoid for the
KDE Plasma desktop
.
https://store.kde.org/p/2258843
|| Install via the Plasma DE build-in widget store.
myMPD
— Standalone and mobile friendly web-based MPD client with a tiny footprint and advanced features.
https://github.com/jcorporation/myMPD
||
mympd
Plattenalbum
— A modern and small GTK4 MPD client written in python.
https://github.com/SoongNoonien/plattenalbum
||
plattenalbum
AUR
QMPDClient
— Qt5 GUI client.
https://bitcheese.net/QMPDClient/
||
qmpdclient
AUR
Quimup
— Simple Qt5 frontend for MPD written in C++.
https://sourceforge.net/projects/quimup/
||
quimup
AUR
RompЯ
— Web client for MPD.
https://fatg3erman.github.io/RompR/
||
rompr
AUR
SkyMPC
— Simple MPD client, powered by Qt5.
https://github.com/soramimi/SkyMPC
||
skympc-git
AUR
Sonata
— Elegant Python GTK client.
https://www.nongnu.org/sonata/
||
sonata-git
AUR
Xfce MPD Panel Plugin
— MPD plugin for
Xfce
4 panel.
https://goodies.xfce.org/projects/panel-plugins/xfce4-mpc-plugin
||
xfce4-mpc-plugin
Xfmpc
— Graphical GTK MPD client focusing on low footprint.
https://goodies.xfce.org/projects/applications/xfmpc
||
xfmpc
ympd
— Standalone MPD Web GUI written in C, utilizing Websockets and Bootstrap/JS.
https://ympd.org/
||
ympd
AUR
Ymuse
— Easy, functional and snappy GTK front-end (client) for Music Player Daemon written in Go.
https://yktoo.com/en/software/ymuse/
||
ymuse
AUR
Misc
mpd-mpris
— Implementation of
MPRIS
for MPD.
https://github.com/natsukagami/mpd-mpris
||
mpd-mpris
mpdris2-rs
— Exposing
MPRIS
V2.2 D-Bus interface for mpd.
https://github.com/szclsya/mpdris2-rs
||
mpdris2-rs
AUR
mpc.el
— A client for the Music Player Daemon in Emacs.
https://github.com/emacs-mirror/emacs/blob/master/lisp/mpc.el
||
emacs
See also
MPD Forum
MPD User Manual
MPD GitHub repository