| Summary: | Toggling "use file metadata" for input will make Digikam forget all imported photos | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jens <jens-bugs.kde.org> |
| Component: | Import-Settings | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 6.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/digikam/d9d38c8df177760186d4ba19cec2618f65d561cd | Version Fixed/Implemented In: | 6.0.0 |
| Sentry Crash Report: | |||
| Attachments: | FileDateForHistory.patch | ||
|
Description
Jens
2018-05-31 20:41:56 UTC
I do not see a practical solution here. The date is an important part to recognize an already imported image. We already accept +/- 1 hour to accept the daylight-saving time. But if the date of the file is so different to the EXIF date, I have no idea. Saving both dates would require a change to the database. I tend to WONTFIX and either use metadata or not to import images. Generally using metadata here is also not a good solution, since the speed advantage when no metadata is used is significant. I do not use metadata and rename the images after imported into digiKam. Maik What data other than the date is used to decide on "already imported"? I don't think the date is the problem here, because this also happens when the EXIF and filesystem date stamp are identical. 1. An MD5 hex string created by:
UMS driver: volume UUID
gPhoto driver: camera model + file path
2. Filename
3. File size
4. Creation date of the image (from EXIF or file)
Maik
I looked at the problem more deeply. When we use metadata we also read the fractional second (sub-second) from the EXIF and use it. But even if we round off or ignore the fractional second, there may be a difference between EXIF date and file date of 1 second for some images here from a Nikon. The only solution I see is that we always use the file date for the download history. However, this is not evaluated if metadata is used at the moment. Maik Maik, take a care. Always read metadata while downloading will increase certainly the time to be connected and to populate Import icon view. Gilles Created attachment 113101 [details]
FileDateForHistory.patch
This patch would fix the problem for new downloads. However, users who previously used metadata would experience errors in the old history. Depending on how long you keep downloaded images on the memory card.
Maik
Git commit d9d38c8df177760186d4ba19cec2618f65d561cd by Maik Qualmann. Committed on 04/07/2018 at 10:33. Pushed by mqualmann into branch 'master'. accept a time difference of +/- 1 second for the date of the download history FIXED-IN: 6.0.0 M +2 -1 NEWS M +5 -2 core/libs/database/coredb/coredb.cpp https://commits.kde.org/digikam/d9d38c8df177760186d4ba19cec2618f65d561cd |