<para>The MPD Protocol has Three Components: Commands, Responses, and Command Lists. All communication between the client and server uses the UTF-8 character encoding.</para>
<sect2>
<sect2id="format_of_commands">
<title>Format of Commands</title>
<para>Commands in MPD are specified begginning with the name of the command. The arguments of a command are delimitted by spaces and should be surrounded by double qutotation marks. The end of a command is delimitted by a return character '<literal>\n</literal>'.<programlisting>command "arg1""arg2"</programlisting></para>
</sect2>
<sect2>
<title>Format of Responses</title>
<titleid="format_of_responses">Format of Responses</title>
<para>The different response elements of a command are seperated by the return character '<literal>\n</literal>'. The last element of a response begin with either <literal>OK</literal> or <literal>ACK</literal>. Thus, if a command is successful, the end of the response is <literal>OK\n</literal>. If a command is unsuccessful <literal>ACK</literal> terminates the command with the following format:<programlisting>ACK {err#:cmd#} {command} some error message</programlisting><literal>err#</literal> is an integer indicating the specific error that occured and <literal>cmd#</literal> is an integer indicating which command of the command list caused the error (See section 1.3 for more info on Command Lists). <literal>command</literal> gives the name of the command the error occurred on; however, its intended more for debugging persons (for human readability). <literal>some error message</literal> is also not intended to be parsed by clients but is intended more for debugging purposes.</para>
<para>The other response elements are data. The data is seperated into a name and value pare by <literal>: </literal>. Thus, a possible command response containing data would be:<programlisting>Name1: Value1
Name2: Value2
OK</programlisting></para>
</sect2>
<sect2>
<sect2id="command_lists">
<title>Command Lists</title>
<para>Command lists allow for a fast, effecient, and atomic execution of multiple commands. Command lists are initiated with either <literal>command_list_begin</literal> or <literal>command_list_ok_begin</literal>and are terminated with <literal>command_list_end</literal>.<programlisting>command_list_begin
<para><literal>command_list_ok_begin</literal> responds with <literal>list_OK</literal> after each command is successfully completed. <literal>command_list_begin</literal> does not return anything between each command that is executed.</para>
</sect2>
</sect1>
<sect1>
<sect1id="commands">
<title>Commands</title>
<sect2>
<sect2id="db_browsing">
<title>DB: Browsing, Searching, and Finding</title>
<sect3>
<sect3id="browsing_responses">
<title>Browsing Responses</title>
<para>Browsing Responses usually contain groups of several responses. These groups are either begin with <literal>file</literal>, <literal>directory</literal>, or <literal>playlist</literal>. Each of these response groups maybe followed by metadata, which always begin with a capital letter (A-Z). Here's an example of a complete browsing response:<programlisting>file: Directory/file.mp3
Artist: Muscian
...
...
@@ -49,34 +49,61 @@ playlist: Directory/favorites
OK</programlisting></para>
<para><literal>directory</literal> and <literal>playlist</literal> have no metadata, however future versions of the MPD protocol may add metadata to either. Also, future versions of MPD may add othe response groups for browsing.</para>
</sect3>
<sect3>
<sect3id="song_info_responses">
<title>Song Info Responses</title>
<para>For query information on songs in the db (and the playlist), there is a common response for each song. The first response element is <literal>file</literal>. The remainng elements of the song info are one of the following metadata types: <literal>Artist</literal>, <literal>Album</literal>, <literal>Title</literal>, <literal>Track</literal>, <literal>Name</literal>, or <literal>Time</literal>.</para>
</sect3>
<sect3>
<sect3id="lsinfo">
<title>
<literal>lsinfo</literal>
</title>
<para><programlisting>lsinfo
lsinfo <emphasis>directory</emphasis>
lsinfo <emphasis>file</emphasis></programlisting><literal>lsinfo</literal> responds with <linklinkend="browsing_responses">info</link> for the directory or file specified. If <literal>lsinfo</literal> is called without any arguments then the root directory is implied as the path.</para>
</sect3>
<sect3>
<titleid="listallinfo">
<literal>listallinfo</literal>
</title>
<para><programlisting>listallinfo
listallinfo <emphasis>directory</emphasis>
listallinfo <emphasis>file</emphasis></programlisting><literal>listallinfo</literal> is a recursive form of <literal>
<linklinkend="lsinfo">lsinfo</link>
</literal></para>
</sect3>
<sect3>
<title>
<literal>listall</literal>
</title>
<para><programlisting>listall
listall <emphasis>directory</emphasis>
listall <emphasis>file</emphasis></programlisting><literal>listall</literal> is the same as <literal>
<linklinkend="listallinfo">listallinfo</link>
</literal> except that no metadata is returned.</para>
search title <emphasis>pattern</emphasis></programlisting><literal>search</literal> respnds with the <linklinkend="song_info_responses">files</link> that match the specified pattern with the specified data (either <literal>filename</literal>, <literal>artist</literal>, <literal>album</literal>, or <literal>title</literal>).</para>
</sect3>
<sect3>
<title>
<literal>find</literal>
</title>
<para><programlisting>find artist <emphasis>match</emphasis>
find album <emphasis>match</emphasis></programlisting><literal>find</literal> responds with the <linklinkend="song_info_responses">files</link> whose <literal>artist</literal> or <literal>album</literal> are the same as <emphasis>match</emphasis>.</para>
</sect3>
<sect3>
<title>
<literal>list</literal>
</title>
<para><programlisting>list artist
list album
list album <emphasis>someArtist</emphasis></programlisting><literal>list</literal> responds with the list of albums or artists in the db.</para>