The song progress bar does not update meaning it does not show where you are on the track it never moves from its place of rest. Also, it now show time remaining on tracks playing it never moves from 0:00:00
What Phonon backend does your system use? I'm assuming it's the PulseAudio backend, though I'm not sure if you have an easy way to test Phonon's GStreamer backend or VLC backend directly. The reason I ask is that JuK's track playback information is fed directly from the underlying Phonon library's media object. So if the track position does not update then it would likely be a Phonon issue, or somehow the Qt signal/slot connections to the TrackPositionAction are being blocked. But those connections are practically guaranteed at compile time at this point so that is not the most likely cause.
Same issue here on KDE Neon which uses the VLC backend. I don't recall whether it updated using the gstreamer backend (in opensuse TW), but I have a hunch that it did.
Created attachment 111586 [details] attachment-9853-0.html Latest Juk works fine now. I still don't know the cause of the problem but thanks for your feedback. On Thu, 8 Feb 2018, 02:07 Michael Pyne, <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=389907 > > --- Comment #1 from Michael Pyne <mpyne@kde.org> --- > What Phonon backend does your system use? I'm assuming it's the PulseAudio > backend, though I'm not sure if you have an easy way to test Phonon's > GStreamer > backend or VLC backend directly. > > The reason I ask is that JuK's track playback information is fed directly > from > the underlying Phonon library's media object. So if the track position > does > not update then it would likely be a Phonon issue, or somehow the Qt > signal/slot connections to the TrackPositionAction are being blocked. But > those connections are practically guaranteed at compile time at this point > so > that is not the most likely cause. > > -- > You are receiving this mail because: > You reported the bug.
The bug is still present for me in version 18.04.0. I'm using KDE Neon.
This bug only occurs when using the VLC Phonon backend. It's working normally with the GStreamer backend. juk: 18.04.0 phonon-qt5: 4.10.1 phonon-qt5-vlc: 0.10.1 phonon-qt5-gstreamer: 4.9.0
Thanks, that helps at least track down what might be the cause of the bug (I normally use Phonon with GStreamer myself).
It looks like PlayerManager::slotTick is never called when using the VLC backend (checked with a simple qWarning in the method). The MPRIS-based Plasma applet seems to report the time correctly.
Proposed fix: https://phabricator.kde.org/D15222
Git commit 665a629e914d5d08bcf0dacd553fa4a382c798f2 by Luigi Toscano. Committed on 02/09/2018 at 20:41. Pushed by ltoscano into branch 'Applications/18.08'. Set the tick interval, because the default value is 0 Summary: With this change the time is correctly updated also when using the VLC backend. It worked for some reason with phonon-gstreamer, but it looks like it's just by accident. In fact, according the documentation, the default value of the property is 0: https://api.kde.org/phonon/html/classPhonon_1_1MediaObject.html#ae0f0ab91c97a1f3495ed9467048bb81a The choosen value (100) should allow for a fluid scrolling of the progress element, without having a too small resolution, and it seems to match the resolution of the gstreamer backend anyway. Test Plan: The time is updated on both the progress bar and the status bar with both VLC and GStreamer Phonon backends. Reviewers: mpyne Reviewed By: mpyne Differential Revision: https://phabricator.kde.org/D15222 M +2 -0 playermanager.cpp https://commits.kde.org/juk/665a629e914d5d08bcf0dacd553fa4a382c798f2