Bug 394906 - Toggling "use file metadata" for input will make Digikam forget all imported photos
Summary: Toggling "use file metadata" for input will make Digikam forget all imported ...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Import-Settings (show other bugs)
Version: 6.0.0
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-31 20:41 UTC by Jens
Modified: 2018-07-04 10:35 UTC (History)
2 users (show)

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


Attachments
FileDateForHistory.patch (7.54 KB, patch)
2018-06-05 18:11 UTC, Maik Qualmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jens 2018-05-31 20:41:56 UTC
When importing photos and switching between the option to use file metadata (which is slower) for *some* imports, each time I change this setting, Digikam will forget which photos I have already imported.

This should not happen. Digikam should remember imported photos regardless of import settings.

Using the most current Digikam amd64 appimage as of today.
Comment 1 Maik Qualmann 2018-05-31 21:29:57 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
Comment 2 Jens 2018-06-01 21:08:38 UTC
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.
Comment 3 Maik Qualmann 2018-06-01 21:27:47 UTC
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
Comment 4 Maik Qualmann 2018-06-05 06:43:40 UTC
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
Comment 5 caulier.gilles 2018-06-05 08:45:16 UTC
Maik,

take a care. Always read metadata while downloading will increase certainly the time to be connected and to populate Import icon view.

Gilles
Comment 6 Maik Qualmann 2018-06-05 18:11:24 UTC
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
Comment 7 Maik Qualmann 2018-07-04 10:35:03 UTC
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