Created attachment 147615 [details] Debugview Log SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** I am recreating digikam MySQL Internal database. 2083 images are in the No Tags collection, but all images had tags before MariaDB crashed. In the past I have selected all of these images then clicked 'Item', 'Reread Metadata from Selected Files'. This usually runs for a few minutes and clears some of the files. I recently discovered that Tags Manager has an option Read Tags under Sync Export. When I try it, the progress bar shows that something is going on, but after many minutes the progress indicator does not go to 0%. STEPS TO REPRODUCE 1. Select images 2. In Tags View, select Tags Manager, Sync Export, Read Tags from image. 3. OBSERVED RESULT Digikam is busy; Move/Merge Tags is disabled. Shading moves on the progress indicator, but progress perecentage does not change. This continues for >15 minutes. EXPECTED RESULT Same as when Item | Reread Metadata from Selected Files. i.e. The progress indicator shows increasing values until the process ends after a few minutes. SOFTWARE/OS VERSIONS Windows: 11 Hme macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
When you sync in Tags Manager, ALL your images will be reread, not just the ones you selected. With a correspondingly large collection, this can take some time until the percentage display moves. I can't find any error here. Your log also shows that digiKam is reading metadata. Maik
The only problem in the log is Flash metadata that is returned as a string and is discarded when written to the database because integer is expected. Please create a log again with deactivated JPG logging. QT_LOGGING_RULES="digikam.*=true;digikam.dimg.jpeg=false" Maik
Git commit 57ef36a123e18056f820664d1638b758a29fa6f8 by Maik Qualmann. Committed on 20/03/2022 at 13:55. Pushed by mqualmann into branch 'qt5-maintenance'. Xmp.exif.Flash has a struct type, get the mode number M +1 -1 core/libs/metadataengine/dmetadata/dmetadata_generic.cpp M +1 -1 core/libs/metadataengine/dmetadata/dmetadata_photo.cpp https://invent.kde.org/graphics/digikam/commit/57ef36a123e18056f820664d1638b758a29fa6f8
(In reply to Maik Qualmann from comment #1) > When you sync in Tags Manager, ALL your images will be reread, not just the > ones you selected. With a correspondingly large collection, this can take > some time until the percentage display moves. I can't find any error here. > Your log also shows that digiKam is reading metadata. > > Maik That explains it, thanks. It's odd that rereading metadata finds tags in files, that were there all the time, but not read when the images were first found by digikam.
We already have a bug report on this problem on Windows. But we don't have an explanation yet. We suspect that the image files were locked by other programs, Explorer, AntiVirus... I'm closing here... Maik
Another note, with the maintenance tool you can select individual albums to re-read the image metadata from them. Maik
I set the QT_LOGGING_RULES as you suggested, it made a huge difference to the speed. It seems that everything in digikam ran faster. The latest log is here https://www.dropbox.com/s/z741xlqb0s0s7il/DELL-G3_220320_1615.zip?dl=0
Yes, logging makes digiKam slow on Windows. If you no longer need it, you should disable it. The log shows no particular problem, looks good. Maik
(In reply to Maik Qualmann from comment #8) > Yes, logging makes digiKam slow on Windows. If you no longer need it, you > should disable it. The log shows no particular problem, looks good. > > Maik Is that done by deleting the QT_LOGGING_RULES variable, or should I change it to digikam=false?