Bug 389814 - Date-based Sub-albums uses modification date instead of metadata date
Summary: Date-based Sub-albums uses modification date instead of metadata date
Status: RESOLVED DUPLICATE of bug 331167
Alias: None
Product: digikam
Classification: Unclassified
Component: Import-Albums (show other bugs)
Version: 5.8.0
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2018-02-03 04:14 UTC by tuxflo
Modified: 2018-02-03 21:21 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description tuxflo 2018-02-03 04:14:44 UTC
I facing a similar problem as https://bugs.kde.org/show_bug.cgi?id=301936 but instead of rename, I'm having problems with the "Date-based Sub-album" import.

Steps to reproduce:
1. Change the modification date of some images  to a different date as the "Creation date" stored in the metadata.

2. Open the Import dialog (Crtl+Alt+I), select the images and enter "yyyy/yyyy-MM/yyyy-MM-dd" as custom date in the "Auto-creation of Albums" settings.

3. Import the images.

Current result: Sub albums are created by the modification date entered in step 1.

Expected result: Sub albums are created by the creation date of the images (anything else doesn't make sense).

If possible let the user choose which date should be used as described in the linked bug ("Use file metadata (makes connection slower).")
Comment 1 Maik Qualmann 2018-02-03 21:19:19 UTC
If you use the option "Use file metadata (makes connection slower)" the creation date from the EXIF metadata is used. And the result is what you want. If this option is disabled, the file date will be used, that's all. This option exists to speed up the connection to card readers or GPhoto2 devices. If you always want the EXIF date, activate the option. There is an exception for RAW files and GPhoto2 devices. We can only solve this problem in the future by first temporarily downloading all the images and then applying any date or time modifications.

Comment 2 Maik Qualmann 2018-02-03 21:21:49 UTC

*** This bug has been marked as a duplicate of bug 331167 ***