https://bugs.kde.org/show_bug.cgi?id=395241
--- Comment #29 from Michael Miller <michael_mil...@msn.com> --- (In reply to Michael Moore from comment #28) > > Can you provide the specs of your system? How fast is the CPU, what kind > > of storage (local SSD, network share, etc...), and probably most > > importantly, how much memory do you have? > > * 8 core AMD Ryzen 7 5700G, max speed 4.6 GHz > * 64GB RAM > * Photos are on a local NVME SSD (WD Blue SN580 2TB) > * MariaDB is on a different local NVME SSD, along with the rest of the > system install (Intel SSDPEKNW010T8) > > I am running Debian Trixie/Testing, and using the digiKam 8.5 AppImage. > > > The face thumbnail is generated from the original image when the face is > > detected in the scan. The thumbnail image is then saved to the thumbnail > > DB. We also have a thumbnail caching service in digikam that keeps a > > portion of the thumbnails in memory. > > I don't think I'm seeing this behavior. > > I made a screen recording to show it. You may have to watch in 4k to see all > the text clearly. > > https://www.youtube.com/watch?v=MwQCRO-9ujc > > In the video I have 4 terminals open: > > 1 with a MariaDB connection to the digikam_thumbs database. > 1 with iotop sorted by disk read activity, and one with iotop sorted by disk > write activity. > The last terminal has htop running to show RAM and CPU usage. > > I open digiKam. > It starts on the People tab, with my face selected. All thumbnails load > quickly > I wait until it says "No active process" again and then run "SELECT COUNT(*) > FROM Thumbnails" in the terminal. > We start with 500854 thumbnails > > I page down by clicking in the scroll bar, below the scroll handle. > Some thumbs load instantly, others take some seconds to load. > During this time you can see that perl is running exiftool quite a lot and > mariadb is doing quite a lot of writing. Both of these processes stop when > all thumbnails have been loaded. > > I repeat the page down process a few times. > > On the last page down I rapidly re-run the "SELECT COUNT(*)" query and we > see the number of thumbnails increasing. Once the thumbs are all loaded, the > count stabilizes at 501006. > > > Maybe I'm looking at the wrong things, but to me it looks like the > thumbnails are being generated when they are first viewed, not when the > faces were detected. Hi Michael, That's definitely interesting. The number of thumbnails shouldn't go up. Is this behavior repeatable? In other words, if you restart digikam will the number of thumbnails go back down to 500854, or will it start at 501006? I'm wondering if there might be an issue with the thumbnail cache. The face pipelines coming in 8.6.0 have been completely rewritten from scratch. I can tell you with certainty that in the 8.6.0 pipelines the thumbnail is written to the DB when it is first extracted from the original image during face detection. If you're willing to try very unstable code, grab the latest AppImage and let's see if we can reproduce the issue. If we can, then it has to be something in the thumbnail cache. You can find it here: https://files.kde.org/digikam/ ** BACK UP ALL YOUR DATABASES BEFORE USING THE 8.6.0 NIGHTLY BUILD ** Also, I see from the video (thank you!) that you have "Remove obsolete core database objects" selected. While this shouldn't affect the thumbnail DB, it might be good to turn it off for testing. Finally, I think you are delegating all metadata functions to exiftool, correct? Can you please turn this off, too. Exiftool can really slow things down. Cheers, Mike -- You are receiving this mail because: You are watching all bug changes.
