+ This interface implements the methods for querying and providing basic + control over what is currently playing. +
+A track is currently playing.
+A track is currently paused.
+There is no track currently playing.
+A playback state.
+The playback will stop when there are no more tracks to play
+The current track will start again from the begining once it has finished playing
+The playback loops through a list of tracks
+A repeat / loop status
+Unique track identifier.
++ If the media player implements the TrackList interface and allows + the same track to appear multiple times in the tracklist, + this must be unique within the scope of the tracklist. +
++ Note that this should be a valid D-Bus object id, although clients + should not assume that any object is actually exported with any + interfaces at that path. +
+
+ Media players may not use any paths starting with
+
+ 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 playback rate
++ This is a multiplier, so a value of 0.5 indicates that playback is + happening at half speed, while 1.5 means that 1.5 seconds of "track time" + is consumed every second. +
+Audio volume level
++ Note that the volume may be higher than 1.0, although generally + clients should not attempt to set it above 1.0. +
+Time in microseconds.
+Skips to the next track in the tracklist.
++ If there is no next track (and endless playback and track + repeat are both off), stop playback. +
+If playback is paused or stopped, it remains that way.
+
+ If
Skips to the previous track in the tracklist.
++ If there is no previous track (and endless playback and track + repeat are both off), stop playback. +
+If playback is paused or stopped, it remains that way.
+
+ If
Pauses playback.
+If playback is already paused, this has no effect.
++ Calling Play after this should cause playback to start again + from the same position. +
+
+ If
Pauses playback.
+If playback is already paused, resumes playback.
+If playback is stopped, starts playback.
+
+ If
Stops playback.
+If playback is already stopped, this has no effect.
++ Calling Play after this should cause playback to + start again from the beginning of the track. +
+
+ If
Starts or resumes playback.
+If already playing, this has no effect.
+If paused, playback resumes from the current position.
+If there is no track to play, this has no effect.
+
+ If
The number of microseconds to seek forward.
++ Seeks forward in the current track by the specified number + of microseconds. +
++ A negative value seeks back. If this would mean seeking + back further than the start of the track, the position + is set to 0. +
++ If the value passed in would mean seeking beyond the end + of the track, acts like a call to Next. +
+
+ If the
The currently playing track's identifier.
++ If this does not match the id of the currently-playing track, + the call is ignored as "stale". +
+
+
Track position in microseconds.
+This must be between 0 and <track_length>.
+Sets the current track position in microseconds.
+If the Position argument is less than 0, do nothing.
++ If the Position argument is greater than the track length, + do nothing. +
+
+ If the
+ The reason for having this method, rather than making
+
+ Uri of the track to load. Its uri scheme should be an element of the
+
Opens the Uri given as an argument
+If the playback is stopped, starts playing
++ If the uri scheme or the mime-type of the uri to open is not supported, + this method does nothing and may raise an error. In particular, if the + list of available uri schemes is empty, this method may not be + implemented. +
+Clients should not assume that the Uri has been opened as soon as this
+ method returns. They should wait until the mpris:trackid field in the
+
+ If the media player implements the TrackList interface, then the
+ opened track should be made part of the tracklist, the
+
The current playback status.
++ May be "Playing", "Paused" or "Stopped". +
+The current loop / repeat status
+May be: +
+ If
The current playback rate.
+
+ The value must fall in the range described by
+
+ If the media player has no ability to play at speeds other than the
+ normal playback rate, this must still be implemented, and must
+ return 1.0. The
+ Not all values may be accepted by the media player. It is left to + media player implementations to decide how to deal with values they + cannot use; they may either ignore them or pick a "best fit" value. + Clients are recommended to only use sensible fractions or multiples + of 1 (eg: 0.5, 0.25, 1.5, 2.0, etc). +
++ This allows clients to display (reasonably) accurate progress bars + without having to regularly query the media player for the current + position. +
++ A value of false indicates that playback is + progressing linearly through a playlist, while true + means playback is progressing through a playlist in some other order. +
+
+ If
The metadata of the current element.
++ If there is a current track, this must have a "mpris:trackid" entry + (of D-Bus type "o") at the very least, which contains a D-Bus path that + uniquely identifies this track. +
++ See the type documentation for more details. +
+The volume level.
++ When setting, if a negative value is passed, the volume + should be set to 0.0. +
+
+ If
+ The current track position in microseconds, between 0 and + the 'mpris:length' metadata entry (see Metadata). +
+
+ Note: If the media player allows it, the current playback position
+ can be changed either the SetPosition method or the Seek method on
+ this interface. If this is not the case, the
+
+ If the playback progresses in a way that is inconstistant with the
+
+ The minimum value which the
+ Note that even if this value is 0.0 or negative, clients should
+ not attempt to set the
This value should always be 1.0 or less.
+
+ The maximum value which the
+ This value should always be 1.0 or greater. +
+
+ Whether the client can call the
+ If it is unknown whether a call to
+ If
+ Even when playback can generally be controlled, there may not + always be a next track to move to. +
+
+ Whether the client can call the
+
+ If it is unknown whether a call to
+ If
+ Even when playback can generally be controlled, there may not + always be a next previous to move to. +
+Whether playback can be started using
+
+ Note that this is related to whether there is a "current track": the
+ value should not depend on whether the track is currently paused or
+ playing. In fact, if a track is currently playing (and
+
+ If
+ Even when playback can generally be controlled, it may not be + possible to enter a "playing" state, for example if there is no + "current track". +
+Whether playback can be paused using
+
+ Note that this is an intrinsic property of the current track: its
+ value should not depend on whether the track is currently paused or
+ playing. In fact, if playback is currently paused (and
+
+ If
+ Not all media is pausable: it may not be possible to pause some + streamed media, for example. +
+
+ Whether the client can control the playback position using
+
+ If
+ Not all media is seekable: it may not be possible to seek when + playing some streamed media, for example. +
+Whether the media player may be controlled over this interface.
++ This property is not expected to change, as it describes an intrinsic + capability of the implementation. +
++ If this is false, clients should assume that all + properties on this interface are read-only (and will raise errors + if writing to them is attempted), no methods are implemented + and all other properties starting with "Can" are also + false. +
++ This allows clients to determine whether to present and enable + controls to the user in advance of attempting to call methods + and write to properties. +
+The new position, in microseconds.
++ Indicates that the track position has changed in a way that is + inconsistant with the current playing state. +
+When this signal is not received, clients should assume that:
++ This signal does not need to be emitted when playback starts + or when the track changes, unless the track is starting at an + unexpected position. An expected position would be the last + known one when going from Paused to Playing, and 0 when going from + Stopped to Playing. +
+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. +
+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. +
++ Provides access to a short list of tracks which were recently played or + will be played shortly. This is intended to provide context to the + currently-playing track, rather than giving complete access to the + media player's playlist. +
++ Example use cases are the list of tracks from the same album as the + currently playing song or the + Rhythmbox play queue. +
++ Each track in the tracklist has a unique identifier. + The intention is that this uniquely identifies the track within + the scope of the tracklist. In particular, if a media item + (a particular music file, say) occurs twice in the track list, each + occurrence should have a different identifier. If a track is removed + from the middle of the playlist, it should not affect the track ids + of any other tracks in the tracklist. +
++ As a result, the traditional track identifiers of URLs and position + in the playlist cannot be used. Any scheme which satisfies the + uniqueness requirements is valid, as clients should not make any + assumptions about the value of the track id beyond the fact + that it is a unique identifier. +
++ Note that the (memory and processing) burden of implementing the + TrackList interface and maintaining unique track ids for the + playlist can be mitigated by only exposing a subset of the playlist when + it is very long (the 20 or so tracks around the currently playing + track, for example). This is a recommended practice as the tracklist + interface is not designed to enable browsing through a large list of tracks, + but rather to provide clients with context about the currently playing track. +
+A mapping from metadata attribute names to values.
++ The mpris:trackid attribute must always be present, and must be + of D-Bus type "o". This contains a D-Bus path that uniquely identifies + the track within the scope of the playlist. There may or may not be + an actual D-Bus object at that path; this specification says nothing + about what interfaces such an object may implement. +
++ If the length of the track is known, it should be provided in the + metadata property with the "mpris:length" key. The length must be + given in microseconds, and be represented as a signed 64-bit integer. +
++ If there is an image associated with the track, a URL for it may be + provided using the "mpris:artUrl" key. For other metadata, fields + defined by the + Xesam ontology + should be used, prefixed by "xesam:". See the + metadata page on the freedesktop.org wiki + for a list of common fields. +
++ Lists of strings should be passed using the array-of-string ("as") + D-Bus type. Dates should be passed as strings using the ISO 8601 + extended format (eg: 2007-04-29T14:35:51). If the timezone is + known, RFC 3339's internet profile should be used (eg: + 2007-04-29T14:35:51+02:00). +
++ The name of the attribute; see the + metadata page + for guidelines on names to use. +
+The value of the attribute, in the most appropriate format.
+A unique resource identifier.
+The list of track ids for which metadata is requested.
+Metadata of the set of tracks given as input.
+See the type documentation for more details.
+Gets all the metadata available for a set of tracks.
++ Each set of metadata must have a "mpris:trackid" entry at the very least, + which contains a string that uniquely identifies this track within + the scope of the tracklist. +
++ The uri of the item to add. Its uri scheme should be an element of the + org.mpris.MediaPlayer2.SupportedUriSchemes + property and the mime-type should match one of the elements of the + org.mpris.MediaPlayer2.SupportedMimeTypes +
+
+ The identifier of the track after which
+ the new item should be inserted. The path
+
+ Whether the newly inserted track should be considered as + the current track. Setting this to true has the same effect as + calling GoTo afterwards. +
+Adds a URI in the TrackList.
+
+ If the
+ Note: Clients should not assume that the track has been added at the + time when this method returns. They should wait for a TrackAdded (or + TrackListReplaced) signal. +
+Identifier of the track to be removed.
+
+
Removes an item from the TrackList.
+If the track is not part of this tracklist, this has no effect.
+
+ If the
+ Note: Clients should not assume that the track has been removed at the + time when this method returns. They should wait for a TrackRemoved (or + TrackListReplaced) signal. +
+Identifier of the track to skip to.
+
+
Skip to the specified TrackId.
+If the track is not part of this tracklist, this has no effect.
++ If this object is not /org/mpris/MediaPlayer2, + the current TrackList's tracks should be replaced with the contents of + this TrackList, and the TrackListReplaced signal should be fired from + /org/mpris/MediaPlayer2. +
++ An array which contains the identifier of each track + in the tracklist, in order. +
+
+ The
+ If false, calling
+
The new content of the tracklist.
+The identifier of the track to be considered as current.
+
+
+ This should correspond to the
Indicates that the entire tracklist has been replaced.
++ It is left up to the implementation to decide when + a change to the track list is invasive enough that + this signal should be emitted instead of a series of + TrackAdded and TrackRemoved signals. +
+The metadata of the newly added item.
+This must include a mpris:trackid entry.
+See the type documentation for more details.
+
+ The identifier of the track after which the new track
+ was inserted. The path
+
Indicates that a track has been added to the track list.
+The identifier of the track being removed.
+
+
Indicates that a track has been removed from the track list.
+The id of the track which metadata has changed.
+If the track id has changed, this will be the old value.
+
+
The new track metadata.
++ This must include a mpris:trackid entry. If the track id has + changed, this will be the new value. +
+See the type documentation for more details.
++ Indicates that the metadata of a track in the tracklist has changed. +
++ This may indicate that a track has been replaced, in which case the + mpris:trackid metadata entry is different from the TrackId argument. +
++ Brings the media player's user interface to the front using any + appropriate mechanism available. +
+
+ The media player may be unable to control how its user interface
+ is displayed, or it may not have a graphical user interface at all.
+ In this case, the
Causes the media player to stop running.
+
+ The media player may refuse to allow clients to shut it down.
+ In this case, the
+ Note: Media players which can be D-Bus activated, or for which there is + no sensibly easy way to terminate a running instance (via the main + interface or a notification area icon for example) should allow clients + to use this method. Otherwise, it should not be needed. +
+If the media player does not have a UI, this should be implemented.
+
+ If false, calling
+
Whether the media player is occupying the fullscreen.
++ This is typically used for videos. A value of true + indicates that the media player is taking up the full screen. +
++ Media centre software may well have this value fixed to true +
+
+ If
+ If
+ This allows remote control interfaces, such as LIRC or mobile devices like + phones, to control whether a video is shown in fullscreen. +
+
+ If false, attempting to set
+
+ Note that the media player may be unable to fulfil the request. + In this case, the value will not change. If the media player knows in + advance that it will not be able to fulfil the request, however, this + property should be false. +
++ This allows clients to choose whether to display controls for entering + or exiting fullscreen mode. +
+
+ If false, calling
+
+ Indicates whether the /org/mpris/MediaPlayer2 + object implements the org.mpris.MediaPlayer2.TrackList + interface. +
+A friendly name to identify the media player to users.
+This should usually match the name found in .desktop files
+(eg: "VLC media player").
+The basename of an installed .desktop file which complies with the Desktop entry specification, + with the ".desktop" extension stripped.
++ Example: The desktop entry file is "/usr/share/applications/vlc.desktop", + and this property contains "vlc" +
++ The URI schemes supported by the media player. +
++ This can be viewed as protocols supported by the player in almost + all cases. Almost every media player will include support for the + "file" scheme. Other common schemes are "http" and "rtsp". +
++ Note that URI schemes should be lower-case. +
++ This is important for clients to know when using the editing + capabilities of the Playlist interface, for example. +
++ The mime-types supported by the media player. +
++ Mime-types should be in the standard format (eg: audio/mpeg or + application/ogg). +
++ This is important for clients to know when using the editing + capabilities of the Playlist interface, for example. +
+