protocol.rst 51.2 KB
Newer Older
1 2 3
########
Protocol
########
4 5

General protocol syntax
6
***********************
7 8 9 10

Protocol overview
=================

11
The :program:`MPD` command protocol exchanges
12 13 14 15 16
line-based text records between client and server over TCP.
Once the client is connected to the server, they conduct a
conversation until the client closes the connection. The
conversation flow is always initiated by the client.

17 18 19
All data between the client and the server is encoded in
UTF-8.

20 21 22 23 24 25
The client transmits a command sequence, terminated by the
newline character ``\n``.  The server will
respond with one or more lines, the last of which will be a
completion code.

When the client connects to the server, the server will answer
26
with the following line::
27

28
 OK MPD version
29 30 31 32 33 34 35 36 37

where ``version`` is a version identifier such as
0.12.2.  This version identifier is the version of the protocol
spoken, not the real version of the daemon.  (There is no way to
retrieve this real version identifier from the connection.)

Requests
========

38 39 40
.. code-block:: none

 COMMAND [ARG...]
41 42 43 44 45 46 47 48 49 50 51 52 53 54

If arguments contain spaces, they should be surrounded by double
quotation marks.

Argument strings are separated from the command and any other
arguments by linear white-space (' ' or '\\t').

Responses
=========

A command returns ``OK`` on completion or
``ACK some error`` on failure.  These
denote the end of command execution.

55 56 57 58 59 60 61 62 63 64 65 66 67
Some commands return more data before the response ends with ``OK``.
Each line is usually in the form ``NAME: VALUE``.  Example::

  foo: bar
  OK

.. _binary:

Binary Responses
----------------

Some commands can return binary data.  This is initiated by a line
containing ``binary: 1234`` (followed as usual by a newline).  After
68
that, the specified number of bytes of binary data follows, then a
69 70 71
newline, and finally the ``OK`` line.

If the object to be transmitted is large, the server may choose a
72 73 74 75 76 77 78 79
reasonable chunk size and transmit only a portion.  The maximum chunk
size can be changed by clients with the :ref:`binarylimit
<command_binarylimit>` command.

Usually, the response also contains a ``size`` line which specifies
the total (uncropped) size, and the command usually has a way to
specify an offset into the object; this way, the client can copy the
whole file without blocking the connection for too long.
80 81

Example::
82 83 84

  foo: bar
  binary: 42
85 86
  <42 bytes>
  OK
87 88


89 90 91 92 93 94 95
Failure responses
-----------------

The nature of the error can be gleaned from the information
that follows the ``ACK``.
``ACK`` lines are of the form:

96 97 98
.. code-block:: none

 ACK [error@command_listNum] {current_command} message_text
99 100 101 102 103 104 105 106 107

These responses are generated by a call to
``commandError``. They contain four separate
terms. Let's look at each of them:

- ``error``: numeric value of one
  of the ``ACK_ERROR`` constants defined
  in `src/protocol/Ack.hxx`.

108 109 110
- ``command_listNum``: offset of the command that caused the error in
  a :ref:`Command List <command_lists>`.  An error will always cause a
  command list to terminate at the command that causes the error.
111

112 113
- ``current_command``: name of the command, in a :ref:`Command List
  <command_lists>`, that was executing when the error occurred.
114 115 116 117 118

- ``message_text``:
  some (hopefully) informative text that describes the
  nature of the error.

119 120
An example might help.  Consider the following sequence
sent from the client to the server::
121

122 123 124 125 126
 command_list_begin
 volume 86
 play 10240
 status
 command_list_end
127

128
The server responds with::
129

130
 ACK [50@1] {play} song doesn't exist: "10240"
131

132 133 134 135 136
This tells us that the play command, which was the second in the list
(the first or only command is numbered 0), failed with error 50.  The
number 50 translates to ``ACK_ERROR_NO_EXIST`` -- the song doesn't
exist.  This is reiterated by the message text which also tells us
which song doesn't exist.
137 138 139 140 141 142 143 144 145 146 147 148

.. _command_lists:

Command lists
=============

To facilitate faster adding of files etc. you can pass a list
of commands all at once using a command list.  The command
list begins with `command_list_begin` or
`command_list_ok_begin` and ends with
`command_list_end`.

149 150 151
It does not execute any commands until the list has ended.  The
response is a concatentation of all individual responses.
On success for all commands,
152 153 154 155 156 157 158 159 160 161
``OK`` is returned.  If a command
fails, no more commands are executed and the appropriate
``ACK`` error is returned. If
`command_list_ok_begin` is used,
``list_OK`` is returned for each
successful command executed in the command list.

Ranges
======

162 163 164 165
Some commands (e.g. :ref:`delete <command_delete>`) allow specifying a
range in the form ``START:END`` (the ``END`` item is not included in
the range, similar to ranges in the Python programming language).  If
``END`` is omitted, then the maximum possible value is assumed.
166 167 168 169 170 171

.. _filter_syntax:

Filters
=======

172 173 174
All commands which search for songs (e.g. :ref:`find <command_find>`
and :ref:`searchadd <command_searchadd>`) share a common filter
syntax::
175

176
 find EXPRESSION
177

178
``EXPRESSION`` is a string enclosed in parentheses which can be one
179
of:
180

181 182 183 184
- ``(TAG == 'VALUE')``: match a tag value; if there are multiple
  values of the given type, at least one must match.
  ``(TAG != 'VALUE')``: mismatch a tag value; if there are multiple
  values of the given type, none of them must match.
185
  The special tag ``any`` checks all
186
  tag types.
187
  ``AlbumArtist`` looks for
188 189 190
  ``VALUE`` in ``AlbumArtist``
  and falls back to ``Artist`` tags if
  ``AlbumArtist`` does not exist.
191
  ``VALUE`` is what to find.
192 193 194
  An empty value string means: match only if the given tag type does
  not exist at all; this implies that negation with an empty value
  checks for the existence of the given tag type.
195

196 197 198
- ``(TAG contains 'VALUE')`` checks if the given value is a substring
  of the tag value.

199 200 201 202 203
- ``(TAG =~ 'VALUE')`` and ``(TAG !~ 'VALUE')`` use a Perl-compatible
  regular expression instead of doing a simple string comparison.
  (This feature is only available if :program:`MPD` was compiled with
  :file:`libpcre`)

204 205 206 207 208 209 210 211 212 213 214
- ``(file == 'VALUE')``: match the full song URI
  (relative to the music directory).

- ``(base 'VALUE')``: restrict the search to
  songs in the given directory (relative to the music
  directory).

- ``(modified-since 'VALUE')``: compares the
  file's time stamp with the given value (ISO 8601 or UNIX
  time stamp).

215 216 217
- ``(AudioFormat == 'SAMPLERATE:BITS:CHANNELS')``: compares the audio
  format with the given value.  See :ref:`audio_output_format` for a
  detailed explanation.
218 219 220

- ``(AudioFormat =~ 'SAMPLERATE:BITS:CHANNELS')``:
  matches the audio format with the given mask (i.e. one
221
  or more attributes may be ``*``).
222

223
- ``(!EXPRESSION)``: negate an expression.  Note that each expression
224
  must be enclosed in parentheses, e.g. :code:`(!(artist == 'VALUE'))`
