Caching Thumbnales for remote folders

I’m under the impression that this was working in the passed but I noticed that thumbnails for files on remote filesystems are not cached. Also generating them is slow. When I enter a folder like smb://server/videos/dir it takes some time, maybe 60 sec for each file, but in the end I see thumbnails for all video files. But when I leave the folder and enter it immediately again all thumbnails are gone and will be recreate. I noticed that no files are written to ./.cache/thumbnails when thumbnails are create for files in those folders. Is this a bug? in the passed I used autofs to mount samba shares , that is why I’m not sure if this was working in the passed.

I’m using:
ffmpegthumbs 24.02.2-1
KDE Plasma 6.0.3
KDE Framework 6.0.0
QT-Version 6.7.0

1 Like

This is the difference, we cache data for mounted fs, not for remote protocol (here smb://). This has always been the case.
Caching thumbnails in those circumstances should be possible.
You can report a feature request for this.

1 Like

Thanks for the replay. I will make a future request.
I switched back to mounting the samba shares, this time witch systemd automount. But I quickly noticed why I preferred using the remote protocol. Because the system dose not like it when a samba share is mounted and the network connection gets lost unexpected. Yes you can circumvent the issue with some hooks in Network Manager, but its not grate.

Sorry about that, not hanging when network becomes unresponsive has been a challenge and is a an important bug. We don’t even have a proper way of detecting the situation when we have a mounted file system that can’t respond anymore.

Kind of related is the missing API to get file notifications for network filesystem Change notifications for network filesystems []

I had a thought about that the other day.

What if KDE had guidelines that a network systemd.mount should be made by the user (--user). That way unmounting and mounting could be done at user level.
This would also mean KDE can look for systemd user mount units, and if they are unresponsive, have the credentials to be able to stop them.

Would that help with the situation?

It would partially at least. Using systemd-unit you could mount lazily and unmount automatically your filesystem when you turn off networking, but it would fail at detecting connectivity loss while still on the network, like the remote server shutting down, network-access disturbed, etc…

That’s a distro specific thing still, since Plasma works on non-systemd systems.
We could provide integration with it, but someone would have to do it…

I do not see that a reliable way of dealing with mounts in a case of a connection issue can be found. And I do not believe that this belongs in the scope of a desktop environment. In the end those mounts are handled by the kernel. Maybe the user tool doing the mounting (systemd / autofs etc) can implement something. The advantage with using the remote protocol to me is this runs in user space therefore it dose fail much nicer. In my case running a hook before the network is going down takes more then 10 seconds. Running it after the notwork has gone done it takes more then a minute, in which the hole system is lagy. So I have to weigh how likely is a unplanned connection issue and how imported are the thumbnails to me.

Mounting it as a user is no problem with systemd, just put it in ~/.config/systemd/user/ and interact with systemctl --user.

And you can make a systemd.timer in the same directory performing a ping every 10 seconds or so, and if no response, stop the mount.
It is “power user” level of config, just throwing it out there in case you wanted a solution for now.