[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 Nate Graham changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #8 from Nate Graham --- Incredible, I can reproduce the issue with the steps in comment 6. Seems like there are shenanigans with the image that we need to sort out. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 --- Comment #7 from nyanpasu64 --- Incredibly I've found that *playing* the second file *on another computer* (in Audacious) can *remotely* trigger >100% CPU usage. - Both computers are running KDE and linked via KDE Connect. - I played 2album.flac in Audacious media player (VLC should also work?). I think this transmits the album art to the computer sitting on its lock screen. - Pausing the player stops CPU burn until I next stop and start playback (unpausing doesn't resume CPU burn). I suspect this is because the lock screen defaults to "No title\n Choose player automatically". The CPU burn only happens when the screen is *black*. If I wait for the password field to disappear (but the clock is still visible), then start playback, I can no longer trigger CPU burn (even with screen off) until I unlock and lock the screen again. I think this is because the album art QQuickImage gains a "stable" size (rather than infinitely looping) and keeps it for the remainder of the process lifetime. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 --- Comment #6 from nyanpasu64 --- Created attachment 182340 --> https://bugs.kde.org/attachment.cgi?id=182340&action=edit Test audio files used to reproduce CPU burn in VLC. I reproduced the bug by loading these two tracks into the VLC playlist (visible by pressing Ctrl+L in VLC). - Extract the ZIP file to a folder, and open it in Dolphin. - Ensure Dolphin is sorting by name, so 01blank.ogg comes first. - Select both files, right-click, Open With > VLC. (Turn down your volume if necessary!) - Press Win+L to lock the screen, then Esc to hide the UI, before 01blank.ogg finishes playing (takes 15 seconds). Once 01blank.ogg finishes playing, 02album.flac will play and the CPU burn will begin. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 --- Comment #5 from Nate Graham --- Could you attach two tracks that can be used to reproduce the issue? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 --- Comment #4 from nyanpasu64 --- mpd is a media player daemon that allows you to play songs on a server while controlling it remotely through desktop or web apps (like MyMPD server, MALP on Android, or KDE Connect to interact with mpd-mpris). If you're willing to wait longer, you can *wait for a song to finish playing* and move on to another one with album art (I cheated by seeking to the end of the previous song and waiting for it to finish). I think the bug specifically happens with the "Fire Emblem Fates from khinsider" album art (1112x1112), and some Touhou songs in the past. It does *not* happen with the Xenogears OST from 81summer.blogspot.com (warning, janky website) album art (400x400); playing the song with screen off does not trigger CPU burn, but waking the screen *prevents* subsequent CPU burn with the screen off. I wonder if the picture has to be sufficiently large to trigger the infinite loop, but don't want to try gdb debugging right now. Just as a proof of concept, I replicated this bug *without mpd* but just using a bog-standard *VLC media player*. I set a playlist to first play an untagged song, then a song from Fire Emblem Fates (any song should work, Lakeside Song is the smallest file size). After initiating the first song, I locked the screen and pressed Esc to hide the lock screen. Once the second song started playing, ssh->htop revealed that kscreenlocker_greet was burning over one CPU core. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 --- Comment #3 from Nate Graham --- So you have to change the song manually while the screen is locked? How exactly are you accomplishing that? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 --- Comment #2 from nyanpasu64 --- Simpler reproducer: - Locate a song with album art: lock the screen, then switch songs until album art appears on the lock screen. Then unlock the screen. - In mpd, play a song with no album art. - In KDE, lock your screen and press Esc for the screen to go dark. - In mpd, switch to playing a song with album art. I've tested this three times and gotten CPU burn each time, with no failures to reproduce (so far). This bug may also happen when a regular music player switches songs, though I have not tested. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 Nate Graham changed: What|Removed |Added CC||[email protected], ||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 503827] When changing songs with screen blanked, kscreenlocker_greet burns over 1 CPU core reloading media control icon
https://bugs.kde.org/show_bug.cgi?id=503827 --- Comment #1 from nyanpasu64 --- Created attachment 180987 --> https://bugs.kde.org/attachment.cgi?id=180987&action=edit Different terminal log of stack traces. I've done a great deal of debugging about this issue. - The bugged state is an infinite loop of QQuickImageBase::requestFinished (std::swap(d->pendingPix, d->currentPix)) → QQuickImage::pixmapChange → QQuickImage::updatePaintedGeometry → QQuickItem::setImplicitSize(full image dimensions) → QQuickImage::geometryChange → ...(property bindings) QQuickImageBase::loadPixmap (d->pendingPix->load(the same image again)). - The bug does *not* happen if QQuickImage::updatePaintedGeometry operates on a d->currentPix of size 108x108 (*not* full image dimensions). This translates to setImplicitSize(108, 108), exactly twice the image item's existing dimensions of 54x54 (is this a DPI scaling thing? I'm on 1.25x.), which never calls QQuickImage::geometryChange. - I forgot what I did to exercise this test case... maybe lock the screen with a song playing *then* switch songs? - TODO what controls the size of pendingPix/currentPix being loaded? - If you only play one song, the bug sometimes but not always happens. - Debugging tip: you can use `loginctl unlock-session 2; sleep 1; loginctl lock-session 2` to restart the lock screen. What normally happens? - The album art is normally set by OrgFreedesktopDBusPropertiesInterface::PropertiesChanged → ... PlayerContainer::updateFromMap (this=, map=) at /usr/src/debug/plasma-workspace/plasma-workspace-6.3.4/libkmpris/playercontainer.cpp:638. - In one of my runs, `QQuickLayout::updatePolish -> ... QQuickGridLayoutItem::setGeometry -> ... QQuickItem::geometryChange` loaded the same image a second time after D-Bus/PlayerContainer set it initially. - TODO does this terminate the CPU usage when you wake the screen? What controls the size of an image being loaded? - QQuickImage::updatePaintedGeometry() checks d->currentPix->width() and height(). These come from QQuickImageBase::loadPixmap (d->pendingPix->load(the same image again)), and the subsequent callback QQuickImageBase::requestFinished (std::swap(d->pendingPix, d->currentPix)). - QQuickImageBase::loadPixmap passes in d->sourcesize. This has width 0, and height 108 with the UI visible and 1976 with the UI blanked (during the bug). I wonder if QQuickLayout::updatePolish above sets the size. With the image hidden, why does QQuickItem::setImplicitSize detect a geometry change? - QQuickItem::setImplicitSize() sets d->implicit*, then calls d->width.setValueBypassingBindings(w) etc. on the input pixmap's size (matching the album art's size). This should ensure the next call with the same size sees wDone = hDone = true, returning before the call to geometryChange(). Why does d->width get set to 0 before the next call? - If I run `p &(d->width.val)\n (double *) 0x64c7333990f0` and `watch *(double *) 0x64c7333990f0`, this shows that QQuickItem::setImplicitSize() is setting d->width = (image width). If I run `fin`, on the same line *without the function even returning* it sets d->width = 0. - Not sure, it appears the first call to geometryChange has some inline function frames which invoke QQuickItem::setImplicitSize() to 0 (missing in gdb's bt)? How many d->pendingPix->load() requests are in flight simultaneously? - IDK. 1? mpd-mpris only leaves one image in /tmp/mpd_mpris/ at a time, all old ones are deleted. How do you prevent this CPU burn incident? - IDK, maybe don't try to load an image while the UI is hidden? - Is this an upstream Qt Quick bug with QQuickItem::setImplicitSize failing and hitting undefined behavior? - I don't know how all the QML bindings are arranged that QQuickImage::geometryChange tries to decode the image again. -- You are receiving this mail because: You are watching all bug changes.