225
  (which is equivalent to :code:`(artist != 'VALUE')`)
226 227

- ``(EXPRESSION1 AND EXPRESSION2 ...)``: combine two or
228
  more expressions with logical "and".  Note that each expression must
229
  be enclosed in parentheses, e.g. :code:`((artist == 'FOO') AND
230
  (album == 'BAR'))`
231

Xipmix's avatar
Xipmix committed
232
The :command:`find` commands are case sensitive, while
233 234
:command:`search` and related commands ignore case.

235
Prior to MPD 0.21, the syntax looked like this::
236

237
 find TYPE VALUE
238

239 240 241 242 243 244 245 246 247 248 249
Escaping String Values
----------------------

String values are quoted with single or double quotes, and special
characters within those values must be escaped with the backslash
(``\``).  Keep in mind that the backslash is also the escape character
on the protocol level, which means you may need to use double
backslash.

Example expression which matches an artist named ``foo'bar"``::

250
 (Artist == "foo\'bar\"")
251 252 253

At the protocol level, the command must look like this::

254
 find "(Artist == \"foo\\'bar\\\"\")"
255 256 257 258 259 260 261 262 263 264 265 266 267 268

The double quotes enclosing the artist name must be escaped because
they are inside a double-quoted ``find`` parameter.  The single quote
inside that artist name must be escaped with two backslashes; one to
escape the single quote, and another one because the backslash inside
the string inside the parameter needs to be escaped as well.  The
double quote has three confusing backslashes: two to build one
backslash, and another one to escape the double quote on the protocol
level.  Phew!

To reduce confusion, you should use a library such as `libmpdclient
<https://www.musicpd.org/libs/libmpdclient/>`_ which escapes command
arguments for you.

269 270 271 272 273
.. _tags:

Tags
====

274
The following tags are supported by :program:`MPD`:
275

276 277 278 279 280 281 282 283 284 285 286
* **artist**: the artist name. Its meaning is not well-defined; see "*composer*" and "*performer*" for more specific tags.
* **artistsort**: same as artist, but for sorting. This usually omits prefixes such as "The".
* **album**: the album name.
* **albumsort**: same as album, but for sorting.
* **albumartist**: on multi-artist albums, this is the artist name which shall be used for the whole album. The exact meaning of this tag is not well-defined.
* **albumartistsort**: same as albumartist, but for sorting.
* **title**: the song title.
* **track**: the decimal track number within the album.
* **name**: a name for this song. This is not the song title. The exact meaning of this tag is not well-defined. It is often used by badly configured internet radio stations with broken tags to squeeze both the artist name and the song title in one tag.
* **genre**: the music genre.
* **date**: the song's release date. This is usually a 4-digit year.
287
* **originaldate**: the song's original release date.
288
* **composer**: the artist who composed the song.
289
* **composersort**: same as composer, but for sorting.
290
* **performer**: the artist who performed the song.
smutbert's avatar
smutbert committed
291
* **conductor**: the conductor who conducted the song.
292 293
* **work**: `"a work is a distinct intellectual or artistic creation,
  which can be expressed in the form of one or more audio recordings" <https://musicbrainz.org/doc/Work>`_
294 295 296 297
* **ensemble**: the ensemble performing this song, e.g. "Wiener Philharmoniker".
* **movement**: name of the movement, e.g. "Andante con moto".
* **movementnumber**: movement number, e.g. "2" or "II".
* **location**: location of the recording, e.g. "Royal Albert Hall".
298 299 300
* **grouping**: "used if the sound belongs to a larger category of
  sounds/music" (`from the IDv2.4.0 TIT1 description
  <http://id3.org/id3v2.4.0-frames>`_).
301 302
* **comment**: a human-readable comment about this song. The exact meaning of this tag is not well-defined.
* **disc**: the decimal disc number in a multi-disc album.
303
* **label**: the name of the label or publisher.
304 305 306 307 308 309 310
* **musicbrainz_artistid**: the artist id in the `MusicBrainz <https://picard.musicbrainz.org/docs/mappings/>`_ database.
* **musicbrainz_albumid**: the album id in the `MusicBrainz <https://picard.musicbrainz.org/docs/mappings/>`_ database.
* **musicbrainz_albumartistid**: the album artist id in the `MusicBrainz <https://picard.musicbrainz.org/docs/mappings/>`_ database.
* **musicbrainz_trackid**: the track id in the `MusicBrainz <https://picard.musicbrainz.org/docs/mappings/>`_ database.
* **musicbrainz_releasetrackid**: the release track id in the `MusicBrainz <https://picard.musicbrainz.org/docs/mappings/>`_ database.
* **musicbrainz_workid**: the work id in the `MusicBrainz <https://picard.musicbrainz.org/docs/mappings/>`_ database.

311
There can be multiple values for some of these tags.  For
312
example, :program:`MPD` may return multiple
313 314 315 316 317 318 319 320
lines with a ``performer`` tag.  A tag value is
a UTF-8 string.

.. _other_metadata:

Other Metadata
==============

321 322
The response to :ref:`lsinfo <command_lsinfo>` and similar commands
may contain :ref:`song tags <tags>` and other metadata, specifically:
323 324 325 326 327 328 329 330

- ``duration``: the duration of the song in
  seconds; may contain a fractional part.

- ``time``: like ``duration``,
  but as integer value.  This is deprecated and is only here
  for compatibility with older clients.  Do not use.

331 332 333 334 335 336
- ``Range``: if this is a queue item referring only to a portion of
  the song file, then this attribute contains the time range in the
  form ``START-END`` or ``START-`` (open ended); both ``START`` and
  ``END`` are time stamps within the song in seconds (may contain a
  fractional part).  Example: ``60-120`` plays only the second minute;
  "``180`` skips the first three minutes.
337 338 339 340

- ``Format``: the audio format of the song
  (or an approximation to a format supported by MPD and the
  decoder plugin being used).  When playing this file, the
341
  ``audio`` value in the :ref:`status <command_status>`
342 343 344 345 346 347 348 349
  response should be the same.

- ``Last-Modified``: the time stamp of the
  last modification of the underlying file in ISO 8601
  format.  Example:
  "*2008-09-28T20:04:57Z*"

Recipes
350
*******
351 352 353 354

Queuing
=======

355 356 357
Often, users run :program:`MPD` with :ref:`random <command_random>`
enabled, but want to be able to insert songs "before" the rest of the
playlist.  That is commonly called "queuing".
358

359 360 361 362 363
:program:`MPD` implements this by allowing the client to specify a
"priority" for each song in the playlist (commands :ref:`priod
<command_prio>` and :ref:`priodid <command_prioid>`).  A higher
priority means that the song is going to be played before the other
songs.
364

365
In "random" mode, :program:`MPD` maintains an
366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381
internal randomized sequence of songs.  In this sequence,
songs with a higher priority come first, and all songs with
the same priority are shuffled (by default, all songs are
shuffled, because all have the same priority "0").  When you
increase the priority of a song, it is moved to the front of
the sequence according to its new priority, but always after
the current one.  A song that has been played already (it's
"before" the current song in that sequence) will only be
scheduled for repeated playback if its priority has become
bigger than the priority of the current song.  Decreasing the
priority of a song will move it farther to the end of the
sequence.  Changing the priority of the current song has no
effect on the sequence.  During playback, a song's priority is
reset to zero.

