Bug 425369 - Imported photo in album other than date taken
Summary: Imported photo in album other than date taken
Status: RESOLVED DUPLICATE of bug 331167
Alias: None
Product: digikam
Classification: Unclassified
Component: Import-Gphoto2 (show other bugs)
Version: 7.0.0
Platform: macOS (DMG) macOS
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-15 04:09 UTC by imksn
Modified: 2021-08-13 06:40 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description imksn 2020-08-15 04:09:29 UTC
SUMMARY
iPhone 6s Plus imported photo can end up in an album other than date created

STEPS TO REPRODUCE
1. Import setting for photo is set to "Auto-creation of Albums using date-based sub-albums"
2. Click dropdown arrow right of "Download" label
3. Click "Download Selected"

OBSERVED RESULT
Sometimes photo from a certain date can be put in an album other than the created date of the photo.

EXPECTED RESULT
Photos from a specific created date should be in an sub-album titled the same as the creation date.

SOFTWARE/OS VERSIONS
macOS: 10.13.6 (High Sierra)
Apple iOS: 13.4.1

ADDITIONAL INFORMATION
Device from which photo transferred: iPhone 6s Plus
Device to which photo transferred: MacBook Pro (Retina, 13-inch, Late 2013); Processor 2.4 GHz Intel Core i5; Memory 8 GB 1600 MHz DDR3
Comment 1 Maik Qualmann 2020-08-15 04:49:08 UTC

*** This bug has been marked as a duplicate of bug 331167 ***
Comment 2 imksn 2020-08-15 06:59:18 UTC
(In reply to Maik Qualmann from comment #1)
> 
> *** This bug has been marked as a duplicate of bug 331167 ***

Ah, not quite. The bug I report is that that digikam generates an album with the title different from the created date, NOT the imported date like bug 331167.

For example, I had several photos with creation date of 07/20/2020. All but one was downloaded to album 2020-07-20 except one which was put in an album 2020-07-21. Then there was photos from creation date of 07/22/2020 that were put in an album titled 2020-07-23. Today’s date is 08/14/2020, so the auto-created albums had nothing to do with date of import as in bug 331167.
Comment 3 Maik Qualmann 2020-08-15 07:31:14 UTC
We know the cause. The correct EXIF date is not available to us when importing, as the file date is usually used when using the GPhotos driver. You can try to activate the loading of the metadata in the camera settings (this makes the connection slower). To fix this and other bugs related to metadata, a major change to the import tool is required. We have to download the temporary file first so that all metadata is available locally.

Maik
Comment 4 Maik Qualmann 2020-08-15 07:35:54 UTC
And yes, bug 331167 is the same problem and cause.

Maik
Comment 5 imksn 2020-08-15 19:13:09 UTC
(In reply to Maik Qualmann from comment #3)
> We know the cause. The correct EXIF date is not available to us when
> importing, as the file date is usually used when using the GPhotos driver.
> You can try to activate the loading of the metadata in the camera settings
> (this makes the connection slower). To fix this and other bugs related to
> metadata, a major change to the import tool is required. We have to download
> the temporary file first so that all metadata is available locally.
> 
> Maik

Well, it’s a slow connection vs spending personal time moving images to appropriate albums and renaming albums to appropriate names/dates.

Can you suggest somewhere to read about how to activate loading of metadata in the camera settings?
Comment 6 caulier.gilles 2020-12-18 12:07:11 UTC
https://bugs.kde.org/show_bug.cgi?id=426938

--- Comment #4 from caulier.gilles@gmail.com ---
Hi,

digiKam 7.2.0-beta2 pre-release PKG installer now support BigSur and is
compiled with last stable Qt 5.15.2.

https://files.kde.org/digikam/

Problem still reproducible with this version.

Thanks and happy Christmas in advance

Best Regards

Gilles Caulier
Comment 7 Maik Qualmann 2021-08-13 06:40:53 UTC

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