Music Player Daemon

From ArchWiki
Revision as of 09:02, 6 May 2018 by Kewl (talk | contribs) (Configure the location of files and directories: improve language)
Jump to: navigation, search

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Reason: Needs improvements in structure and clarify; compare to the User's manual. (Discuss in Talk:Music Player Daemon#Style comment)

MPD (music player daemon) is an audio player that has a server-client architecture. It 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.

Installation

Install the mpd package, or mpd-gitAUR for the development version.

Configuration

MPD is able to run in the #Local configuration (per user) mode, in the #Global configuration mode (settings apply to all users), and in multiple instances #Multi-mpd setup mode. The way of setting up MPD depends on the way it is intended to be used: a local configuration may prove more useful on a desktop system, for example.

In order for MPD to be able to playback audio, ALSA, optionally with PulseAudio, needs to be setup and working.

MPD is configured in the file mpd.conf which can be located in various locations depending on the setup chosen (see below). These are the 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 folder where playlists are saved into
  • music_directory - The folder that MPD scans for music
  • sticker_file - The sticker database

Local configuration (per user)

MPD can be configured per user. Running it as a normal user has the benefits of:

  • Using a single directory ~/.config/mpd/ (or any other directory under $HOME) that contains all the MPD configuration files.
  • It is easier to avoid 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 ~/.config which is the recommended XDG base directory specification.

To build the user configuration, the example configuration file included in the package is a good starting point, copy it using the following lines:

$ mkdir ~/.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
# Required files
db_file            "~/.config/mpd/database"
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         "~/.config/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

MPD can now be started (an optional custom location for the configuration file can be specified):

$ mpd [config_file]

To build the database scanning into the music_directory defined above, a MPD client 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

If ALSA is used, autodetection of the default ALSA device should work out of the box without any particular setting. If not, the syntax for ALSA audio output definition is provided thereafter; the required name parameter specifies a unique name for the audio output.

~/.config/mpd/mpd.conf
audio_output {
        type            "alsa"
        name            "ALSA sound card"
}

Users of PulseAudio will need to make the following modification:

~/.config/mpd/mpd.conf
audio_output {
        type            "pulse"
        name            "pulse audio"
}

User will also have to edit /etc/pulse/client.conf and change the autospawn option to yes in order to allow the MPD user to use pulseaudio. It will be necessary to restart pulseaudio after making this modification.

Autostart with systemd

The mpd package provides a user service file. The configuration file is expected to exist either in ~/.mpdconf or ~/.config/mpd/mpd.conf; see systemd#Editing provided units if you would like to use a different path. 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.

All you have to do is start/enable the user unit mpd.service (i.e. with the --user flag).

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 following tool provides assistance for MPD configuration:

  • mpd-configure — Create a MPD configuration optimized for bit perfect audio playback, without any resampling or conversion, using the ALSA interface hardware address (hw:x,y)
https://github.com/ronalde/mpd-configure || no package

Global configuration

Note: Users of PulseAudio with a global MPD 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 has to be set by parameter 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 conflicts with the default configuration of the user directory where many users store their music.

While there are several solutions to this problem one of these should be most practical:

  • Use instead the #Local configuration (per user) mode
  • 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
$ chmod 710 /home/user_directory
  • Store the music collection in a different path (a) by moving it entirely, (b) with a bind mount or (c) with Btrfs#Subvolumes (you should make this change persistent with an entry to /etc/fstab ). Permissions of alternate directories can be adjusted with Access Control Lists.

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.

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).

Changing user

Changing the group that MPD runs as may result in errors like output: Failed to open "My ALSA Device", [alsa]: Failed to open ALSA device "default": No such file or directory or player_thread: problems opening audio device while playing "Song Name.mp3".

This is because the MPD users need to be part of the audio group to access sound devices under /dev/snd/. To fix it add user make the MPD user part of the audio group:

# gpasswd -a 'MPD' audio

Timeline of MPD startup

To depict when MPD drops its superuser privileges and assumes those of the user set in the configuration, the timeline of a normal MPD startup is listed here:

  1. Since MPD is started as root by systemd, it first reads the /etc/mpd.conf file.
  2. MPD reads the user variable in the /etc/mpd.conf file, and changes from root to this user.
  3. MPD then reads the contents of the /etc/mpd.conf file and configures itself accordingly.

Notice that MPD changes the running user from root to the one named in the /etc/mpd.conf file. This way, uses of ~ in the configuration file point correctly to the home user's directory, and not root's directory. It may be worthwhile to change all uses of ~ to /home/username to avoid any confusion over this aspect of MPD's behavior.

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 would use 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. (Just be sure to have a different port number, so as to not conflict with the first MPD daemon).

Satellite setup

The method above 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. 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:

Console

  • mpc — Command line user interface for MPD server
http://www.musicpd.org/clients/mpc/ || mpc
  • ncmpc — Ncurses client for MPD
http://www.musicpd.org/clients/ncmpc/ || ncmpc
  • ncmpcpp — Almost exact clone of ncmpc with some new features written in C++ (tag editor, search engine)
http://ncmpcpp.rybczak.net/ || ncmpcpp
  • pms — Highly configurable and accessible ncurses client
https://ambientsound.github.io/pms/ || pmus-gitAUR
  • vimpc — Ncurses based MPD client with vi-like key bindings
https://github.com/boysetsfrog/vimpc || vimpc-gitAUR
  • vimus — MPD client with vim-like key bindings, written in Haskell
https://github.com/vimus/vimus || no package

Graphical

  • Ario — Very feature-rich GTK2 GUI client for MPD, inspired by Rhythmbox
http://ario-player.sourceforge.net/ || ario
  • QmpdClient — GUI client written with Qt 4.x
http://bitcheese.net/wiki/QMPDClient || qmpdclient
  • Sonata — Elegant Python GTK+ client
http://www.nongnu.org/sonata/ || sonata
  • gmpc — GTK2 frontend for Music Player Daemon. It is designed to be lightweight and easy to use, while providing full access to all of MPD's features. Users are presented with several different methods to browse through their music. It can be extended by plugins, of which many are available.
http://gmpclient.org/ || gmpc
  • Cantata — High-feature, Qt4, Qt5 or KDE client for MPD with very configurable interface
https://github.com/CDrummond/cantata || cantata
  • Xfmpc — A graphical GTK+ MPD client focusing on low footprint
http://goodies.xfce.org/projects/applications/xfmpc || xfmpc
  • pymp'd — A GTK+ front end client for the music playing daemon MPD
http://pympd.sourceforge.net || pympd
  • Quimup — A client for MPD written in C++ and QT3 / since v. 1.4.0 the code was migrated to Qt5 for MPD 0.17.0 and above
http://goodies.xfce.org/projects/applications/xfmpc || quimupAUR
  • SkyMPC — A simple MPD client, powered by Qt5
https://github.com/soramimi/SkyMPC || skympc-gitAUR

See also

  • MPD Forum
  • MPD User Manual
  • Wikipedia article
  • mopidy is an alternative to MPD written in Python. Note 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. However, the project is not that active and some of its plugins are not maintained.