https://bugs.kde.org/show_bug.cgi?id=527379
Bug ID: 527379
Summary: Opening a local image stalls 3-5 seconds when Recent
Folders has a folder on a slow network mount
Classification: Applications
Product: gwenview
Version First unspecified
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
For the past couple of days Gwenview has been randomly taking like 3-5 seconds
to show normal JPGs and PNGs. Usually it's super snappy, so it was really
noticeable. And the images were on my local disk.
I used Claude to dig into it, and turned out that it had nothing to do with the
image at all. I have Google Drive mounted with rclone at ~/Cloud/gdrive, and at
some point I'd viewed a few images from there, so those Drive folders ended up
in Gwenview's Recent Folders. Claude found that every time Gwenview starts, it
checks whether each recent folder still exists, and it waits for that before
showing the image. When rclone's cache has expired (5 min by default), those
checks have to go all the way to Google's servers, so the window just sits
there waiting.
That's also why it was only slow sometimes. Right after opening an image,
everything is cached (in rclone) and the next image opening is instant, but
after a few minutes the image opening is slow again.
STEPS TO REPRODUCE
1. Have a slow network/FUSE mount (I use rclone for Google Drive with default
cache settings, but I'd guess NFS/SMB/sshfs/a sleepy NAS may do the same).
2. Open an image from a folder on that mount in Gwenview so the folder gets
added to Recent Folders. Close Gwenview.
3. Wait more than 5 minutes so the cache expires (rclone, or whatever else you
may test it with).
4. Open any image from your local disk, e.g. from Dolphin.
OBSERVED RESULT
3 to 5 seconds of waiting before the image shows up.
EXPECTED RESULT
Image opening in less than 0.5 seconds as it usually does.
SOFTWARE/OS VERSIONS
Operating System: Garuda Linux, kernel 7.2.11-1-cachyos, Wayland
KDE Plasma Version: 6.8.0
KDE Frameworks Version: 6.31.0
Qt Version: 6.12.0
Gwenview: 26.08.2
rclone: v1.75.2 (--vfs-cache-mode full, default --dir-cache-time 5m)
ADDITIONAL INFORMATION
What Claude measured (I asked claude to prepare this part):
- From journalctl, slow opens took 2.9 s, 3.8 s, 3.8 s and 5.2 s until the
image started loading. Normal opens take 0.3-0.6 s.
- Claude sampled the gwenview process during a slow open. The main thread was
blocked in newfstatat() on the FUSE mount (wchan fuse_chan_send) for about 5.3
s, right after the debug log printed "Checking for plugins in ... kf6/purpose".
The listing of the local folder only finished after that (5.5 s).
- Just running `stat` on the three Drive folders from Recent Folders, with the
rclone cache expired, took 2.6 s + 0.5 s.
- After removing just those Drive entries from
~/.local/share/gwenview/recentfolders/, the same open took 0.18 s with zero
waits on the mount.
THE FIX
Turning off "Remember folders and URLs" and clearing the history keeps it fast
again for it doesn't hold up the image while it checks with rclone.
SUGGESTION:
You may ignore this part if it isn't sound :). But what I think is that,
Gwenview should open the image instantly while the folder check runs in the
background. That way a slow folder will not hold up the image.
Also, I am not sure if it's a regression or has always been the case. I noticed
it right after updating (Gwenview 26.08.1 -> 26.08.2, Frameworks 6.30 -> 6.31,
Qt 6.11 -> 6.12), but the Drive folders were already in my history before that.
So either something changed around when the check runs, or I just hadn't
noticed before, I don't know.
Thanks for taking the time to read this, and thanks for keeping Gwenview up and
running.
Cheers and have a good day!
--
You are receiving this mail because:
You are watching all bug changes.
