Created attachment 189325 [details] DateTime1 Hi! Something's wrong. I've seen this problem several times before. After scanning the slides, I add the capture date using "Set date and time." However, after the scan, some photos don't have an updated date. In my example, the time should be 14:00:10, incrementing by 10 seconds each time. But it's still showing the old 18:xx:xx. Interestingly, the next photos, also showing 14:xx:xx PM, have the correct 10-second increments. In the edit window, the metadata seems to be written in a jumbled way during the scan. Sometimes it's at the top, sometimes at the bottom, and then randomly in between. Batch processing does this too. But it works. It just seemed like the edit window for date and time closed before all the changes were written. Andy
PS: The subsequent run with the same data worked successfully.
So you have used the import tool to tune the time stamp. Right ?
No. From the toolbar at the top, select "Set date and time" (Ctrl+Shift+D).
Ok, it's the time adjust plugin. Can you take a screenshot of the plugin dialog to show all settings used? Gilles Caulier
Created attachment 189341 [details] DateTime2 Here's the screenshot. Unfortunately, I can't yet say what the cause is. Only that it happens sometimes. Perhaps it's related to the order of the photos? I've moved them around a lot and renamed the files several times. The third column, "Used Timestamp," is confusing me. Shouldn't it show an existing timestamp from the file?
Git commit 7db6850c6ccc2125a6b46a2ea306c68c7fb29607 by Maik Qualmann. Committed on 08/02/2026 at 07:18. Pushed by mqualmann into branch 'master'. fix early finish when using "ok" in the Time Adjust Tool FIXED-IN: 9.0.0 M +1 -1 NEWS M +6 -6 core/dplugins/generic/metadata/timeadjust/timeadjustdialog.cpp https://invent.kde.org/graphics/digikam/-/commit/7db6850c6ccc2125a6b46a2ea306c68c7fb29607
Created attachment 189619 [details] DateTime3 Hi Maik, The problem is still present in the latest version. See the screenshot. Andy
Since I can no longer reproduce it, we need a DebugView log of the Time Adjust Tool process. https://www.digikam.org/contribute/#windows-host Maik
Created attachment 189621 [details] Ausgabe1 Hi Maik, here's the log. Andy
What is this? I've never seen messages like this in DebugView before. Lots of these messages from different DLL files. "digikam.exe" (Win32): "C:\Program Files\digiKam\KF6IconThemes.dll" geladen. Das Laden von Symbolen wurde durch die Einstellung zum Einschließen/Ausschließen deaktiviert. Maik
It seems you have enabled the monitoring of albums for external changes. I don't recommend this; it only causes problems under Windows. Please disable it, restart digiKam, and test again. Maik
Created attachment 189623 [details] Ausgabe2 Yes, that's right. The continuous monitoring has been active for a week. I'm currently sorting everything out. Some of the scanned slides are mixed up. I've been working with Digikam and Windows Explorer simultaneously. It worked surprisingly well. Here's the new log.
No error can be detected from the debug output; it appears that all files have been processed and the metadata written. Maik
Strange. There were 18 selected files, but only 16 were modified.
Maik, "digikam.exe" (Win32): "C:\Program Files\digiKam\KF6IconThemes.dll" ==> WIN32 ??? Sounds like a mix from a very old digiKam install and a recent one ? Gilles
That's possible. I've only ever installed updates. Aren't old components completely uninstalled during the installation process? It certainly looks that way. Andy
The file is dated 14.02.2026 19:23:04
Another thing you could try is using a local collection. It might be related to the NAS, file locking, or something similar. Maik
Hi! I've had that idea too. But I'd rather not switch back to local albums because there are also problems with Synology Drive. In certain cases, conflict duplicates are created. I can't figure out why it takes so long for the first changes to be written to the EXIF files. In the log, I can see that it can take up to 7 seconds per file on the first pass. Are areas for the EXIF data being created for the first time? Is each photo being read and rewritten? The photos are still between 15 and 35 MB in size. That will further delay the processing. If the new file isn't quite finished yet, so that the date and time can't be written, is that step skipped? Are the changes being made sequentially or simultaneously? In the window for the time entries, I always click OK instead of Apply first. Perhaps that's why the window closes before all the changes have been made? I can see a percentage indicator for the processing, which has not yet reached 100% when closing. Andy
Although I switched to SQLite and local albums, it just happened again that the window closed when I clicked OK, before the time was changed in all the files. Out of 20 photos, 3 weren't changed. I'll now try applying the changes only and then closing the window. Andy
I can imagine that this problem occurs if the preview calculation thread is still running and you then press OK. Maik
I can't really imagine that's the case. I always double-check the date before clicking OK. Because the month is written out in words there, and not everywhere else, I always double-check it. So it takes 2-3 seconds before I click OK. But I'll keep a close eye on that. Andy
Created attachment 190402 [details] 20260305 Hmm. Could it be related to the photo being edited again? Here's another image. On the right side, all the photos should start with the name 19821231_xxxxxxxx. But after the change, some still have 19821224. So, those photos were skipped when the metadata was changed. The change was initiated by clicking OK. I haven't had any problems with the "Apply" button so far. But unfortunately, I still haven't been able to discern any pattern. Andy
There's no difference between clicking OK and Apply. It seems to happen less often with just a few photos than with 20 or more. I don't know the sequence of events. Perhaps the changes to the database aren't fully written by the time the photos are edited. The database is SQLite and is located on an M.2 SSD. Andy
Git commit 98b9615c8f5fe037cf3aa439e5a337794023a9b3 by Maik Qualmann. Committed on 07/03/2026 at 07:28. Pushed by mqualmann into branch 'master'. fix preview job race condition in the Time Adjust Tool FIXED-IN: 9.1.0 M +8 -1 core/dplugins/generic/metadata/timeadjust/timeadjustdialog.cpp M +7 -7 core/libs/threads/actionthreadbase.cpp M +1 -1 core/libs/threads/actionthreadbase.h https://invent.kde.org/graphics/digikam/-/commit/98b9615c8f5fe037cf3aa439e5a337794023a9b3