| Commit message (Collapse) | Author | Files | Lines |
|
Implement a "bulk" edit mode that postpones both UpdateQueuedSong()
and OnModified(). This way, the playlist version gets incremented
only once. More importantly: when adding multiple songs to a queue
that consists of only one song, the first song that got added will
always be played next. By postponing this choice, all newly added
songs get a chance to become the next song. Fixes the second (and
last) part of Mantis ticket 0004005.
|
|
|
|
|
|
Don't use IgnoreError() when there's an overload that does not try to
give us one.
|
|
Fixes purging deleted songs from the queue after update. Fixes
regression from commit e96779d.
|
|
|
|
|
|
Fix for a major memory leak.
|
|
Prepare to migrate away from GLib. Currently, we're still using GLib
as a backend.
|
|
|
|
|
|
Replaces GLib's GError.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use the C++ API.
|
|
|
|
|
|
Allow the plugin to allocate the GetSong() return value.
|
|
Rewrite of the pc_get_error_message() function, now using a GError
object instead of the complicated "errored_song" attribute.
|
|
|
|
Moving songs using either 'move' or 'moveid' to position -1 (after the
current song) would fail for a song which is just before the current
song.
This patch corrects the check to see if the current song is in the range
to be moved. Since the range is from `start` up to `end` (exclusive) the
check was incorrect, but is now fixed.
|
|
Sorts remaining songs by priority. This can be used for the
much-demanded "queue feature".
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Renamed all playlist functions to non-CamelCase.
|
|
|
|
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.
|
|
"ls" is a bad name for a library which parses URIs. We'll move the
rest of the "ls" library later.
|
|
|
|
This command shuffles a range of songs.
|
|
When MPD is stopped, but the last song is still the "current song",
and you delete it, playlist->current is not updated, and becomes an
invalid value. Fix this by catching "!playlist->playing &&
playlist->current == (int)songOrder".
|
|
Moved functions for playlist editing (append, delete, shuffle, move)
to playlist_edit.c.
|
|
Moved handlers for control commands (play, stop, next, prev) to
playlist_control.c.
|
|
Don't call syncPlaylistWithQueue() in nextSongInPlaylist() and
previousSongInPlaylist(). This is a relic from the time when there
was no event, and was a workaround to the timing problem.
|
|
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.
|
|
Moved everything related to saving or loading the playlist from/to the
state file to playlist_state.c.
|
|
Before every operation which modifies the playlist, remember a pointer
to the song struct. After the modification, determine the "next song"
again, and if it differs, dequeue and queue the new song.
This removes a lot of complexity from the playlist update code, and
makes it more robust.
|