Command reference
382
*****************
383 384 385 386 387 388 389

.. note:: For manipulating playlists and playing, there are two sets of
   commands.  One set uses the song id of a song in the playlist,
   while another set uses the playlist position of the song. The
   commands using song ids should be used instead of the commands
   that manipulate and control playback based on playlist
   position. Using song ids is a safer method when multiple
390
   clients are interacting with :program:`MPD`.
391

392
Querying :program:`MPD`'s status
393 394
================================

395 396
.. _command_clearerror:

397
:command:`clearerror`
398 399 400
    Clears the current error message in status (this is also
    accomplished by any command that starts playback).

401 402
.. _command_currentsong:

403
:command:`currentsong`
404
    Displays the song info of the current song (same song that
405 406 407
    is identified in status). Information about the current song
    is represented by key-value pairs, one on each line. The first
    pair must be the `file` key-value pair.
408

409 410 411
.. _command_idle:

:command:`idle [SUBSYSTEMS...]` [#since_0_14]_
412
    Waits until there is a noteworthy change in one or more
413
    of :program:`MPD`'s subsystems.  As soon
414 415 416 417
    as there is one, it lists all changed systems in a line
    in the format ``changed:
    SUBSYSTEM``, where SUBSYSTEM is one of the
    following:
418 419

    - ``database``: the song database has been modified after :ref:`update <command_update>`.
420 421
    - ``update``: a database update has started or finished.  If the database was modified during the update, the ``database`` event is also emitted.
    - ``stored_playlist``: a stored playlist has been modified, renamed, created or deleted
422
    - ``playlist``: the queue (i.e. the current playlist) has been modified
423 424 425
    - ``player``: the player has been started, stopped or seeked or
      tags of the currently playing song have changed (e.g. received
      from stream)
426 427 428 429 430 431 432
    - ``mixer``: the volume has been changed
    - ``output``: an audio output has been added, removed or modified (e.g. renamed, enabled or disabled)
    - ``options``: options like repeat, random, crossfade, replay gain
    - ``partition``: a partition was added, removed or changed
    - ``sticker``: the sticker database has been modified.
    - ``subscription``: a client has subscribed or unsubscribed to a channel
    - ``message``: a message was received on a channel this client is subscribed to; this event is only emitted when the queue is empty
433 434
    - ``neighbor``: a neighbor was found or lost
    - ``mount``: the mount list has changed
435 436

    Change events accumulate, even while the connection is not in
437
    "idle" mode; no events get lost while the client is doing
438 439
    something else with the connection.  If an event had already
    occurred since the last call, the new :ref:`idle <command_idle>`
440
    command will return immediately.
441

442 443 444 445 446
    While a client is waiting for `idle`
    results, the server disables timeouts, allowing a client
    to wait for events as long as mpd runs.  The
    `idle` command can be canceled by
    sending the command `noidle` (no other
447
    commands are allowed). :program:`MPD`
448 449 450
    will then leave `idle` mode and print
    results immediately; might be empty at this time.
    If the optional ``SUBSYSTEMS`` argument
451
    is used, :program:`MPD` will only send
452 453 454
    notifications when something changed in one of the
    specified subsytems.

455 456 457
.. _command_status:

:command:`status`
458 459
    Reports the current status of the player and the volume
    level.
460

461 462
    - ``partition``: the name of the current partition (see
      :ref:`partition_commands`)
463 464
    - ``volume``: ``0-100`` (deprecated: ``-1`` if the volume cannot
      be determined)
465 466
    - ``repeat``: ``0`` or ``1``
    - ``random``: ``0`` or ``1``
467
    - ``single`` [#since_0_15]_: ``0``, ``1``, or ``oneshot`` [#since_0_21]_
468
    - ``consume`` [#since_0_15]_: ``0`` or ``1``
469 470
    - ``playlist``: 31-bit unsigned integer, the playlist version number
    - ``playlistlength``: integer, the length of the playlist
471
    - ``state``: ``play``, ``stop``, or ``pause``
472 473
    - ``song``: playlist song number of the current song stopped on or playing
    - ``songid``: playlist songid of the current song stopped on or playing
474 475
    - ``nextsong`` [#since_0_15]_: playlist song number of the next song to be played
    - ``nextsongid`` [#since_0_15]_: playlist songid of the next song to be played
476
    - ``time``: total time elapsed (of current playing/paused song) in seconds
477
      (deprecated, use ``elapsed`` instead)
478 479
    - ``elapsed`` [#since_0_16]_: Total time elapsed within the
      current song in seconds, but with higher resolution.
480
    - ``duration`` [#since_0_20]_: Duration of the current song in seconds.
481 482 483 484
    - ``bitrate``: instantaneous bitrate in kbps
    - ``xfade``: ``crossfade`` in seconds
    - ``mixrampdb``: ``mixramp`` threshold in dB
    - ``mixrampdelay``: ``mixrampdelay`` in seconds
485 486 487
    - ``audio``: The format emitted by the decoder plugin during
      playback, format: ``samplerate:bits:channels``.  See
      :ref:`audio_output_format` for a detailed explanation.
488 489 490
    - ``updating_db``: ``job id``
    - ``error``: if there is an error, returns message here

491 492 493 494
    :program:`MPD` may omit lines which have no (known) value.  Older
    :program:`MPD` versions used to have a "magic" value for
    "unknown", e.g. ":samp:`volume: -1`".

495 496
.. _command_stats:

497
:command:`stats`
498
    Displays statistics.
499

500 501 502 503
    - ``artists``: number of artists
    - ``albums``: number of albums
    - ``songs``: number of songs
    - ``uptime``: daemon uptime in seconds
504
    - ``db_playtime``: sum of all song times in the database in seconds
505 506
    - ``db_update``: last db update in UNIX time (seconds since
      1970-01-01 UTC)
507 508 509 510 511
    - ``playtime``: time length of music played

Playback options
================

512 513
.. _command_consume:

514
:command:`consume {STATE}` [#since_0_15]_
515 516 517 518
    Sets consume state to ``STATE``,
    ``STATE`` should be 0 or 1.
    When consume is activated, each song played is removed from playlist.

519 520
.. _command_crossfade:

521
:command:`crossfade {SECONDS}`
522 523
    Sets crossfading between songs.

524 525
.. _command_mixrampdb:

526
:command:`mixrampdb {deciBels}`
527 528
    Sets the threshold at which songs will be overlapped. Like crossfading but doesn't fade the track volume, just overlaps. The songs need to have MixRamp tags added by an external tool. 0dB is the normalized maximum volume so use negative values, I prefer -17dB. In the absence of mixramp tags crossfading will be used. See http://sourceforge.net/projects/mixramp

529 530
.. _command_mixrampdelay:

531
:command:`mixrampdelay {SECONDS}`
532 533
    Additional time subtracted from the overlap calculated by mixrampdb. A value of "nan" disables MixRamp overlapping and falls back to crossfading.

534 535 536
.. _command_random:

:command:`random {STATE}`
537 538 539
    Sets random state to ``STATE``,
    ``STATE`` should be 0 or 1.

540 541
.. _command_repeat:

542
:command:`repeat {STATE}`
543 544 545
    Sets repeat state to ``STATE``,
    ``STATE`` should be 0 or 1.

546 547 548
.. _command_setvol:

:command:`setvol {VOL}`
549 550 551
    Sets volume to ``VOL``, the range of
    volume is 0-100.

552 553
.. _command_getvol:

554 555 556 557 558 559 560 561 562 563
:command:`getvol`

    Read the volume.  The result is a ``volume:`` line like in
    :ref:`status <command_status>`.  If there is no mixer, MPD will
    emit an empty response.  Example::

      getvol
      volume: 42
      OK

564 565
.. _command_single:

566
:command:`single {STATE}` [#since_0_15]_
567
    Sets single state to ``STATE``,
568
    ``STATE`` should be ``0``, ``1`` or ``oneshot`` [#since_0_21]_.
569 570 571
    When single is activated, playback is stopped after current song, or
    song is repeated if the 'repeat' mode is enabled.

572 573
.. _command_replay_gain_mode:

574
:command:`replay_gain_mode {MODE}` [#since_0_16]_
575
    Sets the replay gain mode.  One of
576 577 578 579
    ``off``,
    ``track``,
    ``album``,
    ``auto``
580 581
    .
    Changing the mode during playback may take several
582
    seconds, because the new settings do not affect the
583 584 585 586
    buffered data.
    This command triggers the
    ``options`` idle event.

587 588
.. _command_replay_gain_status:

589
:command:`replay_gain_status`
590 591 592 593
    Prints replay gain options.  Currently, only the
    variable ``replay_gain_mode`` is
    returned.

594 595
.. _command_volume:

596
:command:`volume {CHANGE}`
597
    Changes volume by amount ``CHANGE``.
598
    Deprecated, use :ref:`setvol <command_setvol>` instead.
599 600 601 602

Controlling playback
====================

603 604
.. _command_next:

605
:command:`next`
606 607
    Plays next song in the playlist.

608 609
.. _command_pause:

610 611 612 613
:command:`pause {STATE}`
    Pause or resume playback.  Pass :samp:`1` to pause playback or
    :samp:`0` to resume playback.  Without the parameter, the pause
    state is toggled.
614

615 616
.. _command_play:

617
:command:`play [SONGPOS]`
618 619 620
    Begins playing the playlist at song number
    ``SONGPOS``.

621 622
.. _command_playid:

623
:command:`playid [SONGID]`
624 625 626
    Begins playing the playlist at song
    ``SONGID``.

627 628
.. _command_previous:

629
:command:`previous`
630 631
    Plays previous song in the playlist.

632 633
.. _command_seek:

634
:command:`seek {SONGPOS} {TIME}`
635 636 637 638
    Seeks to the position ``TIME`` (in
    seconds; fractions allowed) of entry
    ``SONGPOS`` in the playlist.

639 640
.. _command_seekid:

641
:command:`seekid {SONGID} {TIME}`
642 643 644 645
    Seeks to the position ``TIME`` (in
    seconds; fractions allowed) of song
    ``SONGID``.

646 647
.. _command_seekcur:

648
:command:`seekcur {TIME}`
649 650
    Seeks to the position ``TIME`` (in
    seconds; fractions allowed) within the current song.  If
651
    prefixed by ``+`` or ``-``, then the time is relative to the
652 653
    current playing position.

654 655
.. _command_stop:

656
:command:`stop`
657 658
    Stops playing.

659 660 661 662 663 664 665 666 667 668 669 670 671 672
The Queue
=========

.. note:: The "queue" used to be called "current playlist" or just
          "playlist", but that was deemed confusing, because
          "playlists" are also files containing a sequence of songs.
          Those "playlist files" or "stored playlists" can be
          :ref:`loaded into the queue <command_load>` and the queue
          can be :ref:`saved into a playlist file <command_save>`, but
          they are not to be confused with the queue.

          Many of the command names in this section reflect the old
          naming convention, but for the sake of compatibility, we
          cannot rename commands.
673

674 675 676
There are two ways to address songs within the queue: by their
position and by their id.

677
The position is a 0-based index.  It is unstable by design: if you
678 679 680 681 682 683 684 685 686 687 688 689
move, delete or insert songs, all following indices will change, and a
client can never be sure what song is behind a given index/position.

Song ids on the other hand are stable: an id is assigned to a song
when it is added, and will stay the same, no matter how much it is
moved around.  Adding the same song twice will assign different ids to
them, and a deleted-and-readded song will have a new id.  This way, a
client can always be sure the correct song is being used.

Many commands come in two flavors, one for each address type.
Whenever possible, ids should be used.

690 691
.. _command_add:

692
:command:`add {URI}`
693 694 695 696
    Adds the file ``URI`` to the playlist
    (directories add recursively). ``URI``
    can also be a single file.

697
    Clients that are connected via local socket may add arbitrary
698
    local files (URI is an absolute path).  Example::
699 700 701

     add "/home/foo/Music/bar.ogg"

702 703
.. _command_addid:

704 705 706
:command:`addid {URI} [POSITION]`
    Adds a song to the playlist (non-recursive) and returns the
    song id. ``URI`` is always a single file or  URL.  For example::
707

708 709 710
     addid "foo.mp3"
     Id: 999
     OK
711

712 713
    If the second parameter is given, then the song is inserted at the
    specified position.  If the parameter starts with ``+`` or ``-``,
714 715 716 717
    then it is relative to the current song; e.g. ``+0`` inserts right
    after the current song and ``-0`` inserts right before the current
    song (i.e. zero songs between the current song and the newly added
    song).
718

719 720
.. _command_clear:

721
:command:`clear`
722
    Clears the queue.
723

724 725 726
.. _command_delete:

:command:`delete [{POS} | {START:END}]`
727 728
    Deletes a song from the playlist.

729 730
.. _command_deleteid:

731
:command:`deleteid {SONGID}`
732 733 734
    Deletes the song ``SONGID`` from the
    playlist

735 736
.. _command_move:

cotko's avatar
cotko committed
737
:command:`move [{FROM} | {START:END}] {TO}`
738
    Moves the song at ``FROM`` or range of songs
739
    at ``START:END`` [#since_0_15]_ to ``TO``
740 741
    in the playlist.

742 743 744 745 746
    If ``TO`` starts with ``+`` or ``-``, then it is relative to the
    current song; e.g. ``+0`` moves to right after the current song
    and ``-0`` moves to right before the current song (i.e. zero songs
    between the current song and the moved range).

747 748
.. _command_moveid:

749
:command:`moveid {FROM} {TO}`
750 751
    Moves the song with ``FROM`` (songid) to
    ``TO`` (playlist index) in the
752 753 754 755 756 757
    playlist.

    If ``TO`` starts with ``+`` or ``-``, then it is relative to the
    current song; e.g. ``+0`` moves to right after the current song
    and ``-0`` moves to right before the current song (i.e. zero songs
    between the current song and the moved song).
758

759 760
.. _command_playlist:

761 762
:command:`playlist`

763
    Displays the queue.
764

765 766 767
    Do not use this, instead use :ref:`playlistinfo
    <command_playlistinfo>`.

768 769
.. _command_playlistfind:

770
:command:`playlistfind {FILTER}`
771
    Finds songs in the queue with strict
772 773
    matching.

774 775
.. _command_playlistid:

776
:command:`playlistid {SONGID}`
777 778 779 780
    Displays a list of songs in the playlist.
    ``SONGID`` is optional and specifies a
    single song to display info for.

781 782 783
.. _command_playlistinfo:

:command:`playlistinfo [[SONGPOS] | [START:END]]`
784 785 786
    Displays a list of all songs in the playlist, or if the optional
    argument is given, displays information only for the song
    ``SONGPOS`` or the range of songs
787
    ``START:END`` [#since_0_15]_
788

789 790
.. _command_playlistsearch:

791
:command:`playlistsearch {FILTER}`
792
    Searches case-insensitively for partial matches in the
793
    queue.
794

795 796
.. _command_plchanges:

797
:command:`plchanges {VERSION} [START:END]`
798 799 800 801
    Displays changed songs currently in the playlist since
    ``VERSION``.  Start and end positions may
    be given to limit the output to changes in the given
    range.
802

803 804 805
    To detect songs that were deleted at the end of the
    playlist, use playlistlength returned by status command.

806 807
.. _command_plchangesposid:

808
:command:`plchangesposid {VERSION} [START:END]`
809 810 811 812
    Displays changed songs currently in the playlist since
    ``VERSION``.  This function only
    returns the position and the id of the changed song, not
    the complete metadata. This is more bandwidth efficient.
813

814 815 816
    To detect songs that were deleted at the end of the
    playlist, use playlistlength returned by status command.

817 818 819
.. _command_prio:

:command:`prio {PRIORITY} {START:END...}`
820 821 822
    Set the priority of the specified songs.  A higher
    priority means that it will be played first when
    "random" mode is enabled.
823

824 825 826
    A priority is an integer between 0 and 255.  The default
    priority of new songs is 0.

827 828 829 830
.. _command_prioid:

:command:`prioid {PRIORITY} {ID...}`
    Same as :ref:`priod <command_prio>`,
831 832
    but address the songs with their id.

833 834
.. _command_rangeid:

835
:command:`rangeid {ID} {START:END}` [#since_0_19]_
836
    Since :program:`MPD`
837 838 839 840 841 842 843 844
    0.19 Specifies the portion of the
    song that shall be played.  ``START`` and
    ``END`` are offsets in seconds
    (fractional seconds allowed); both are optional.
    Omitting both (i.e. sending just ":") means "remove the
    range, play everything".  A song that is currently
    playing cannot be manipulated this way.

845 846
.. _command_shuffle:

847
:command:`shuffle [START:END]`
848
    Shuffles the queue.
849 850 851
    ``START:END`` is optional and specifies
    a range of songs.

852 853
.. _command_swap:

854
:command:`swap {SONG1} {SONG2}`
855 856 857
    Swaps the positions of ``SONG1`` and
    ``SONG2``.

858 859
.. _command_swapid:

860
:command:`swapid {SONG1} {SONG2}`
861 862 863
    Swaps the positions of ``SONG1`` and
    ``SONG2`` (both song ids).

864 865
.. _command_addtagid:

866
:command:`addtagid {SONGID} {TAG} {VALUE}`
867 868 869 870 871 872
    Adds a tag to the specified song.  Editing song tags is
    only possible for remote songs.  This change is
    volatile: it may be overwritten by tags received from
    the server, and the data is gone when the song gets
    removed from the queue.

873 874
.. _command_cleartagid:

875
:command:`cleartagid {SONGID} [TAG]`
876 877 878 879 880 881 882 883 884 885 886 887 888 889 890
    Removes tags from the specified song.  If
    ``TAG`` is not specified, then all tag
    values will be removed.  Editing song tags is only
    possible for remote songs.

Stored playlists
================

Playlists are stored inside the configured playlist directory.
They are addressed with their file name (without the directory
and without the `.m3u` suffix).

Some of the commands described in this section can be used to
run playlist plugins instead of the hard-coded simple
`m3u` parser.  They can access playlists in
891 892
the music directory (relative path including the suffix),
playlists in arbitrary location (absolute path including the suffix;
893
allowed only for clients that are connected via local socket), or
894 895
remote playlists (absolute URI with a supported scheme).

896 897
.. _command_listplaylist:

898
:command:`listplaylist {NAME}`
899 900 901
    Lists the songs in the playlist.  Playlist plugins are
    supported.

902 903
.. _command_listplaylistinfo:

904
:command:`listplaylistinfo {NAME}`
905 906 907
    Lists the songs with metadata in the playlist.  Playlist
    plugins are supported.

908 909
.. _command_listplaylists:

910
:command:`listplaylists`
911 912 913 914 915 916 917
    Prints a list of the playlist directory.
    After each playlist name the server sends its last
    modification time as attribute "Last-Modified" in ISO
    8601 format.  To avoid problems due to clock differences
    between clients and the server, clients should not
    compare this value with their local clock.

918 919
.. _command_load:

920
:command:`load {NAME} [START:END] [POSITION]`
921 922 923 924
    Loads the playlist into the current queue.  Playlist
    plugins are supported.  A range may be specified to load
    only a part of the playlist.

925
    The ``POSITION`` parameter specifies where the songs will be
926 927 928
    inserted into the queue; it can be relative as described in
    :ref:`addid <command_addid>`.  (This requires specifying the range
    as well; the special value `0:` can be used if the whole playlist
929 930
    shall be loaded at a certain queue position.)

931 932
.. _command_playlistadd:

933
:command:`playlistadd {NAME} {URI}`
934 935 936 937 938
    Adds ``URI`` to the playlist
    `NAME.m3u`.
    `NAME.m3u` will be created if it does
    not exist.

939 940
.. _command_playlistclear:

941
:command:`playlistclear {NAME}`
942 943
    Clears the playlist `NAME.m3u`.

944 945
.. _command_playlistdelete:

946
:command:`playlistdelete {NAME} {SONGPOS}`
947 948 949
    Deletes ``SONGPOS`` from the
    playlist `NAME.m3u`.

950 951
.. _command_playlistmove:

952
:command:`playlistmove {NAME} {FROM} {TO}`
953 954 955 956
    Moves the song at position ``FROM`` in
    the playlist `NAME.m3u` to the
    position ``TO``.

957 958
.. _command_rename:

959
:command:`rename {NAME} {NEW_NAME}`
960 961
    Renames the playlist `NAME.m3u` to `NEW_NAME.m3u`.

962 963
.. _command_rm:

964
:command:`rm {NAME}`
965 966 967
    Removes the playlist `NAME.m3u` from
    the playlist directory.

968 969
.. _command_save:

970
:command:`save {NAME}`
971
    Saves the queue to
972 973 974 975 976
    `NAME.m3u` in the playlist directory.

The music database
==================

977 978
.. _command_albumart:

979
:command:`albumart {URI} {OFFSET}`
980
    Locate album art for the given song and return a chunk of an album
981
    art image file at offset ``OFFSET``.
982 983 984 985

    This is currently implemented by searching the directory the file
    resides in for a file called :file:`cover.png`, :file:`cover.jpg`,
    :file:`cover.tiff` or :file:`cover.bmp`.
986

987 988
    Returns the file size and actual number
    of bytes read at the requested offset, followed
989
    by the chunk requested as raw bytes (see :ref:`binary`), then a
990
    newline and the completion code.
991 992 993

    Example::

994
     albumart foo/bar.ogg 0
995 996
     size: 1024768
     binary: 8192
997 998
     <8192 bytes>
     OK
999

1000 1001
.. _command_count:

1002
:command:`count {FILTER} [group {GROUPTYPE}]`
1003 1004
    Count the number of songs and their total playtime in
    the database matching ``FILTER`` (see
1005
    :ref:`Filters <filter_syntax>`).  The
1006
    following prints the number of songs whose title matches
1007 1008 1009 1010
    "Echoes"::

     count title Echoes

1011 1012 1013 1014
    The *group* keyword may be used to
    group the results by a tag.  The first following example
    prints per-artist counts while the next prints the
    number of songs whose title matches "Echoes" grouped by
1015 1016 1017 1018
    artist::

     count group artist
     count title Echoes group artist
1019

1020 1021
    A group with an empty value contains counts of matching songs which
    don't have this group tag.  It exists only if at least one such song is
1022 1023
    found.

1024 1025
.. _command_getfingerprint:

1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036
:command:`getfingerprint {URI}`

    Calculate the song's audio fingerprint.  Example (abbreviated fingerprint)::

      getfingerprint "foo/bar.ogg"
      chromaprint: AQACcEmSREmWJJmkIT_6CCf64...
      OK

    This command is only available if MPD was built with
    :file:`libchromaprint` (``-Dchromaprint=enabled``).

1037 1038 1039
.. _command_find:

:command:`find {FILTER} [sort {TYPE}] [window {START:END}]`
1040
    Search the database for songs matching
1041 1042
    ``FILTER`` (see :ref:`Filters <filter_syntax>`).

1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054
    ``sort`` sorts the result by the
    specified tag.  The sort is descending if the tag is
    prefixed with a minus ('-').
    Without ``sort``, the
    order is undefined.  Only the first tag value will be
    used, if multiple of the same type exist.  To sort by
    "Artist", "Album" or "AlbumArtist", you should specify
    "ArtistSort", "AlbumSort" or "AlbumArtistSort" instead.
    These will automatically fall back to the former if
    "\*Sort" doesn't exist.  "AlbumArtist" falls back to just
    "Artist".  The type "Last-Modified" can sort by file
    modification time.
1055

1056 1057 1058 1059 1060
    ``window`` can be used to query only a
    portion of the real response.  The parameter is two
    zero-based record numbers; a start number and an end
    number.

1061 1062
.. _command_findadd:

1063
:command:`findadd {FILTER} [sort {TYPE}] [window {START:END}] [position POS]`
1064
    Search the database for songs matching
1065
    ``FILTER`` (see :ref:`Filters <filter_syntax>`) and add them to
1066
    the queue.  Parameters have the same meaning as for
1067
    :ref:`find <command_find>` and :ref:`searchadd <command_searchadd>`.
1068

1069 1070 1071
.. _command_list:

:command:`list {TYPE} {FILTER} [group {GROUPTYPE}]`
1072 1073
    Lists unique tags values of the specified type.
    ``TYPE`` can be any tag supported by
1074
    :program:`MPD`.
1075 1076

    Additional arguments may specify a :ref:`filter <filter_syntax>`.
1077 1078
    The *group* keyword may be used
    (repeatedly) to group the results by one or more tags.
1079

1080
    The following example lists all album names,
1081 1082 1083 1084
    grouped by their respective (album) artist::

     list album group albumartist

1085 1086 1087 1088
    ``list file`` was implemented in an early :program:`MPD` version,
    but does not appear to make a lot of sense.  It still works (to
    avoid breaking compatibility), but is deprecated.

1089
.. _command_listall:
1090

1091
:command:`listall [URI]`
1092 1093
    Lists all songs and directories in
    ``URI``.
1094

1095
    Do not use this command.  Do not manage a client-side
1096
    copy of :program:`MPD`'s database.  That
1097 1098
    is fragile and adds huge overhead.  It will break with
    large databases.  Instead, query
1099
    :program:`MPD` whenever you need
1100 1101
    something.

1102 1103 1104 1105
.. _command_listallinfo:

:command:`listallinfo [URI]`
    Same as :ref:`listall <command_listall>`,
1106
    except it also returns metadata info in the same format
1107 1108
    as :ref:`lsinfo <command_lsinfo>`

1109
    Do not use this command.  Do not manage a client-side
1110
    copy of :program:`MPD`'s database.  That
1111 1112
    is fragile and adds huge overhead.  It will break with
    large databases.  Instead, query
1113
    :program:`MPD` whenever you need
1114 1115
    something.

1116 1117
.. _command_listfiles:

1118
:command:`listfiles {URI}`
1119 1120
    Lists the contents of the directory
    ``URI``, including files are not
1121
    recognized by :program:`MPD`.
1122 1123 1124 1125 1126 1127
    ``URI`` can be a path relative to the
    music directory or an URI understood by one of the
    storage plugins.  The response contains at least one
    line for each directory entry with the prefix "file: "
    or "directory: ", and may be followed by file attributes
    such as "Last-Modified" and "size".
1128

1129 1130 1131 1132
    For example, "smb://SERVER" returns a list of all shares
    on the given SMB/CIFS server; "nfs://servername/path"
    obtains a directory listing from the NFS server.

1133 1134
.. _command_lsinfo:

kaliko's avatar
kaliko committed
1135
:command:`lsinfo [URI]`
1136 1137 1138 1139 1140
    Lists the contents of the directory
    ``URI``.  The response contains records
    starting with ``file``,
    ``directory`` or
    ``playlist``, each followed by metadata
1141 1142
    (:ref:`tags <tags>` or :ref:`other metadata <other_metadata>`).

1143 1144 1145
    When listing the root directory, this currently returns
    the list of stored playlists.  This behavior is
    deprecated; use "listplaylists" instead.
1146

1147 1148
    This command may be used to list metadata of remote
    files (e.g. URI beginning with "http://" or "smb://").
1149

1150
    Clients that are connected via local socket may
1151 1152 1153
    use this command to read the tags of an arbitrary local
    file (URI is an absolute path).

1154 1155
.. _command_readcomments:

1156
:command:`readcomments {URI}`
1157 1158 1159
    Read "comments" (i.e. key-value pairs) from the file
    specified by "URI".  This "URI" can be a path relative
    to the music directory or an absolute path.
1160

1161 1162
    This command may be used to list metadata of remote
    files (e.g. URI beginning with "http://" or "smb://").
1163

1164 1165 1166
    The response consists of lines in the form "KEY: VALUE".
    Comments with suspicious characters (e.g. newlines) are
    ignored silently.
1167

1168 1169 1170 1171
    The meaning of these depends on the codec, and not all
    decoder plugins support it.  For example, on Ogg files,
    this lists the Vorbis comments.

1172 1173
.. _command_readpicture:

1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197
:command:`readpicture {URI} {OFFSET}`
    Locate a picture for the given song and return a chunk of the
    image file at offset ``OFFSET``.  This is usually implemented by
    reading embedded pictures from binary tags (e.g. ID3v2's ``APIC``
    tag).

    Returns the following values:

    - ``size``: the total file size
    - ``type``: the file's MIME type (optional)
    - ``binary``: see :ref:`binary`

    If the song file was recognized, but there is no picture, the
    response is successful, but is otherwise empty.

    Example::

     readpicture foo/bar.ogg 0
     size: 1024768
     type: image/jpeg
     binary: 8192
     <8192 bytes>
     OK

1198 1199
.. _command_search:

1200
:command:`search {FILTER} [sort {TYPE}] [window {START:END}]
1201
    Search the database for songs matching
1202 1203
    ``FILTER`` (see :ref:`Filters <filter_syntax>`).  Parameters
    have the same meaning as for :ref:`find <command_find>`,
1204 1205
    except that search is not case sensitive.

1206 1207
.. _command_searchadd:

1208
:command:`searchadd {FILTER} [sort {TYPE}] [window {START:END}] [position POS]`
1209
    Search the database for songs matching
1210
    ``FILTER`` (see :ref:`Filters <filter_syntax>`) and add them to
1211 1212
    the queue.

1213 1214
    Parameters have the same meaning as for :ref:`search <command_search>`.

1215 1216 1217
    The ``position`` parameter specifies where the songs will be
    inserted.

1218 1219
.. _command_searchaddpl:

1220
:command:`searchaddpl {NAME} {FILTER} [sort {TYPE}] [window {START:END}]`
1221
    Search the database for songs matching
1222
    ``FILTER`` (see :ref:`Filters <filter_syntax>`) and add them to
1223
    the playlist named ``NAME``.
1224

1225 1226
    If a playlist by that name doesn't exist it is created.

1227 1228 1229 1230 1231
    Parameters have the same meaning as for :ref:`search <command_search>`.

.. _command_update:

:command:`update [URI]`
1232 1233
    Updates the music database: find new files, remove
    deleted files, update modified files.
1234

1235 1236 1237
    ``URI`` is a particular directory or
    song/file to update.  If you do not specify it,
    everything is updated.
1238 1239

    Prints ``updating_db: JOBID`` where
1240 1241
    ``JOBID`` is a positive number
    identifying the update job.  You can read the current
1242
    job id in the :ref:`status <command_status>`
1243 1244
    response.

1245 1246
.. _command_rescan:

1247 1248
:command:`rescan [URI]`
    Same as :ref:`update <command_update>`,
1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261
    but also rescans unmodified files.

Mounts and neighbors
====================

A "storage" provides access to files in a directory tree.  The
most basic storage plugin is the "local" storage plugin which
accesses the local file system, and there are plugins to
access NFS and SMB servers.

Multiple storages can be "mounted" together, similar to the
`mount` command on many operating
systems, but without cooperation from the kernel.  No
1262 1263
superuser privileges are necessary, because this mapping exists
only inside the :program:`MPD` process.
1264

1265 1266 1267
.. _command_mount:

:command:`mount {PATH} {URI}`
1268
    Mount the specified remote storage URI at the given
1269 1270 1271 1272
    path.  Example::

     mount foo nfs://192.168.1.4/export/mp3

1273 1274
.. _command_unmount:

1275 1276
:command:`unmount {PATH}`
    Unmounts the specified path.  Example::
1277

1278
     unmount foo
1279

1280 1281
.. _command_listmounts:

1282
:command:`listmounts`
1283 1284
    Queries a list of all mounts.  By default, this contains
    just the configured ``music_directory``.
1285 1286 1287 1288 1289 1290 1291 1292 1293
    Example::

     listmounts
     mount:
     storage: /home/foo/music
     mount: foo
     storage: nfs://192.168.1.4/export/mp3
     OK

1294 1295
.. _command_listneighbors:

1296
:command:`listneighbors`
1297 1298
    Queries a list of "neighbors" (e.g. accessible file
    servers on the local net).  Items on that list may be
1299 1300 1301 1302 1303 1304 1305
    used with the :ref:`mount <command_mount>`
    command.  Example::

     listneighbors
     neighbor: smb://FOO
     name: FOO (Samba 4.1.11-Debian)
     OK
1306 1307 1308 1309

Stickers
========

1310
"Stickers" [#since_0_15]_ are pieces of
1311
information attached to existing
1312
:program:`MPD` objects (e.g. song files,
1313 1314
directories, albums; but currently, they are only implemented for
song).  Clients can create arbitrary name/value
1315
pairs.  :program:`MPD` itself does not assume
1316 1317 1318 1319 1320
any special meaning in them.

The goal is to allow clients to share additional (possibly
dynamic) information about songs, which is neither stored on
the client (not available to other clients), nor stored in the
1321
song files (:program:`MPD` has no write
1322 1323 1324 1325 1326 1327 1328 1329 1330
access).

Client developers should create a standard for common sticker
names, to ensure interoperability.

Objects which may have stickers are addressed by their object
type ("song" for song objects) and their URI (the path within
the database for songs).

1331 1332
.. _command_sticker_get:

1333
:command:`sticker get {TYPE} {URI} {NAME}`
1334 1335
    Reads a sticker value for the specified object.

1336 1337
.. _command_sticker_set:

1338
:command:`sticker set {TYPE} {URI} {NAME} {VALUE}`
1339 1340 1341 1342
    Adds a sticker value to the specified object.  If a
    sticker item with that name already exists, it is
    replaced.

1343 1344
.. _command_sticker_delete:

1345
:command:`sticker delete {TYPE} {URI} [NAME]`
1346 1347 1348 1349
    Deletes a sticker value from the specified object.  If
    you do not specify a sticker name, all sticker values
    are deleted.

1350 1351
.. _command_sticker_list:

1352
:command:`sticker list {TYPE} {URI}`
1353 1354
    Lists the stickers for the specified object.

1355 1356
.. _command_sticker_find:

1357
:command:`sticker find {TYPE} {URI} {NAME}`
1358 1359 1360 1361 1362
    Searches the sticker database for stickers with the
    specified name, below the specified directory (URI).
    For each matching song, it prints the URI and that one
    sticker's value.

1363 1364
.. _command_sticker_find_value:

1365
:command:`sticker find {TYPE} {URI} {NAME} = {VALUE}`
1366
    Searches for stickers with the given value.
1367

1368 1369 1370 1371 1372 1373
    Other supported operators are:
    "``<``", "``>``"

Connection settings
===================

1374 1375
.. _command_close:

1376
:command:`close`
1377 1378
    Closes the connection to :program:`MPD`.
    :program:`MPD` will try to send the
1379 1380 1381 1382
    remaining output buffer before it actually closes the
    connection, but that cannot be guaranteed.  This command
    will not generate a response.

1383 1384 1385
    Clients should not use this command; instead, they should just
    close the socket.

1386 1387
.. _command_kill:

1388
:command:`kill`
1389
    Kills :program:`MPD`.
1390

1391 1392 1393 1394
    Do not use this command.  Send ``SIGTERM`` to :program:`MPD`
    instead, or better: let your service manager handle :program:`MPD`
    shutdown (e.g. :command:`systemctl stop mpd`).

1395 1396
.. _command_password:

1397
:command:`password {PASSWORD}`
1398 1399 1400 1401
    This is used for authentication with the server.
    ``PASSWORD`` is simply the plaintext
    password.

1402 1403
.. _command_ping:

1404
:command:`ping`
1405 1406
    Does nothing but return "OK".

1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417
.. _command_binarylimit:

:command:`binarylimit SIZE` [#since_0_22_4]_

    Set the maximum :ref:`binary response <binary>` size for the
    current connection to the specified number of bytes.

    A bigger value means less overhead for transmitting large
    entities, but it also means that the connection is blocked for a
    longer time.

1418 1419
.. _command_tagtypes:

1420
:command:`tagtypes`
1421 1422 1423
    Shows a list of available tag types.  It is an
    intersection of the ``metadata_to_use``
    setting and this client's tag mask.
1424

1425 1426 1427 1428 1429 1430 1431
    About the tag mask: each client can decide to disable
    any number of tag types, which will be omitted from
    responses to this client.  That is a good idea, because
    it makes responses smaller.  The following
    ``tagtypes`` sub commands configure this
    list.

1432 1433
.. _command_tagtypes_disable:

kaliko's avatar
kaliko committed
1434
:command:`tagtypes disable {NAME...}`
1435 1436 1437 1438
    Remove one or more tags from the list of tag types the
    client is interested in.  These will be omitted from
    responses to this client.

1439 1440
.. _command_tagtypes_enable:

1441
:command:`tagtypes enable {NAME...}`
1442 1443 1444 1445
    Re-enable one or more tags from the list of tag types
    for this client.  These will no longer be hidden from
    responses to this client.

1446 1447
.. _command_tagtypes_clear:

1448
:command:`tagtypes clear`
1449
    Clear the list of tag types this client is interested
1450
    in.  This means that :program:`MPD` will
1451 1452
    not send any tags to this client.

1453 1454
.. _command_tagtypes_all:

1455
:command:`tagtypes all`
1456 1457 1458
    Announce that this client is interested in all tag
    types.  This is the default setting for new clients.

1459 1460
.. _partition_commands:

1461 1462 1463 1464 1465 1466 1467 1468
Partition commands
==================

These commands allow a client to inspect and manage
"partitions".  A partition is one frontend of a multi-player
MPD process: it has separate queue, player and outputs.  A
client is assigned to one partition at a time.

1469 1470
.. _command_partition:

1471
:command:`partition {NAME}`
1472 1473
    Switch the client to a different partition.

1474 1475
.. _command_listpartitions:

1476
:command:`listpartitions`
1477 1478 1479 1480 1481
    Print a list of partitions.  Each partition starts with
    a ``partition`` keyword and the
    partition's name, followed by information about the
    partition.

1482 1483
.. _command_newpartition:

1484
:command:`newpartition {NAME}`
1485 1486
    Create a new partition.

1487 1488
.. _command_delpartition:

1489 1490 1491 1492
:command:`delpartition {NAME}`
    Delete a partition.  The partition must be empty (no connected
    clients and no outputs).

1493 1494
.. _command_moveoutput:

1495 1496 1497
:command:`moveoutput {OUTPUTNAME}`
    Move an output to the current partition.

1498 1499 1500
Audio output devices
====================

1501 1502
.. _command_disableoutput:

1503
:command:`disableoutput {ID}`
1504 1505
    Turns an output off.

1506 1507
.. _command_enableoutput:

1508
:command:`enableoutput {ID}`
1509 1510
    Turns an output on.

1511 1512
.. _command_toggleoutput:

1513
:command:`toggleoutput {ID}`
1514 1515 1516
    Turns an output on or off, depending on the current
    state.

1517 1518 1519
.. _command_outputs:

:command:`outputs`
1520
    Shows information about all outputs.
1521

1522 1523 1524 1525 1526 1527 1528 1529 1530 1531
    ::

        outputid: 0
        outputname: My ALSA Device
        plugin: alsa
        outputenabled: 0
        attribute: dop=0
        OK

    Return information:
1532

1533 1534 1535 1536
    - ``outputid``: ID of the output. May change between executions
    - ``outputname``: Name of the output. It can be any.
    - ``outputenabled``: Status of the output. 0 if disabled, 1 if enabled.

1537 1538
.. _command_outputset:

1539
:command:`outputset {ID} {NAME} {VALUE}`
1540 1541
    Set a runtime attribute.  These are specific to the
    output plugin, and supported values are usually printed
1542
    in the :ref:`outputs <command_outputs>`
1543 1544 1545 1546 1547
    response.

Reflection
==========

1548 1549
.. _command_config:

1550
:command:`config`
1551 1552
    Dumps configuration values that may be interesting for
    the client.  This command is only permitted to "local"
1553
    clients (connected via local socket).
1554

1555 1556
    The following response attributes are available:

1557 1558
    - ``music_directory``: The absolute path of the music directory.

1559 1560
.. _command_commands:

1561
:command:`commands`
1562 1563
    Shows which commands the current user has access to.

1564 1565
.. _command_notcommands:

1566
:command:`notcommands`
1567 1568 1569
    Shows which commands the current user does not have
    access to.

1570 1571
.. _command_urlhandlers:

1572
:command:`urlhandlers`
1573 1574
    Gets a list of available URL handlers.

1575 1576
.. _command_decoders:

1577
:command:`decoders`
1578
    Print a list of decoder plugins, followed by their
1579 1580 1581 1582 1583 1584 1585 1586
    supported suffixes and MIME types.  Example response::

     plugin: mad
     suffix: mp3
     suffix: mp2
     mime_type: audio/mpeg
     plugin: mpcdec
     suffix: mpc
1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597

Client to client
================

Clients can communicate with each others over "channels".  A
channel is created by a client subscribing to it.  More than
one client can be subscribed to a channel at a time; all of
them will receive the messages which get sent to it.

Each time a client subscribes or unsubscribes, the global idle
event ``subscription`` is generated.  In
1598
conjunction with the :ref:`channels <command_channels>`
1599 1600 1601 1602 1603 1604
command, this may be used to auto-detect clients providing
additional services.

New messages are indicated by the ``message``
idle event.

1605 1606 1607
If your MPD instance has multiple partitions, note that
client-to-client messages are local to the current partition.

1608 1609
.. _command_subscribe:

1610
:command:`subscribe {NAME}`
1611 1612 1613 1614 1615
    Subscribe to a channel.  The channel is created if it
    does not exist already.  The name may consist of
    alphanumeric ASCII characters plus underscore, dash, dot
    and colon.

1616 1617
.. _command_unsubscribe:

1618
:command:`unsubscribe {NAME}`
1619 1620
    Unsubscribe from a channel.

1621 1622 1623
.. _command_channels:

:command:`channels`
1624 1625 1626
    Obtain a list of all channels.  The response is a list
    of "channel:" lines.

1627 1628
.. _command_readmessages:

1629
:command:`readmessages`
1630 1631 1632
    Reads messages for this client.  The response is a list
    of "channel:" and "message:" lines.

1633 1634
.. _command_sendmessage:

1635
:command:`sendmessage {CHANNEL} {TEXT}`
1636 1637
    Send a message to the specified channel.

1638
.. rubric:: Footnotes
1639

1640 1641 1642
.. [#since_0_14] Since :program:`MPD` 0.14
.. [#since_0_15] Since :program:`MPD` 0.15
.. [#since_0_16] Since :program:`MPD` 0.16
1643
.. [#since_0_19] Since :program:`MPD` 0.19
1644
.. [#since_0_20] Since :program:`MPD` 0.20
1645
.. [#since_0_21] Since :program:`MPD` 0.21
1646
.. [#since_0_22_4] Since :program:`MPD` 0.22.4