Created attachment 155258 [details] thumb cache cleaning since I find some discrepancies with thumbnail generation ( https://bugs.kde.org/show_bug.cgi?id=464046 ) I started to look closer the thumbnail cache in ~/cache/thumbnails/ seems never being maintained or cleaned what leads to the problem that thousands of thumbs might get stored (attachment) thumb generation always was kind of slow, one of the reasons likely is the number of thumbs already in cache specially slow it was and now it still is worse with camera raw images times ago, because of this slowdown, I limited my camera files count to 200/directory, it is quite normal for a photographer having an average of 300+ files per day thumbs are stored as PNGs, I believe that storing as JPGs would be really faster, I tried it with a third party thumb generator and 128px wide thumbs, in a directory with 200 camera JPGs, using the JPG format for thumbs finished in half of the time needed for PNGs may be you consider it and check if you can change to jpg thumbs in any case I would like to have a configurable option how many days I want to hold my thumbs, being deleted after automatically then I think that the thumbnail cache would be better placed in the image directory as .thumbs or something, I access the same places from different machines, this would eliminate a lot of local home/.cache storage space and much faster processing in the end
The XDG thumbnail specification specifies the format to be PNG (https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#CREATION), so this isn't going to change
(In reply to Nicolas Fella from comment #1) > The XDG thumbnail specification specifies the format to be PNG > (https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest. > html#CREATION), so this isn't going to change I see, don't know the reason but maybe not so important right now the removing thumbs part of the doc is very thin and probably not implemented anywhere, some other parts could also need some reading and modification meanwhile, I moved and merged all my thumb caches to the image work dir on the server and symlinked it for now on all machines, and that gave a real better performance in comparison to how it was, the thumbs are also compatible between the different OSs, even FreeBSD, so far that is for me, but hard to suggest it as solution to average users certainly, the doc and its contributors never previewed that people might have a very large number of image files, means that the actual thumb generation process is too slow for handling it I hope that the "cleaning after N days" isn't so difficult to add and that it is there some day thanks for the link
does this help? this days was there an update and kio was part, upgrade to Package: kio Version: 5.102.0-0xneon+22.04+jammy+release+build22 since then dolphin did not display anymore the raw files after removing kio no image thumb/preview was displayed anymore while gwenview kept working normally shows dolphin depends on kio and gwenview not so why is that and why dolphin can not treat thumbs like gwenview does?
but then I wonder why Arch keeps working fine local/dolphin 22.12.1-1 (kde-applications kde-system) local/dolphin-plugins 22.12.1-1 (kde-applications kdesdk) local/gwenview 22.12.1-1 (kde-applications kde-graphics) local/kio 5.101.0-2 (kf5) local/kio-extras 22.12.1-1 (kde-applications kde-network)