D-Bus: PropertiesChanged signal does not always get emitted on track change

[selurvedu]

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

[selurvedu]

P.S. I really liked your project. For many years I couldn't figure out how to control multiple playback sources with a one-stop solution, without the need to hard-code the players and with the ability to control the media playback in web browsers. Once I noticed that KDE Connect lets me do exactly that, except it was phone-only, I knew I got closer to solving this. Then I found Empress, and it turned out to be exactly what I was looking for, the final missing piece, because Empress itself can be controlled and monitored via D-Bus.

[ray-kast]

oh oop I'm so sorry this slipped through my GitHub inbox!! i just saw all three of your issues, i'll see what i can do!

[ray-kast]

@selurvedu For this issue and #12, are you able to change how you run the empress server to pass -vvv as an argument and forward any relevant log sections from its output? I'm trying to track down where exactly this is happening in the server code.

If you're using the systemd unit file for empress, it should be as simple as replacing empress server with empress server -vvv wherever the file is installed.

[ray-kast]

Actually, addendum to this—I just pushed a bunch of changes here. This includes fixing the missing property listeners, refactoring a bunch of old player-tracking jank, and some diagnostic fixes/hacks. If you're able to build and run that (with empress server -vvv) and check whether the error is still reproducible that'd be fantastic.