Project

General

Profile

Bug #855

[Re-opened][KDE respones]KDE Media Player widget display glitchy countdown and progress bar.

Added by kevin tee over 5 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
December 28, 2018
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

I filed this bug on Audacious before here:
https://redmine.audacious-media-player.org/issues/853
Sorry, I don't know how to re-opened that thread.

I filed this bug to KDE here: https://bugs.kde.org/show_bug.cgi?id=402585
They basically said that Audacious did a different implementation than specification. Therefore, causing the glitch.
The message below is a direct quote from the assignee for KDE bug.

From the docs:

"
Position — x (Time_In_Us)
Read only
The org.freedesktop.DBus.Properties.PropertiesChanged signal is not emitted when this property changes. "

https://specifications.freedesktop.org/mpris-spec/latest/Player_Interface.html#Property:Position

From your output:

signal time=1546016973.985605 sender=:1.479 -> destination=(null destination) serial=171 path=/org/mpris/MediaPlayer2; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.mpris.MediaPlayer2.Player"
array [
dict entry(
string "Position"
variant int64 27887000
)
]

repeatedly.
Which is going against the spec.

Please send it back to them with this info.

If they argue let me know and I'll jump in the discussion.


We can maybe just ignore these updates on the KDE side and work round it, but then we risk breaking some other obscure client that also doesn't follow the spec properly.

History

#1 Updated by John Lindgren over 5 years ago

  • Status changed from New to Rejected

The PropertiesChanged signal is a known bug in GDBus. See #849.

There is a patch recently merged that fixes it:
https://gitlab.gnome.org/GNOME/glib/merge_requests/532

You will need to wait for the next GDBus release and then rebuild Audacious to pull in the fix.

Nevertheless, I fail to see how this could "cause" the glitchy time display that you see in KDE. The Position property itself is accurate, as far as I know, and that should be all that KDE needs to display the correct time.

Also available in: Atom PDF