Situation for 1 possible 2 problems: 1) Two separate computers with digikam installed each with their own local database "/user/someuser/digikam" "Mint Debian systems, identical versions". 2) Both systems share a common usb drive loaded with camera raw and jpg images "~25,000 images at ~340 gig " 3) usb drive is mount to both machines at /pvl/someyear so it looks the same to both digikam installs and more importantly to me. Problem: 1) Changes made on one computer to image tags updated to the usb drive are not found by digikams initial start up on the second machine. 2) Deleted tags are not updated except through maintenance and are also not updated on the second machines initial start up. 3) Changing one tag for one image out of 25,000 requires me to run maintenance on all 25,000 images taking hours. This i see as a problem. Reproducible: Always Steps to Reproduce: 1.Take one image assign it any tag update to sidecar only on first machine "usb drive". 2.take usb to 2nd machine and add to collection, then modify image add a second tag and update 3.return to first machine let it scan for new items check if tag modification shows on first machine Actual Results: Returning to the first machine will see no change in tags modified in the second machine Expected Results: I would expect that there is a time stamp for tags and sidecars "also absolute and relative file location" that will allow the "start up scan" to catch modified sidecars along with newly entered images. This would also change the maintenance cycle time dramatically. There is no Severity option I could find. This is a great program that is almost unusable because of how tags are maintained. Even if I used only one computer and one data base moving a small number of files in a large collection with multiple folders is problematic.
You must use "Maintenance/Sync Metadata and Database" tool with the right direction. This take a while. This is why these operations are not present in scan for new items process. Gilles Caulier
I understand that "On 24/09/14 03:09 AM, Gilles Caulier wrote:". I know it is not in the "new items", for one reason to much time. I have surmised that the "Maintenance/Sync Metadata and Database" options of either updating sidecars or updating the database does so without checking for anything other than the existence of a sidecar or an entry in the database. That is the database writes every entry out to a sidecar or every sidecar is read and entered into the database "one way only". I have not noted in this process any means of checking between database and sidecars for modified/changes to tags. Unless I have missed something this lack of checking is why the process takes so long. It is that length of time as an outcome of the current process that I see as a problem. One possible way to speed that up would be to time stamp, sidecars and tag entries. I mention only tags for this is of critical interest to me. On 24/09/14 03:09 AM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=339342 > > Gilles Caulier <caulier.gilles@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |caulier.gilles@gmail.com > > --- Comment #1 from Gilles Caulier <caulier.gilles@gmail.com> --- > You must use "Maintenance/Sync Metadata and Database" tool with the right > direction. > > This take a while. This is why these operations are not present in scan for new > items process. > > Gilles Caulier > (In reply to Gilles Caulier from comment #1) > You must use "Maintenance/Sync Metadata and Database" tool with the right > direction. > > This take a while. This is why these operations are not present in scan for > new items process. > > Gilles Caulier
Can you reproduce the problem using digiKam Linux AppImage bundle ? The last bundle is available at this url: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier
What's about this file using 5.8.0 pre-release buncle : https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
Git commit 9c77203fdc10cd59aa0ba645ab3fde7f774dbaf2 by Maik Qualmann. Committed on 13/09/2018 at 19:47. Pushed by mqualmann into branch 'master'. store as modification date always the most recent from the image or the sidecar Related: bug 397340, bug 398331, bug 380341 FIXED-IN: 6.0.0 M +5 -2 NEWS M +14 -1 core/libs/database/collection/collectionscanner.cpp M +14 -1 core/libs/database/item/imagescanner.cpp https://commits.kde.org/digikam/9c77203fdc10cd59aa0ba645ab3fde7f774dbaf2