Something is wrong with my KDE Plasma desktop environment.
I frequently encounter situations such as the Wastebin icon looking like it’s full, but contains no files. F5 on the desktop does nothing. Files are often left around even after they have been moved (F5 in Dolphin manually solves this). Thumbnails don’t update when I edit an image. And so on…
There seems to be a general problem with aggressive caching. I couldn’t find any settings related to caching, nor have I changed anything related to that from the default, yet here we are: things (icons, views, thumbnails, etc.) randomly just don’t… update. They get “frozen in time” for unknown reasons.
I no longer use the Wastebin widget, but even the “real icon” Wastebin behaves like this. Right now, for example, it appears visually to be full of waste, but the “Empty Wastebin” option is disabled, and opening it up reveals no files.
What to make of this general problem? What is wrong?
I haven’t run into this personally, but Googling “kde plasma dolphin doesn’t automatically refresh” led to this bug, which I assume is related to what you’re seeing:
Well, is there a “conclusion” from that bug discussion page? I tried to follow it but soon got lost. The last message seems to indicate that it’s still an issue to this date and that they’ve done something about it, but I don’t know for sure. So I should just assume that it will be fixed with an update “soon”?
You can look in the metadata at the top of a Bugzilla page to see its status. In that case, the status is “CONFIRMED”, which means the bug has already been documented as being reproduced, but isn’t fixed yet since it’s not in “RESOLVED FIXED” status.
If you have new information, system logs, workarounds/ideas for how to fix, etc. that would be helpful to maintainers, those can be added as comments to that bug.
I would not assume that the core issue there would be fixed with an update “soon”, since it’s been a long-standing off-and-on challenge it would seem from reading the comments.
Edited to add a reference for KDE bug triaging / what the statuses mean:
Sorry, but this makes absolutely no sense at all. Why would it matter in any way what edits the image? XnView isn’t responsible for updating KDE Plasma desktop’s thumbnails…
I only see one thing that makes no sense. If a file is edited with some tool but for whatever reason that file hangs in the tool’s limbo, then no, that file will not be updated on the desktop ( fm…whatever). Xnview has a longstanding KNOWN issue with that. If you simply Google “xnview doesn’t update edited files” or something alike, you’d know. Here’s a file on my desktop, before and after it’s being cropped in Gwenview. It is being updated instantly.
Alright. You win. I didn’t think about the file being “kept open”, which sounds crazy, but I’ve been increasingly annoyed with XnView ever since I switched to Linux, and this Gwenview thing does seem MUCH better than the image viewers available on XFCE, so I’m almost “won over” and will probably drop XnView soon. Especially as it forces me to manually update it. But although I found keyboard shortcut configuration, there seems to be no mouse configuration? I kind of need the middle mouse button to toggle fullscreen on/off…
I suspect you’re out of inotify file handles or watches. Being in this situation can trigger issues like the ones you describe.
I’d recommend installing the kde-inotify-survey package (might be called something a bit different depending on your distro’s packaging) and then reoboot. Thereafter, this thing will detect then you’re low on those resources and prompt you via a notification to increase them.
And even if you don’t see any notification about it right now, it’s useful to have that installed so that it can warn you in the future if such a situation arises.
If Debian doesn’t package that software, shame on them. It’s been out for years, and I am consistently frustrated and disappointed with Debian’s inability to provide its users with a quality KDE experience.
Moving on: all that little app really does is create an override for various preset systemd limits on inotify watches and instances. Here’s what it looks like on my system, for example:
$ cat /etc/sysctl.d/50-kde-inotify-survey-max_user_instances.conf
# This file was auto-generated by kde-inotify-survey. Manual changes will be overwritten.
fs.inotify.max_user_instances=256
You can create such a file yourself, reboot, and see if it helps.
What’s going on here is that various apps will try to watch for filesystem changes, and every time they do, this counts against the system’s default limit of how many times it can be done. I couldn’t tell you why such a limit exists, but it s easy to bump into it if you have a lot of files or a lot of software that wants to watch for file changes.
For what it’s worth, the origin of the inotify limit seems to have been a desire to be conservative when using unswappable kernel memory - if anyone reading this is interested in learning more about that feature, here are a couple links I found helpful (including suggested upper limits for that value):
And for what it’s worth… @ExXfceUser , if I can offer a thought, in my humble and ignorant user opinion, having no basis in actual development knowledge…the highlight of the Debian project is their Stable release. That release’s philosophy is curating specific releases of software that will fit together into a “whole that is more than the sum of the parts”, and that swapping out those parts for newer ones is a “FrankenDebian”, not recommended.
My observation of the KDE philosophy is one of more rapid and iterative improvements - over my five months or so of running openSUSE Tumbleweed daily, I’ve seen multiple releases of different KDE packages (Plasma Desktop, Gear apps, Frameworks, etc.), not all at the same time, and not all in one massive “this is the culmination of two years’ worth of work” push (although that no doubt does happen with things like the upcoming Plasma 6).
Take this for what it is, but I don’t feel like the “find a collection that works and stay with it for two years” approach from Debian meshes that well with the “fast iterative feature development, releasing and fixing” approach from KDE. Debian’s approach would seem to fit better with projects like (ironically, I assume, given your username) Xfce that value long-term availability of an unchanging feature set. Personally, I had a better experience using KDE products on Kubuntu with the Backports PPA, and am having an even better one on Tumbleweed, and I suspect that’s because they’re more naturally aligned with the upstream KDE model.
Take all that with many grains of salt, but just a few thoughts as I was thinking about this thread and several others.
Is really running out of inotify file handles the culprit, here? From what @dzon said earlier it seems xnview is showing the problem while gwenview doesn’t.
If both rely on inotify and if we assume it’s related to inotify but it shows in one app while not in the other, I can’t help, it feels just to work around tuning inotify settings, then, instead of looking what xnview does differently. Just a thought
and OT: I don’t feel too well just blaming the GNU/Linux Debian project here. Different distros, different release models, different decisions, different defaults, different focus, different goals… Hope you don’t mind the perspective of a complete “outsider”, here.
