Bug #849

MPRIS2 plugin is emitting position-change signals

Added by FeRD (Frank) Dana over 2 years ago. Updated over 2 years ago.

Target version:
Start date:
December 08, 2018
Due date:
% Done:


Estimated time:
Affects version:


This came up in a report from a user of the GSConnect gnome-shell plugin who was experiencing high CPU usage from GSConnect when playing music in Audacious.

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.

The MPRIS2 D-Bus Interface Specification documentation of the MediaPlayer2.Player interface has this to say about Position (emphasis mine):

Position — x (Time_In_Us)
Read only
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-3.10-1.fc29.x86_64 and audacious-plugins-3.10-1.fc29.x86_64 packages. However, the current source of mpris2/ 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.

#2 Updated by John Lindgren over 2 years ago

It is currently not possible to disable these signals due to a missing feature in GDBus, see:

This has been known for over 6 years; if you would like to see it fixed, please talk to the GNOME project.

#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.

#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!

Also available in: Atom PDF