MusicPlayerDaemonQueue

From Music Player Daemon Community Wiki

The Problem:

There are two basic sets of users that have some aquired behaviors carried over from other music players. One group is xmms/winamp users who have grown accustomed to queuing.

In xmms, you can press a key ("q" in general) to queue a specific song in the playlist. Any songs that are queued in the playlist are the next songs to be played, regardless of the order of songs in the playlist or whether random is enabled. However, in xmms this queue list is hidden, apart from a [n] after the song name, where n is the position in the queue.

Another group of users (i think they used something like mserv) are accustomed to having a 'queue' and not a 'playlist'. Here, a queue is played and is essentially the 'playlist' in mpd. However, when a song is done playing in the 'queue/playlist' it is removed from the queue (same as a fifo queue). When the queue is empty, there is some command that says to either play some random song from the db, or do something like that.

MPD Solution:

MPD currently lacks any easy way to accomplish this. Either the playlist plays in order or it is randomized. While a user could shuffle a playlist, then 'queue' songs by moving songs in the playlist, this presents a few problems: 1) users/clients will have to reshuffle the playlist when the playlist is done 2) some users want the 'displayed' playlist to be in specific order to easy find songs to be queued 3) it's not possible to 'queue' the same song multiple times (as this would require adding the song multiple times to the playlist, then expunging it).

So maybe MPD should implement this concept of a 'queue'. Here, a user/client adds songs from the playlist to the queue. Then when MPD has done playing the current song (whether it be in the queue or in the playlist) it plays the next song in the queue. If the queue is empty, it plays the next song in the playlist. When a song is done playing or skipped, if it exists in the queue, then it will be removed from the queue. Clients can request the list of songs currently in the queue.

Existing implementation

http://whatah.nyunderground.net/code/mpd_queue/

Protocol Changes:

There will be a new 'queued' command that will give the list of song IDs currently in the queue, in order.

A new 'queue' command will take a song ID and will be used to add songs to the end of the queue. (remember that song IDs are unique IDs for each item in the playlist)

 wouldn't it be better to use a unique song ID which is independend from the playlist?
 In this case one could queue songs directly from the DB without having to put them in the playlist first
 -- jonas

'status' command will have a new optional item, 'queueid'. If this item is missing from 'status', then there is no queue. If this number changes between successive calls to 'status', then this means the queue has been changed (a song was expunged).

Potential Issues:

Will people expect to be able to reorder queues and remove items from the queues? If so, then there may be a need to add some sort of ID for queues, analogous to 'IDs' for songs in a playlist.

-- when I think of a "cheap dj" approach, I'd like to have a music "library"
(probably a restricted library, actually - party music only), search there for songs I want to play,
then drop them into my queue. And yes, I'll want to reorder/edit my queue then occasionally. -- erich

What will people expect for 'prev' and 'next'? If someone has some songs queued and they press 'prev', do they expect the last song in the queue that was played to be played? Or do they epect the last song that was played in the playlist to be played?

History/Queue approach

One approch for queue management I like a lot can be seen on the Nectarine website. Basically it makes the distinction between playing history and queue transparent. You would just have "the queue" (or one per output stream) which contains the songs played in the past (in order), the currently playing song (should be highlighted by clients that display this queue) and anything manually queued (should be reorderable). When the user presses prev/next, mpd can just go back/forward within this queue. Only when the end of the queue is reached, the currently selected playlist is consulted (taking into account the randomize and loop toggles). If there is no playlist selected, other plugins like mood anaylizers etc. could take over. Protocol-wise, the History/Queue could be implemented as a special playlist, but probably should get a new set of commands. -- pixelpapst

[edit] Development proposition

Queue operations most user would probably like to have available are:

• list queued items
• add file to the end of queue
• remove any queued file from queue

[edit] New commands

In order not to break current client interfaces queue would get new set of functions similar to those for playlist:

• queueinfo - similar to playlistinfo
• queueid [playlistid] - add song with id _playlistid_ from playlist to queue
• dequeue [pos] - remove song at position _pos_ from queue

To keep things as simple as possible items will have no ids. Removal and/or other modifications of queue will be controlled through position only.