MPRIS2 plugin is emitting position-change signals
GSConnect is a local implementation of the KDE Connect protocol for two-way communication with one or more paired Android devices on the local network, and in concert with the KDE Connect Android app, proxies various services and interactions between the device(s) and Gnome Shell in both directions. This proxying includes MPRIS2 media control, with the Android app providing status display and transport controls for any compatible media players running on the desktop.
The high CPU load was determined to be caused by the flood of Position updates emitted whenever Audacious is playing a track, due to all of those updates being proxied to the Android device. This condition is not encountered with any other media player (that we are aware of), and in our reading of the MPRIS2 spec, is improper behavior on the part of Audacious' MPRIS2 plugin.
Position — x (Time_In_Us)
The org.freedesktop.DBus.Properties.PropertiesChanged signal is not emitted when this property changes.
The current track position in microseconds, between 0 and the 'mpris:length' metadata entry (see Metadata).
Note: If the media player allows it, the current playback position can be changed either the SetPosition method or the Seek method on this interface. If this is not the case, the CanSeek property is false, and setting this property has no effect and can raise an error.
If the playback progresses in a way that is inconstistant with the Rate property, the Seeked signal is emited.
In typical operation (based on empirical testing with both VLC and MPD), an MPRIS2 server would emit the Position property only once at the start of play, or at song change. The client would then use the Position and Rate properties to run a local timer for position updates, independent of the MPRIS2 server application. Until a transport event (play stop, track skip, etc.), further signals would not be emitted except, as the spec indicates, If the playback progresses in a way that is inconstistant with the Rate property. If play is proceeding normally, it is not necessary to emit Position updates on the session bus, because the client will keep track itself based on the emitted playback parameters.
My testing was performed on Fedora 29 using the current
audacious-plugins-3.10-1.fc29.x86_64 packages. However, the current source of mpris2/plugin.cc still contains the
update() function to emit position (Lines 170-183), and the 4 Hz timer that causes them to be emitted four times per second (Line 360), so I would expect this issue to affect all releases newer than 3.10, as well as the current git HEAD.
#1 Updated by FeRD (Frank) Dana over 2 years ago
This is also related to bug #809, where the user reported a flood of errors from indicator-sound when Audacious was playing. The bug that caused the error message is indeed in indicator-sound, but as the user in that report said:
If I play something with vlc, I get this message only one time (not 4 times each second), if I use mpv, avplay or something else, I don't get the message.
#3 Updated by Andy Holmes over 2 years ago
Hi, I took the liberty of rebasing the patch you linked to so it applies the upstream's master. Hopefully this will be easier for pwithnall to review.
I really don't have much use for gdbus-codegen myself so I haven't actually tested this (not sure why the pipleline is failing, but I think it actually passes the test suite). If you have time to and can add a "works-for-me", maybe we can finally get this merged :)
Otherwise I retained Thomas Jost's authorship of the original patch in the MR, so he's been pinged as well.
#4 Updated by Andy Holmes over 2 years ago
Oops, here's the link: https://gitlab.gnome.org/GNOME/glib/merge_requests/532
#5 Updated by John Lindgren over 2 years ago
- % Done changed from 0 to 100
- Target version set to 3.10.1
- Status changed from New to Closed
I added the necessary annotation to our XML file:
Tested the gdbus-codegen patch and the signals are no longer emitted for me. Thanks!