As far as I can tell, empress now-playing returns just 4 json values, no more & no less (unless I'm missing something):

It would be nice to have the active player title returned as well, similar to playerctl metadata.

On a side note: is the "artist" field supposed to be an array?

This would allow integrating empress with e.g. WM bars/panels without extra quirks, similar to playerctl metadata -F.

Related to #11.
I don't know how to properly describe the steps to reproduce this, but this happens quite often with different players.

I tested this with different players, and got different results.

With Exaile and Strawberry, everything works pretty much as expected.

With Audacious and Spotify, the signal does not get emitted on track change, only on play/pause.

With Quod Libet and Qmmp, the results are quite weird. The signal does get emitted, but rather than containing data for the new track, it always contains the data for the previously playing track (the one that has finished playing or the one the user manually switched from).

I opened QDBusViewer and connected to PropertyChanged signals on both Empress and the player in question.

For Audacious and Spotify, I saw the player emitting the signals properly with correct track info.

For Qmmp, I noticed it sometimes emits a "Stopped" playback state and no track info, and then emits another one with the "Playing" state and the new track info. I guess that's what gets Empress confused.

I couldn't test this on Quod Libet because of the following error:

Error: Unable to connect to service org.mpris.MediaPlayer2.quodlibet, path /org/mpris/MediaPlayer2, interface org.freedesktop.DBus.Properties, signal PropertiesChanged

Currently I'm emulating this by reading the bus name of the currently active player from Empress and then invoking the Raise() method on the corresponding MPRIS interface. Of course, this method is not available for all players – for instance, it doesn't work for Chromium-based browsers.

Currently, it seems that the only way to format the empress now-playing output is by using an external program like jq. This is nice and flexible, but the performance hit is terrible:

Compared to playerctl metadata with built-in filters (as far as I can tell):

IMHO output filtering of some sort is crucial if one wants to integrate empress/playerctl/whatever with their desktop. In my case, output filtering is used in a custom Waybar module (custom/media).

bro you just committed cringe

you are going to lose star... 😞

The current D-Bus bindings crate appears to be dead or dying, and the zbus crate (hosted on FreeDesktop's own website) seems like it is now picking up traction and also looks to contain a cleaner API for implementing an interface. I'll need to do some testing to see if it fits my use case but making the switch would likely make working with D-Bus easier going forward.

Presently when the daemon is searching for a player to execute a command, it uses the first player which can successfully respond to said command. However, due to varying capabilities of different players, this can result on different commands being sent to different players, often in counterintuitive ways.

This ticket may require bumping the D-Bus protocol to v2 for allowing the methods to accept a map of player query filters, so that a single unified player search function can be implemented while still allowing users similar functionality to v1 if desired.