playerctld: a proxy daemon for the active player #161
Labels
Comments
This was referenced Jan 11, 2020
|
Just some feedback, this works really well, thank you very much! |
kdesysadmin
pushed a commit
to KDE/kdeconnect-kde
that referenced
this issue
May 20, 2020
playerctld (altdesktop/playerctl#161) is a proxy daemon for the currently active player by playerctl, which facilitates managing mpris players, forwarding requests to the currently active/last active player, and sorting out troubles with selecting the correct player manually. Unfortunately, it also creates an annoying issue with kdeconnect: when playing media on the phone, kdeconnect publishes the state to the computer through the mprisremote plugin - then, playerctld picks it up as active player, and registers its own mpris media player. As a result, the mpriscontrol plugin sees this as a running media player, and in turn, publishes the state back to the phone, essentially creating another media session on the phone, resulting in two notifications. As playerctld is _always_ only a proxy to another media player (or kdeconnect), it can safely be ignored, just like kdeconnect itself already is. This commit adds an if check doing exactly that.
|
Before I learnt about this daemon a zenity prompt with a list of available players that was saved to a file and read on each playerctl invocation was my solution, but will definitely give playerctld a try now. |
|
Thankyou!!! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A lot of people are having trouble managing multiple media players with Playerctl. They would like it to always control the last "active player". This definition needs some fleshing out, but I think it approximates something like the last player to do some action like play, pause, switch track, open, etc.
This cannot be accomplished with a one-off command because we don't have access to the history of player actions. It could be accomplished if we had a daemon running to monitor player actions and contain the logic to determine what is the most active one.
To accomplish this, we could add a new binary to Playerctl called
playerctld. This should be activatable so it can be launched on demand by Playerctl (dbus supports this I think).The daemon will implement
org.mpris.MediaPlayer2.Playeras a proxy to the active player. So callingPlayon this interface will cause the active player to play by calling that method on the player and returning its result.If we take the name
org.mpris.MediaPlayer2.playerctld, we can integrate this functionality into Playerctl without any modifications to the main binary, except maybe to activate the service on demand.In this case, playerctld will give the command to whatever it decides is the active player.
More interfaces could be added to
playerctldat a later time to facilitate third-party widgets and other desktop tools to better integrate with Playerctl and the desktop.Feedback on the approach is welcome.
The text was updated successfully, but these errors were encountered: