SUMMARY inconsistency between metadata displayed and metadata taken in account to rename STEPS TO REPRODUCE 1. modify DateTimeoriginal of a photo of a Digikam album with an external tool 2. scan for new items 3. to display DateTimeoriginal of the photo into metadata panel/exif 4. to rename the photo (F2) with [date:yyyy-MM-dd_hh'h'mm-ss] option OBSERVED RESULT DateTimeOriginal displayed into the metadata panel/exif is the new date the new name of the photo is unchanged (it is based on the old date) EXPECTED RESULT consistency between metadata displayed and metadata taken in account to rename SOFTWARE/OS VERSIONS: Linux/KDE Plasma: Manjaro/KDE KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION re-read metadata from file solves the problem
There are many dates in photos. The question is which one did you change with the external program? Has the date under the thumbnail been updated to the new one? They may need to reread the metadata from the image. You should use digiKam's TimeAdjust Tool. Maik
In order to be able to narrow down the problem further, we need 2 images, namely before and after processing in the external tool. Maik
(In reply to Maik Qualmann from comment #1) > There are many dates in photos. The question is which one did you change > with the external program ? I provided this information : Image Information/DateTimeoriginal (the one displayed which this name in the Digiakm Metadada Exif panel > Has the date under the thumbnail been updated to the new one ? I don't know since only seconds part changed in my try. But I think it is irrelevant : I change Image Information/DateTimeoriginal with an external tool and this change appears in the Image Information/DateTimeoriginal into the Digiakm Metadada Exif panel after to scan for new items. > They may need to reread the metadata from the image. I said that in the ADDITIONAL INFORMATION part. I know the solution to solve the inconsistency but it would be better if there was not inconsistency at all : at the same time, Digikam provide a DateTimeoriginal A into the Metadata Panel and a DateTimeoriginal B into the renaming panel (F2). It would be fine either A or B, but for both panels. > You should use digiKam's TimeAdjust Tool. Of course but in this case I had a good reason to do it outside Digikam.
If the date is displayed in the metadata panel, it does not mean that it has also been changed in the digiKam database. The metadata panel shows the "live" status of the metadata of the image. You may also have to activate the digiKam metadata settings to re-read the metadata after changes. Maik
Created attachment 135764 [details] before
Created attachment 135765 [details] after
(In reply to Maik Qualmann from comment #4) > If the date is displayed in the metadata panel, it does not mean that it has > also been changed in the digiKam database. The metadata panel shows the > "live" status of the metadata of the image. > > Maik You have the right to think that is not a bad thing to display different values for a field of the selected image depending of the panel displayed. IMHO it is bad but of course I am not the one who decide.
When I compare the two text files, I see that the file modification date has not changed. Since the file size has probably not changed either, digiKam cannot detect any changes even with a new item scan. With such a change you have to manually read the metadata again from the externally changed images so that the database is up to date again. There is no other way to do this. Because the date function in the renaming uses the database as a source. Alternatively, there are also date functions of metadata for renaming. Maik
(In reply to Maik Qualmann from comment #8) > When I compare the two text files, I see that the file modification date has > not changed. What you see are exif fields inside the file, not the file properties. I suppose that 'scan for new items' detects file changes checking the file properties (provided py the file system), not looking inside exif metadata of each file. As you can see with the two new attached files, the file properties changed after the date modification with the external tool (anyway, it changed also within the exif data, see FileInodeChangeDate field).
Created attachment 135826 [details] file properties before
Created attachment 135827 [details] files properties after
No, the first lines with File* that Exiftool outputs do not come from the metadata, this is real file system information. Information on FileModifyDate, FileAccessDate and FileInodeChangeDate does not exist in the Exif metadata. Maik
(In reply to Maik Qualmann from comment #12) > No, the first lines with File* that Exiftool outputs do not come from the > metadata, this is real file system information. You are right. When I submitted initially the report, the setting of the external tool I used to change DateTimeoriginal was "don't change file date" so your answer at 20:35:44 UTC was a good explanation. But I retry with a new setting "change file date" and I attached the screen copies of the file properties windows (such as displayed by Dolphin) before and after the modification into the external tool. As you can see, the date of the file has changed. But even with a new date file, 'scan for new item' don't upadate Digikam database, at least for DateTimeoriginal since the rename function 'F2' don't "see" the new value (it see it only re-reading the metadata from file). So my question : is 'scan for new items' limited to NEW files or is it supposed to be able to detect changes in modified files (when file system date attribute has changed, of course) ? (Sorry for my previous bad/incomplete explanation, I missed to explain that I was talking about a new try taking in account your comment.)
Did you activate this option in the metadata settings? [x] Rescan file when files are modified Maik
Yes, it is activated.