Bug 433060 - inconsistency between metadata displayed and metadata taken in account to rename
Summary: inconsistency between metadata displayed and metadata taken in account to rename
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: AdvancedRename-metadata (show other bugs)
Version: 7.2.0
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-17 09:31 UTC by mahikeulbody
Modified: 2022-01-31 21:41 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.2.0
Sentry Crash Report:


Attachments
before (3.72 KB, text/plain)
2021-02-17 13:11 UTC, mahikeulbody
Details
after (3.72 KB, text/plain)
2021-02-17 13:11 UTC, mahikeulbody
Details
file properties before (37.19 KB, image/png)
2021-02-18 09:53 UTC, mahikeulbody
Details
files properties after (37.16 KB, image/png)
2021-02-18 09:54 UTC, mahikeulbody
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mahikeulbody 2021-02-17 09:31:25 UTC
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
Comment 1 Maik Qualmann 2021-02-17 11:38:07 UTC
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
Comment 2 Maik Qualmann 2021-02-17 11:40:22 UTC
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
Comment 3 mahikeulbody 2021-02-17 12:55:56 UTC
(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.
Comment 4 Maik Qualmann 2021-02-17 13:03:09 UTC
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
Comment 5 mahikeulbody 2021-02-17 13:11:18 UTC
Created attachment 135764 [details]
before
Comment 6 mahikeulbody 2021-02-17 13:11:37 UTC
Created attachment 135765 [details]
after
Comment 7 mahikeulbody 2021-02-17 13:21:16 UTC
(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.
Comment 8 Maik Qualmann 2021-02-17 20:35:44 UTC
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
Comment 9 mahikeulbody 2021-02-18 09:53:19 UTC
(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).
Comment 10 mahikeulbody 2021-02-18 09:53:47 UTC
Created attachment 135826 [details]
file properties before
Comment 11 mahikeulbody 2021-02-18 09:54:05 UTC
Created attachment 135827 [details]
files properties after
Comment 12 Maik Qualmann 2021-02-18 11:36:51 UTC
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
Comment 13 mahikeulbody 2021-02-18 12:16:10 UTC
(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.)
Comment 14 Maik Qualmann 2021-02-18 22:08:19 UTC
Did you activate this option in the metadata settings?

[x] Rescan file when files are modified

Maik
Comment 15 mahikeulbody 2021-02-19 08:36:18 UTC
Yes, it is activated.