01-08-2020, 03:14 PM
Not wishing to add a new work item to Tim's inexhaustible ToDo list [1], here's another client-side hint.
The MPD command protocol includes a command_list_begin/command_list_end construction. To quote from the protocol specification
Based on that, here's a URL-encoded HTTP GET request for the moOde player hostname "moode" which when entered in my browser clears the player queue, loads the "Favorites" playlist into the queue, and starts playing the first playlist entry [2] in one fell swoop. Please note that this request is entered as a single line despite how it may be displayed when you read this post.
The string "%0D%0A" is the URL-encoding for CRLF, %20 is the URL-encoding for ASCII space, so this GET request is the equivalent of
There's no fancy error handling here (e.g., the ACK error messages spoken of in the quote are ignored).
The first command stops whatever is playing and clears the queue. If the named playlist doesn't exist, that's the end of the story. If the playlist exists, it's loaded. Then, if the specified playlist entry doesn't exist the player remains stopped.
Obviously @DRONE7's proposal can be effected using this same command_list construction.
Regards,
Kent
[1] adding a new endpoint to the API entails a fair amount of work which has to be planned, documented, executed, and tested. Defining the requirements is key. Feature creep is like kudzu and must be guarded against.
[2] I forgot in my post yesterday that playlists begin at entry 0 not 1. Classic programmer mistake.
The MPD command protocol includes a command_list_begin/command_list_end construction. To quote from the protocol specification
Quote: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.
It does not execute any commands until the list has ended. The response is a concatenation of all individual responses. On success for all commands, 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.
Based on that, here's a URL-encoded HTTP GET request for the moOde player hostname "moode" which when entered in my browser clears the player queue, loads the "Favorites" playlist into the queue, and starts playing the first playlist entry [2] in one fell swoop. Please note that this request is entered as a single line despite how it may be displayed when you read this post.
Code:
http://moode/command/?cmd=command_list_begin%0D%0Aclear%0D%0Aload%20Favorites%0D%0Aplay%200%0D%0Acommand_list_endThe string "%0D%0A" is the URL-encoding for CRLF, %20 is the URL-encoding for ASCII space, so this GET request is the equivalent of
Code:
command_list_begin
clear
load Favorites
play 0
command_list_endThere's no fancy error handling here (e.g., the ACK error messages spoken of in the quote are ignored).
The first command stops whatever is playing and clears the queue. If the named playlist doesn't exist, that's the end of the story. If the playlist exists, it's loaded. Then, if the specified playlist entry doesn't exist the player remains stopped.
Obviously @DRONE7's proposal can be effected using this same command_list construction.
Regards,
Kent
[1] adding a new endpoint to the API entails a fair amount of work which has to be planned, documented, executed, and tested. Defining the requirements is key. Feature creep is like kudzu and must be guarded against.
[2] I forgot in my post yesterday that playlists begin at entry 0 not 1. Classic programmer mistake.
