Created attachment 165512 [details] Screen of bug. There is both applet and systemsettings (OK) view. *** There is no devices shown *** STEPS TO REPRODUCE 1. Open applet extended view (left click) 2. See results 3. OBSERVED RESULT No devices shown EXPECTED RESULT Devices are shown SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.7.0 beta 2 ADDITIONAL INFORMATION This is pipewire used + bluetooth headphones. On Systemsettings is all OK.
There is pipewire and pipewire-pulse. I assume than these socket name is not handled.
Does the following command also have the problem? `QT_LOGGING_RULES="org.kde.plasma.pulseaudio=true" plasmawindowed org.kde.plasma.volume` If so: please attach the output. If not: does the plasma applet have this problem across reboots or was this a one-off issue?
It was one-off, across reboots is looks like semi-normal.
In case you have persistent journald enabled can you take a look if you have the output "context kaput" and/or "Giving up after" My best guess is that pipewire was or restarting or something and we failed to re-establish a connection to the daemon.
There is some fragments in log: фев 03 23:40:31 archlinux systemsettings[3012]: org.kde.plasma.pulseaudio: Settings schema org.freedesktop.pulseaudio.module-group is not installed фев 03 23:40:31 archlinux systemsettings[3012]: org.kde.plasma.pulseaudio: Settings schema org.freedesktop.pulseaudio.module-group is not installed фев 03 23:40:31 archlinux systemsettings[3012]: org.kde.plasma.pulseaudio: Settings schema org.freedesktop.pulseaudio.module-group is not installed фев 03 23:42:36 archlinux plasmashell[1369]: kpipewire_logging: PipeWire remote error: -2 target not found фев 03 23:42:36 archlinux plasmashell[1369]: kpipewire_logging: PipeWire remote error: -2 unknown resource 3 op:7 But I do not know WTF it is.
Created attachment 165547 [details] Full Plasma log from those boot There is a full Plasma log with a bunch of Pipewire errors.
Sounds unrelated. I doubt we'll get to the bottom of this since it's not reproducible. That being said, we currently have no proper error reporting when the daemon connection explodes, so I think we'll just resolve this bug by adding some more useful output in the hopes that future issues like this will become easier to debug.
Sounds eminently sane.