MPRIS compatibility?


I couldn’t find anything about this in the search, I wonder if MPRIS protocol support is planned for MOC. I’d love it :)

I would guess it is not planned. The concept sounds interesting. Are there any apps supporting this on the user side ? I might try to code this just to have a reason to start working with dbus ;-) - how to you currently use players with MPRIS support ?

Unfortunately I don’t know how to work with MPRIS beyond the user level (that is, if a program supports it, I’ll get the currently playing songs and I’ll be happy :P)

Anyway, I think Amarok and Exaile are MPRIS compliant, and for one, KMess supports getting data from MPRIS to display it as a status message in MSN.

Just for the record:
I had a look at the spec and some software around MPRIS and started playing around with DBUS at a low level in C.
As it seems, I am going to create support for MPRIS in MOC but (at least) one thing remains unclear:

MPRIS seems to be centered around the idea of using the Session-DBUS for communication - and this makes sense for graphical players that perish together with X. MOC on the other hand survives X quite well (and often on my machine) and so I would rather go for the System-DBUS. Most mpris-frontends will be hardcoded to the other bus so I guess the most sane approach is to just create two connections - System and Session. As it seems there is no session-bus when not in X... need to figure it out.

Stay tuned! :-)

Hi all,

I want to inform you that I'm working on this feature as my very first contribution to an open-source project ever.
Hendrik, I hope you don't mind that I took your task, I also felt like playing with D-Bus :-) If you have anything in production we can take the best from both works.
I already have most of features done so I can control MOC using mpris-remote and lrcShow-X or the low-level dbus-send program.
Features to be done are working with a playlist (as I didn't need that yet) and telling other parties about the player capability (see the specification).
On the technical side, the communication is done in a separate server thread (also my first time :-), the low-level D-Bus API has been used and this feature is fully optional.

I have run into a few issues too:
- As Hendrik (hiben) said, the session bus runs only with X11 which just sucks. Finding a way of getting D-Bus run separately would make me really happy.
- Error handling in the low-level D-Bus library would make our code really heavy (unreadable). We should reconsider if it is worth it and either write our own light-weight binding or use some existing. OOP (C++) might help too.
- The "Play" command works only if MOC already played something.
- I can't figure out how to get (or set) the position in a song with a higher precision than seconds. This is important for better synchronization with e.g. lrcShow-X.
- A minor flaw is that when the playlist is shuffled curr_playing of course contains a track number relative to it, i.e., regardless of the real position in the playlist, it equals to 3 if the third random song is on.

If everything goes well I'll release the first preview patch sometime today (upload it somewhere?).
Until then I'll be (sleeping and then ;-) cleaning up the code and maybe even adding the missing features.

I'm sorry for not being brief, I guess I just like babbling.

Regards, Ondra Svoboda

Edit: Still cleaning up the code. I hope to publish it soon.

Cool, looking forward to it :)

For me, it doesn’t matter that it requires X, I’m one of those people who run MOCP locally and always have an X session running as well.

So here goes. It's the first try to support MPRIS (incompletely).
I added some comments (at least at the start of the main file).
Get the patch here (there's a "download" option):
Apply it using
$ patch -p0 -i patch_name
in trunk. It's aimed at revision 2228 (now current).

Have fun and I welcome your suggestions and even complaints :-)

Didn't try too much, but I couldn't get it to work; I'll probably wait for 2.5.0 to come out and the patch get ported to it ^^;

Well if you don't mind waiting till about half of February, after I have (hopefully) passed my exams, or maybe sooner, I will do my best to release some functioning code. I hope I can get it out before an eventual stable release (although I think it gets released when there are new features that have been in testing for long enough).
Not much has changed from the last time.
BTW what didn't work? I know the code at pastebin already expired but still, couldn't you patch the latest trunk, or was there an error while configuring/compiling, or did it simply not work when MOC was running?

Couldn't compile it. the particular revision your patch was made for didn't want to compile and I didn't have enough time to mess with 2.5.0 alphas, unfortunately. I think waiting for a beta and then porting your code to it might be better ^^ We'll see, I'll check back here when I have a moment to breathe.

I tried it now, and it works great :) Thank you :)

2.5.0~r2245, with --without-aac because it can't find the headers provided by our libfaad2-dev package for whatever reason.

Good to hear someone has picked it up. I really do not mind as I am currently not actively developing in that direction (I'm spending all my current 'moc-time' to fix the somewhat broken MIDI plugin).
Currently I have some proof of concept code but no integration with MOC (had to learn how to use dbus containers in low level C, fun but took some time...).

I don't think I want to go further with MPRIS as I got a bit frustrated with the spec. Many of MOCs features just can't be used. The MPRIS specification needs a mechanism for dynamic extensions... but I don't see a lobby big enough to develop the spec. Don't get me wrong: MPRIS is a nice idea but the current state of the spec is totally tailored to XMMS-like players...
Timing on second-granularity is one thing but you cannot even control the volume from MPRIS as you cannot select a mixer...
Using a C++ API for DBUS is a tempting solution but I am not sure if it is worth polling something more complex than moc into moc... :-)

I yet had no time to use your patch but I am looking forward to do so. If I understand correctly, you implemented MPRIS on the session-bus. I still believe, there should be always two connections: one to system and one to session (if the session dies, just look from time to time if it comes back). Should be no problem to monitor both from a single thread.
You still need to punch some holes in the system-dbus security model. If this is of interest for you, I used to following configuration (placed in /etc/dbus-1/system.d/moc.conf on my system):
<br /> &lt;!DOCTYPE busconfig PUBLIC<br /> "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br /> ""&gt;<br /> &lt;busconfig&gt;<br /> &lt;policy group="audio"&gt;<br /> &lt;allow own="org.mpris.moc"/&gt;<br /> &lt;/policy&gt;<br /> &lt;policy context="default"&gt;<br /> &lt;allow send_interface="org.freedesktop.MediaPlayer"/&gt;<br /> &lt;allow<br /> receive_interface="org.freedesktop.MediaPlayer"<br /> receive_sender="org.freedesktop.MediaPlayer"<br /> /&gt;<br /> &lt;/policy&gt;<br /> &lt;/busconfig&gt;<br />

This allows anyone in the audio-group to connect (as a service (player)) to the system bus as 'org.mpris.moc' and all clients can use the org.freedesktop.MediaPlayer interface.
Hope this can be of some help...


I found a way of having one session D-Bus available to both X session and consoles (on Arch Linux).
What started this was this LFS page:
I then read the dbus-launch man page which aided me to learn that if dbus-lauch is run without a parameter like gnome-session (which it runs) it prints out environment variables DBUS_SESSION_BUS_ADDRESS and DBUS_SESSION_BUS_PID.
So I made a small script ~/bin/run-dbus with the following content:
echo "#!/bin/bash" > ~/.dbus-session
dbus-launch --auto-syntax >> ~/.dbus-session
chmod +x ~/.dbus-session

You can run it with your init scripts under your user name. (I will do so myself and post what I came up with.)
Then I added a line to my .bash_profile:
. $HOME/.dbus-session
And finally modified the /usr/bin/startx script which I still use to run X manually. (I should consider getting myself a *DM.)
There was "unset DBUS_SESSION_BUS_ADDRESS" which I "commented".
If you use a *DM you will instead have to change *DM's configuration.
Edit: I also remember doing chmod -x on /etc/X11/xinit/xinitrc.d/30-dbus which I originally wanted to modify to reuse the env. variables from console...

This finding has been made about an hour ago but I couldn't resist posting it here quickly :-)
I will post complete steps once I have completed this change at my box.

Edit: Wow, I was not the first to discover this.

Hi all,

I finally got myself to do something just before new exams came up. I reordered the code and commented it. I was having challenge working on code for adding/deleting items from playlist, but had to give up. Luckily, because I would never release anything in a reasonable time ;-) The need for a new patch has also been high because the original one disappeared from the web a long time ago. Sorry for the delay.

So, how is it going?
There are a couple of issues left to solve.
- I have to cope with the fact that in MOC there are multiple instances of clients (so there may be several different playlists) and volume setters (mixers).
As for the clients/playlists, how about making the last used client (accessed by the user) the one to communicate with over MPRIS?
For the latter I propose MOC's software mixer to be controlled by MPRIS methods when there is no way to choose from two other mixers. (And by the way, I miss a possibility to mute/unmute the current audio device from inside MOC.)
- Getting the number of a track in a playlist, especially when it has been moved up/down and the playlist is shuffled, is magic for me. I think the solution lies down in the menu code.
- I'm still not telling the other side what MOC's "capabilities" are at a time. These include: are metadata available, is it possible to pause, to go to the next/previous file and others.
- I still send no fallback metadata when the audio file has no tag.
- I also don't inform when a playlist changed.
- MOC doesn't start playing when the Play command is used right after startup.
- And as I said, you can't add or remove tracks from the playlist.

What I consider solved:
- Using the system (D-)bus will not be implemented. We learned that it is possible to run the session bus universally and without X. No other players or other applications use the system bus for MPRIS functionality or expect that anyway.
- What if the session bus was not running or died? I was developing some code to restart the MPRIS thread via a command line parameter, but found that quite an overkill in the end. It sure is possible to finish this, though.
- I got a high enough (50 ms, configurable) precision when getting the time in a song. The other way, setting the position in a song with a higher precision, is not necessary and would IIRC need changes in decoder plugins.

What I haven't looked at yet are those D-Bus configuration files. I will have to look at it when I'll be finishing my work and getting it upstream.

Now I guess I said all that had to be said, so here's the patch:
I hope you'll enjoy it.

Does anyone still have a copy of the patch? The link above is a 404 now.

I would very much like to dust this off and get it merged into master, even if it involves starting from scratch.

Dear xordspar0,

I uploaded a slightly more recent version of it here:

It should apply against the commit "MOC will soon use snd_pcm_recover() (introduced in ALSA 1.0.11)." (git-svn-id: svn:// from Wed Aug 27 07:31:35 2014 +0000.

Please pardon the (unfinished, raw) state it is in. It was however sufficient for me at the time (almost 10 years ago?!). I was able to use lrcShow-X with it, and later osdlyrics.

I hope the patch(es) will help you at least a little, to get started. Good luck!

Thanks a lot! I will definitely rely on the work you did you help me get started.