Bug 447137 - Feature request: update metadata from picture file if associated sidecar is deleted
Summary: Feature request: update metadata from picture file if associated sidecar is d...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Sidecar (other bugs)
Version First Reported In: 7.5.0
Platform: Flatpak All
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-17 16:22 UTC by MarcP
Modified: 2023-10-29 18:05 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MarcP 2021-12-17 16:22:43 UTC
SUMMARY
This is not a serious issue, but it would be cool if it could be implemented. I have my database set to read sidecars from files as default (and only write if the files are read-only). This is useful for video files in which XMP metadata cannot be written. Sometimes, you want to stop using a sidecar associated to a file and save the data directly into the file. However, if you delete the sidecar file, since the photo file has not changed, the information from the picture file is not read and digikam does not update the database.

It would be interesting if digikam could update the metadata from the associated file once a sidecar has been deleted. Right now, the only way is manually selecting these files and "re-read information from files". We should also take into account that sidecar can have two formats, one with the file extension and another without (e.g. IMG_4985.JPG.xmp and IMG_4985.xmp)

STEPS TO REPRODUCE
1. Have a picture, and save some information to a sidecar (e.g. some keywords)
2. Close digikam
3. Delete the sidecar file
4. Open digikam and let it scan for changes

OBSERVED RESULT
Digikam does not find any changes.

EXPECTED RESULT
Digikam realizes sidecar is missing, and re-read the metadata from the associated picture file.
Comment 1 Maik Qualmann 2021-12-17 18:05:28 UTC
In principle, this is already possible now, you just must not have set the modification date to always be set to the previous one. If the sidecar is no longer there, digiKam would find a different modification date and scan the file again. There is no indication in the database as to whether a sidecar exists. There is no other way to detect this in the start scan. Otherwise we would have to create a sidecar deletion option directly in digiKam.

Maik
Comment 2 MarcP 2021-12-17 18:12:41 UTC
But if the sidecar is deleted, but the original picture file is left untouched, its modification date won't change and digikam won't re-scan it, right?
Comment 3 Maik Qualmann 2021-12-17 19:11:03 UTC
No, some time ago we added the detection of whether the sidecar was changed externally. We save the most recent modification date in the database, either from the sidecar or from the file. This allows us to recognize changes to both the file or the sidecar. So if the modification date is always reset to the previous one by digiKam or externally when there is a change and even the file and sidecar have the same date, we cannot detect any change during the scan.
You only need to switch off the reading of sidecars and watch the terminal when it starts (debug variable enabled), digiKam will scan files that had a sidecar again. The same thing if you reactivate sidecar reading.

Maik
Comment 4 Maik Qualmann 2023-10-29 18:05:16 UTC
Git commit 4cfbcbdc0c87bd958f4fa3d2715cefd88932c02b by Maik Qualmann.
Committed on 29/10/2023 at 19:04.
Pushed by mqualmann into branch 'master'.

fix sidecar check as depend on the update timestamp option
FIXED-IN: 8.2.0

M  +1    -1    NEWS
M  +0    -1    core/libs/database/collection/collectionscanner_scan.cpp

https://invent.kde.org/graphics/digikam/-/commit/4cfbcbdc0c87bd958f4fa3d2715cefd88932c02b