From http://bugs.debian.org/513291
"In mpd.conf, the "admin" permission covers updating the db and
killing mpd.
"Since there are quite some usecases in which the user can upload
music to the mpd's directory by means of anonymous FTP or so, it is
desirable that any user may issue a db update, while killing the mpd
should not be possible.
"I'd suggest to remove the db update from the admin group and either
add it to "control" or an own group."
Allocate a player_control object where needed, and pass it around.
Each "client" object is associated with a "player_control" instance.
This prepares multi-player support.
this is inconsistent with other commands (e.g. find) and seems wrong --
a song with no stickers attached is a perfectly valid state and an empty
list of stickers is also perfectly valid.
When handle_update() was modified to use uri_safe_local(), suddently
"mpc update ''" and "mpc update '/'" stopped working, because both are
not a "safe" local URI. This patch adds a special case for these, to
retain backwards compatibility.
This is a very basic check, which only ensures that the path does not
begin with a slash, doesn't have double slashes and the special names
"." and ".." are forbidden.
After we've been hit by Large File Support problems several times in
the past week (which only occur on 32 bit platforms, which I don't
have), this is yet another attempt to fix the issue.
The new player_status struct replaces a bunch of playerGetX()
functions. When we add proper locking to the player_control struct,
we will only need to lock once for the "status" command.
Allow most printable characters in unquoted words. The tokenizer
patch introduced very strict requirements for command parameters -
those were undocumented, and we're reverting the strictness now.
Converted the range checks in volume_level_change() to assertions.
Changed all volume types to "unsigned", expect for those which must be
able to indicate error (-1).
db_get_song was being called once for all sub-handlers, but with the
addition of the find command, we don't have a URI coming in, so doing
db_get_song once won't work anymore.
[mk: fixed initialization order]
This is a little ugly, but as nextSongInPlaylist is both called when
queued is update (in case playlist ended) and for user "next" command,
there isn't any other (simple) solution
The smartstop feature is a way to tell mpd to stop playing after
current song.
This patche provides:
- 'state' command returns 'smartstop' state (1 or 0)
- 'smartstop' can activate or not the smartstop state
- when song is terminated, mpd stops playing and smartstop is set to 0
The move command now accepts a range for the first argument, in the same
form as other range commands, e.g. move 15:17 3. The first song in the
range is placed at the destination position. Note that as with other
range commands, the range is inclusive on the left only; this example
would move only songs 15 and 16, not 17.
[mk: fixed signed/unsigned warnings; use G_MAXUINT instead of
UINT_MAX]
This updates the copyright header to all be the same, which is
pretty much an update of where to mail request for a copy of the GPL
and the years of the MPD project. This also puts all committers under
'The Music Player Project' umbrella. These entries should go
individually in the AUTHORS file, for consistancy.
The output_command library provides a command interface to the audio
outputs. It assumes the input comes from an untrusted source
(i.e. the client) and verifies all parameters.
Export the "g_playlist" variable, and pass it to all playlist
functions. This way, we can split playlist.c easier into separate
parts. The code which initializes the singleton variable is moved to
playlist_global.c.
PlaylistInfo() (notice the capital 'P') sends a stored playlist to the
client. Move it to a separate library, where all the code which glues
the playlist and the MPD protocol together will live.
Don't attempt to restart the player if it was stopped, but there were
still songs left on the playlist. This looks like it has been a
workaround for a bug which has been fixed long time ago.
The "sticker" command allows clients to query or manipulate the
sticker database. This patch implements the sub-commands "get" and
"set"; more will follow soon (enumeration), as well as extended
"lsinfo" / "playlistinfo" versions.
Loosely based on a patch provided by lesion in bug #1766. The playlistinfo
command can now retrieve ranges of the playlist. The new argument indicates
which entry is the last one that will be displayed. The number of displayed
entries may be smaller than expected if the end of the playlist is reached.
Previous usage:
playlistinfo [start]
New usage:
playlistinfo [start[:end]]
Don't call command_error() if loading a song from the playlist fails.
This may result in assertion failures, since command_error() may be
called more than once.
