Bug 451723

Summary: Reread metadata from image stalls when started from Tag Manager
Product: [Applications] digikam Reporter: Steve Franks <stevef48>
Component: Tags-ManagerAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, metzpinguin
Priority: NOR    
Version First Reported In: 7.7.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In: 7.7.0
Sentry Crash Report:
Attachments: Debugview Log

Description Steve Franks 2022-03-20 11:22:01 UTC 
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
Comment 1 Maik Qualmann 2022-03-20 11:57:37 UTC 
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
Comment 2 Maik Qualmann 2022-03-20 12:12:04 UTC 
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
Comment 3 Maik Qualmann 2022-03-20 13:57:11 UTC 
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
Comment 4 Steve Franks 2022-03-20 15:07:12 UTC 
(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.
Comment 5 Maik Qualmann 2022-03-20 15:12:49 UTC 
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
Comment 6 Maik Qualmann 2022-03-20 15:17:27 UTC 
Another note, with the maintenance tool you can select individual albums to re-read the image metadata from them.

Maik
Comment 7 Steve Franks 2022-03-20 16:23:33 UTC 
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
Comment 8 Maik Qualmann 2022-03-20 16:42:42 UTC 
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
Comment 9 Steve Franks 2022-03-21 10:31:28 UTC 
(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?