indicator-sound-developers team mailing list archive

[Johannes Sasongko <sasongko@xxxxxxxxx>]

Hi all,

Some comments about the spec draft, from Exaile's perspective. (Though
I haven't really looked at the TrackList interface because we're
unlikely to implement it.)


> Each media player must request an unique bus name which begins with org.
> mpris.

I discussed this a bit with Jorge. It's not pretty, but it gets the
job done when you want clients to be able to select which player to
talk to; we couldn't come up with a better solution. I'd suggest
placing it under another namespace, though, perhaps org.mpris.players.

Another thing that can help simplify the interaction with clients is
this: in addition to grabbing the player-specific bus name, each
player also tries to grab a well-known bus name (e.g.
org.mpris.MediaPlayer). The D-Bus queuing mechanism [1] will take care
of which player holds the name, and a simple client can just connect
to this well-known bus name without caring about choosing one
particular player.

[1] http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-names


> org.mpris.MediaPlayer

Should have a method to present / show / activate / bring up the
actual player. I'll leave you to choose the best name for this.


> org.mpris.MediaPlayer.TrackList

> GetTracksMetadata ( as: TrackIds ) → aa{sv}

Should we have a GetAllTracksMetadata method as well? This would cater
for the common case of startup, rather than requiring the client to
send in all track IDs.

Also, perhaps clients should be allowed to specify which metadata they
want to accept, to reduce traffic (not that interesting unless we're
looking at Alex's scenario of pulling up a huge playlist).


> org.mpris.MediaPlayer.Player

> Repeat ( b: State ) → nothing
> GetStatus ( ) → (iiii)

These have a few problems:
1. repeat_current and endless can be thought of one status, as they
are mutually exclusive.
2. There is currently no way to set the shuffle and endless statuses.
3. The Capabilities property should include whether these statuses can
be set at all. For example, Exaile doesn't support repeat_current,
while a Last.fm player can't set any of them.
4. Naming: Repeat here should be SetRepeatCurrent.


> Position − i (Time_In_Ms), read-only

There should be an note that--to change the position--the client needs
to use SetPosition, which works around the issue of race conditions by
requiring the track ID.


Next, from http://xmms2.org/wiki/MPRIS_Metadata :

> "time"
> (uint32) The duration in seconds
> "mtime"
> (uint32) The duration in milliseconds

For consistency with Position and SetPosition, I believe this should
be "length" and always in milliseconds.


That's it for now, I think. I'm quite happy with the direction, and
especially that Alex Merry covered a lot of my concerns with MPRIS v1
in last month's discussion.

Cheers,
Johannes