Provides access to the media player's playlists.

Since D-Bus does not provide an easy way to check for what interfaces are exported on an object, clients should attempt to get one of the properties on this interface to see if it is implemented.

Unique playlist identifier.

Multiple playlists may have the same name.

This is a D-Bus object id as that is the definitive way to have unique identifiers on D-Bus. It also allows for future optional expansions to the specification where tracks are exported to D-Bus with an interface similar to org.gnome.UPnP.MediaItem2.

A URI.

A data structure describing a playlist.

A unique identifier for the playlist.

This should remain the same if the playlist is renamed.

The name of the playlist, typically given by the user.

The URI of an (optional) icon.

A data structure describing a playlist, or nothing.

D-Bus does not (at the time of writing) support a MAYBE type, so we are forced to invent our own.

Whether this structure refers to a valid playlist.

The playlist, providing Valid is true, otherwise undefined.

When constructing this type, it should be noted that the playlist ID must be a valid object path, or D-Bus implementations may reject it. This is true even when Valid is false. It is suggested that "/" is used as the playlist ID in this case.

Specifies the ordering of returned playlists.

Alphabetical ordering by name, ascending.

Ordering by creation date, oldest first.

Ordering by last modified date, oldest first.

Ordering by date of last playback, oldest first.

A user-defined ordering.

Some media players may allow users to order playlists as they wish. This ordering allows playlists to be retreived in that order.

Starts playing the given playlist.

Note that this must be implemented. If the media player does not allow clients to change the playlist, it should not implement this interface at all.

It is up to the media player whether this completely replaces the current tracklist, or whether it is merely inserted into the tracklist and the first track starts. For example, if the media player is operating in a "jukebox" mode, it may just append the playlist to the list of upcoming tracks, and skip to the first track in the playlist.

The id of the playlist to activate.

Gets a set of playlists.

The index of the first playlist to be fetched (according to the ordering).

The maximum number of playlists to fetch.

The ordering that should be used.

Whether the order should be reversed.

A list of (at most MaxCount) playlists.

The number of playlists available.

The available orderings. At least one must be offered.

Media players may not have access to all the data required for some orderings. For example, creation times are not available on UNIX filesystems (don't let the ctime fool you!). On the other hand, clients should have some way to get the "most recent" playlists.

The currently-active playlist.

If there is no currently-active playlist, the structure's Valid field will be false, and the Playlist details are undefined.

Note that this may not have a value even after ActivatePlaylist is called with a valid playlist id as ActivatePlaylist implementations have the option of simply inserting the contents of the playlist into the current tracklist.

The playlist which details have changed.

Indicates that either the Name or Icon attribute of a playlist has changed.

Client implementations should be aware that this signal may not be implemented.

Without this signal, media players have no way to notify clients of a change in the attributes of a playlist other than the active one