SUMMARY Setting multiple tags on all images in an album does not work. Some images get set correctly, others do not get set. Worse is that tags already set in those images where the tags do not get set get unset, thus destroying hours of work. If I go through the images one at a time, it works. But this is a bit of a pain. this looks very much like bug 339227 which is resolved as fixed, but that was resolved as fixed in 2014, so this may be a reintroduction of that bug. STEPS TO REPRODUCE 1. Select all the photos in an album 2. Set several tags 3. Hit apply OBSERVED RESULT The tags do not get set on all images. They get set on SOME images. It also takes about 15 minutes for 36 files. I'm wondering if the two go hand in hand. EXPECTED RESULT All selected tags should be set on all selected images. SOFTWARE/OS VERSIONS Windows: 11 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Build date: 6/17/2023 7:39 AM (target: RelWithDebInfo) Revision: e61508aa9af17ca1094fdedd9c755aaf93076801 Branch: master
After reviewing the bug symptoms more, this needs to be marked as MAJOR as there is data loss.
No reproducible at all here under Linux, operation is very fast. I use sqlite database. It sound like a look of the database in background. Which kind of datatabase did you use ? where do you store database files ? Also we needs a debug trace from Microsoft debugview program. Look the instructions from the contribute page: https://www.digikam.org/contribute/ Best Gilles Caulier
Maik, Under Windows cross compiled with MXE, at the opposite with macOS and Linux bundles, we are back to Exiv2 0.27-maintenance branch, due to the lack of unicode support of paths under Windows with Exiv2 0.28. Gilles
Git commit 626e53b2f9491c99263feccb29c3dfe4175be99b by Maik Qualmann. Committed on 19/06/2023 at 19:59. Pushed by mqualmann into branch 'master'. resolve the image history when deleting and restoring images already This means that the database is not locked later (transaction locking) if the image history is resolved later by just setting the "needTaggingHistoryGraph" flag. M +3 -3 core/libs/album/treeview/albumselectiontreeview.cpp M +40 -29 core/libs/database/utils/ifaces/dio.cpp https://invent.kde.org/graphics/digikam/-/commit/626e53b2f9491c99263feccb29c3dfe4175be99b
I've noticed a bit of new information. Apparently, it works until the Geo Tag is done for a set of images. This has started happening in the last few beta releases. I've tried with the image database with the collection on a removable hard drive, and I've tried migrating the database to the internal disk with the images still on the removable hard disk. I can't move the images to the local hard drive since they take more space than the size of the internal drive. Ive set Write locations as tags and Write locations metadata. I am wondering if this is the root cause of the problem since it appears that it works until I go through the process of Reverse Geocoding.
Reverse geocoding could actually be the cause. If the database tags are not in sync with the metadata tags, it can actually result in tag loss. In addition, tags are only created in the digiKam TagsList and dc.subject. This part is quite old and the geolocation editor is shared with showFoto which doesn't support database. I will fix it. Maik
Git commit 5ec4f32e459cb1f5ffef88bce95b9965af536d28 by Maik Qualmann. Committed on 20/06/2023 at 20:04. Pushed by mqualmann into branch 'master'. sync database tags to the geolocation editor FIXED-IN: 8.1.0 M +2 -1 NEWS M +11 -2 core/libs/database/item/containers/itemgps.cpp M +59 -45 core/utilities/geolocation/geoiface/items/gpsitemcontainer.cpp M +1 -0 core/utilities/geolocation/geoiface/items/gpsitemcontainer.h https://invent.kde.org/graphics/digikam/-/commit/5ec4f32e459cb1f5ffef88bce95b9965af536d28