Now Playing: MPRIS

MPRIS is insane. MPRIS is well-thought out. MPRIS is a standard for querying and controlling any media player without having to know the details of each player’s remote interface. MPRIS is now supported by the Now Playing data engine.

All of the above statements are true, to varying degrees.

It’s insane because it uses the same interface name (org.freedesktop.MediaPlayer) for three different interfaces (one for each of the objects /, /Player and /TrackList). This causes havoc with Qt’s D-Bus interface compiler. Luckily, just about everything I need is exported by the /Player part of the interface. Unfortunately, the only way to get the current track number out of Audacious is using the /TrackList object.

It’s well-thought out in most other respects. It has signals for information changes (something missing in Juk’s D-Bus interface). It is generally adaptable to the capabilities of most media players, without going overboard. It has a sane system of informing clients about the capabilities of the player’s interface (such as whether you can skip to the next track, for example), even if Audacious isn’t entirely honest about what is possible.

It’s a universal standard that allows clients to be player-agnostic. Or, at least, that’s the idea. Currently, I can only find one client supporting it: Audacious (although VLC 0.9.0 should include MPRIS support). And Audacious diverges from the standard in a couple of respects, most noticeably in the metadata returned for a track. It doesn’t include the tracknumber (which is optional, but it would be nice if it returned it when it made sense). It uses “length” for the length of the track in seconds, rather than “time”. And, outside the metadata, it claims every action is possible, even when it isn’t, such as stopping when nothing is playing.

The Now Playing applet support MPRIS players. Or, at least, it supports Audacious, which is the only one I’ve tested it with. And it doesn’t give a track number even then. But hey, it’s better than nothing, right? And other players should work “out of the box”, providing they don’t need any hacks like Audacious’ length/time metadata issue.

So: Juk and MPRIS players are supported. Next, I think I’ll steal XMMS support from the Kopete Now Listening plugin.

Incidentally, the player-querying code in the Now Playing engine should be general enough to use with other projects that need to get this information. One possible future change is to make them plugins that can be loaded by anyone who wants them.

PS: Is it me, or are there loads of media players that all seem exactly the same (WinAMP, Audacious, XMMS, Beep)?


Tags: ,

9 Responses to “Now Playing: MPRIS”

  1. raptros-v76 Says:

    to your PS:
    afaik, XMMS is supposed to be sort of a clone of WinAMP, Beep is the descendant of XMMS, and audacious is the descendant of Beep. so it makes sense that they are all the same; it’s a chain.

  2. ZeD Says:

    well, in the ancient time, there was WinAMP,
    then it comes X11AMP a.k.a. XMMS,
    then it forked in Audacious,
    then it forked in Beep Media Player a.k.a. BMP
    then it forked (?) in BMPx
    then it forked…

    …then will come xmms2 😀

  3. Jakob Petsovits Says:

    Well… XMMS was a clone of WinAmp. Beep forked from XMMS when XMMS moved too slowly from GTK+ 1.x to 2.x. And Audacious is another fork (the most recent one), although I don’t remember if they forked off XMMS or Beep.

    So… yeah, quite some similarity.

  4. randomguy3 Says:

    I didn’t realise that Beep was a fork of XMMS, otherwise it would have made sense (since I knew Audacious was a fork of Beep).

  5. Kevin Says:

    It is quite unfortunate that the problem of the D-Bus interface hasn’t been solved yet.

    I think it was about a year ago when I advised the developers working on it to split it into three interfaces, one for each exported object.

    Right now each of the three objects has the same interface and any implementation needs to throw exceptions (D-Bus errors) if one of the “not-implemented” methods is called.

    If you want to make this broken interface available, I recommend just implementing all methods in one object, as defined by the interface contract, and register it for all three object paths.

    If you want to make use of the broken interface using a code generator, I recommend splitting the interface into three introspection files, one for each object, and let the code generator process those.

  6. randomguy3 Says:


    The trouble with generating three objects is that they all have the same name (OrgFreedesktopMediaPlayer). There’s probably an option to change that, but I haven’t looked for it yet.

  7. Linus Berglund Says:

    I know it is not really the same thing, and most likely it is not what you are looking for, but have you tried remoot?

  8. randomguy3 Says:

    Linus Berglund: it’s not, but thanks for the link – I’ll probably be able to steal some code from it.

  9. Kevin Says:

    A little misunderstanding.
    It is not about generating three objects, but to register the same object for three D-Bus object paths.

    So if you want to implement the “interface”, just create one adaptor and register the object three times.

    As a result it really doesn’t matter which of the three paths a client is using and since all three objects officially implement the same interface anyway, it is easier to just register one multiple times.
    See QDBusConnection::registerObject()

    Of course it would be preferable to have meaningful interfaces for each of the three objects, maybe you can help the specification maintainers to fix it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: