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.
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.
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): http://pastebin.com/m33aec062
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 :-)
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.
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):
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: http://www.linuxfromscratch.org/blfs/view/stable/general/dbus.html
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: #!/bin/bash
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. http://www.linuxfromscratch.org/hints/downloads/files/starting-and-stopping-dbus-with-kdm.txt
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:
http://www.fi.muni.cz/~xsvobo15/moc-mpris-r2245-04-04-2010.diff
I hope you'll enjoy it.
It should apply against the commit "MOC will soon use snd_pcm_recover() (introduced in ALSA 1.0.11)." (git-svn-id: svn://daper.net/moc/trunk@2666) 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!
Ondra
hiben
Fri, 2009-07-31 09:03
Permalink
I would guess it is not
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 ?
ralesk
Sat, 2009-08-15 21:01
Permalink
Unfortunately I don’t know
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.
hiben
Mon, 2009-08-10 22:09
Permalink
Just for the record: I had a
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! :-)
lenoch
Mon, 2009-12-07 01:30
Permalink
Implementation in progress
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.
ralesk
Mon, 2009-12-07 03:14
Permalink
Cool, looking forward to it
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.
lenoch
Mon, 2009-12-07 21:05
Permalink
First patch
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): http://pastebin.com/m33aec062
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 :-)
ralesk
Fri, 2010-01-08 16:03
Permalink
Didn't try too much, but I
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 ^^;
lenoch
Fri, 2010-01-08 19:18
Permalink
Progress?
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?
ralesk
Thu, 2010-01-21 17:20
Permalink
Couldn't compile it. the
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.
ralesk
Sat, 2010-02-06 19:42
Permalink
I tried it now, and it works
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.
hiben
Sat, 2009-12-12 12:59
Permalink
Good to hear someone has
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.confon my system):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...
lenoch
Sun, 2009-12-13 00:12
Permalink
Running D-Bus on its own
Hi,
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: http://www.linuxfromscratch.org/blfs/view/stable/general/dbus.html
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:
#!/bin/bashecho "#!/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. http://www.linuxfromscratch.org/hints/downloads/files/starting-and-stopping-dbus-with-kdm.txt
lenoch
Sun, 2010-04-04 10:23
Permalink
Another patch released
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:
http://www.fi.muni.cz/~xsvobo15/moc-mpris-r2245-04-04-2010.diff
I hope you'll enjoy it.
xordspar0
Thu, 2019-11-14 04:14
Permalink
Dusting this off
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.
lenoch
Mon, 2019-11-18 17:07
Permalink
Re: Dusting this off
Dear xordspar0,
I uploaded a slightly more recent version of it here:
http://svobodasoft.cz/moc-mpris/0001-Support-seeking-with-milisecond-pre...
http://svobodasoft.cz/moc-mpris/0002-Implement-partial-MPRIS-1.0-support...
It should apply against the commit "MOC will soon use snd_pcm_recover() (introduced in ALSA 1.0.11)." (git-svn-id: svn://daper.net/moc/trunk@2666) 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!
Ondra
xordspar0
Mon, 2019-11-18 17:38
Permalink
Thanks a lot! I will
Thanks a lot! I will definitely rely on the work you did you help me get started.