Albert is virtually unresponsive with LightlyShaders enabled (Plasma 6.0.2, Wayland, Arch w/ CachyOS packages) about albert HOT 15 CLOSED

Update: Albert just became fully responsive again after a few minutes of waiting. journalctl -b 0 | grep 'albert' (new log entries):

Mar 14 04:34:33 fezzedone-MSI systemd[11684]: Started albert show.
Mar 14 04:34:33 fezzedone-MSI kwin_wayland_wrapper[17820]: Albert set visible.

Nothing from Lightly though. This has happened before. Whenever I log in, Albert apparently ends up becoming very slow and unresponsive for a few minutes, then mysteriously becomes responsive after several minutes have passed, with no relevant log info explaining what happened. I didn't touch Albert's configuration at all, and I already had disabled Albert's file indexing before this login to rule that out.

from albert.

Run it with QT_LOGGING_RULES='*.debug=true' albert

from albert.

I just found out what caused the unresponsiveness — it's the NVIDIA driver, which also caused a seemingly unrelated kernel freeze (usually with no logs on my end) a few minutes after waking my laptop from sleep. The latest NVIDIA 550.x driver update apparently fixed both Albert's unresponsiveness and (most likely) the kernel freeze. I checked — Albert was immediately responsive as expected when I uninstalled the older, bugged NVIDIA 550.x driver for a test. This issue (as well as my system freezes) now seems to be resolved.

from albert.

Looks like the Albert bug is still there, although testing reveals that the unrelated kernel freeze bug appears to be fixed.

from albert.

Here is my debug log, although Albert is apparently responsive when I restart it after the login freeze.
albert-debug.log

from albert.

Oh, one more thing — Albert is unresponsive for several minutes whenever it's autostarted by Plasma or launched from a launcher in Plasma, but not when I run it from a terminal. I do pass --platform xcb to Albert whenever it's launched via Plasma though, something I don't do via the terminal.

from albert.

Does it happen when run with xcb from terminal?

from albert.

Managed to capture a debug log from an unresponsive instance of Albert. And no, it doesn't happen when invoked from a terminal with --platform xcb. It always happens when it's autostarted, and sometimes happens when it's manually started from a Plasma launcher.
albert-autostart-debug.log

from albert.

nothing special in the logs. Can you please adjust the exec line in .config/autostart/albert… to run with -n or --no-load ? just to see if the core and frontend work as expected?

from albert.

With -n, Albert is apparently fully and immediately responsive when autostarted. Debug log:
albert-autostart-debug-2.log

from albert.

Here are my enabled plugins:

• Applications
• Calculator
• Chromium
• Clipboard
• MPRIS
• SSH
• System
• Terminal
• URL Handler

Note that there was some unresponsiveness when I clicked «Applications» the first time, but not afterward.

from albert.

With some sort of binary search you need about 3 reboots to find the plugin causing the issue. 😄 (assuming it is only one of them). reminds me of ddmin.

from albert.

 step | delta | test case                | test
------------------------------------------------
   1   |   1   | [1, 2, 3, 4] .  .  .  .  | pass
   2   |   2   |  .  .  .  . [5, 6, 7, 8] | fail
------------------------------------------------
   3   |   1   |  .  .  .  . [5, 6] .  .  | pass
   4   |   2   |  .  .  .  .  .  . [7, 8] | fail
------------------------------------------------
   5   |   1   |  .  .  .  .  .  . [7] .  | fail  (minimal input)
------------------------------------------------
result |                           [7] 

like that src

from albert.

Uh, I just got something relevant to the issue in KDE's autostart logs for Albert (link expires in 24 hours). Turns out I got a GPU (or GPU driver) error when I closed an unresponsive Albert instance this afternoon.

from albert.

Okay, so updating the NVIDIA driver to 550.67 fixed this issue. Here's the relevant change from their changelog:

• Fixed a bug that caused wgpu applications to hang on Wayland.

Which is weird because the Intel iGPU is what's being used for desktop rendering. Then again, the NVIDIA driver was causing a more serious issue (kernel page faults / panics) for me, even though every single time that issue happened, nothing was running on the NVIDIA dGPU.

from albert.