[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[Maik Qualmann]

https://bugs.kde.org/show_bug.cgi?id=384603

Maik Qualmann  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Version Fixed In||6.0.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #15 from Maik Qualmann  ---
This issue is now be resolved. When digiKam tried to save a date with UTC
extension into a MySQL database, it failed and the record was discarded. I
close the bug now.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[Simon]

https://bugs.kde.org/show_bug.cgi?id=384603

Simon  changed:

   What|Removed |Added

 CC||freisi...@gmail.com

--- Comment #14 from Simon  ---
Thanks for the thorough investigation. In my opinion not re-reading metadata
off of files that haven't changed when doing it for entire albums or by
maintenance, but agree there should be an option to override it for cases like
this where something is fd up and probably also not care about it when
doing the operation directly on items.
I haven't looked at the code yet whether this is easily feasible, as I am
working on something else right now (and if Maik does, he will be like 10x
faster anyway).

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #13 from digi...@homemp3.dyndns.org ---
Even simpler: I found out that simply touching the file (updating the last
modified timestamp in the file system, using the "touch" command) and then
re-reading the metadata from file gives the file its Camera Creation Time
(which is then correctly taken from the EXIF tag, not the file timestamp).

This seems to imply that Digikam is keeping state about whether a file has
changed since last read, and the "re-read ..." command seems a no-op if the
file modification time is at or before the time when Digikam thinks it read the
file last.

I would expect an explicit "re-read..." operation to re-read, no matter what
the time stamps say.

Above and beyond that, of course, the root cause for the missing Camera
Creation Date needs to be found, particularly after Mike suggested that an
empty Camera Creation Date cannot occur at all (although it does here).

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #12 from digi...@homemp3.dyndns.org ---
I did another experiment: when I open one of the JPG files affected with GIMP
and simply export it again as JPG, keeping all EXIF information, the timestamp
is updated property when refreshing the folder. It almost seems as if for some
reason the update only happens when the file's contents change (I suppose
exporting from GIMP slightly modifies the binary content compared to how the
camera produced the JPG).

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #11 from digi...@homemp3.dyndns.org ---
I've now switched back to the old DB where at least all my tags seem to be
complete again. The log output digikam gives when doing "Item - Reread metadata
from file" on an item where the camera creation date is not shown is this:

digikam.general: Using  4  CPU core to run threads
digikam.general: Creating a metadata task for synchronizing metadata
digikam.general: Creating a metadata task for synchronizing metadata
digikam.general: Creating a metadata task for synchronizing metadata
digikam.general: Creating a metadata task for synchronizing metadata
digikam.general: Action Thread run  4  new jobs
digikam.general: One job is done
digikam.general: One job is done
digikam.general: One job is done
digikam.general: One job is done
digikam.general: List of Pending Jobs is empty
digikam.general: Event is dispatched to desktop notifier through DBUS
digikam.general: Cancel Main Thread
digikam.general: Cancel Main Thread

Does that look suspicious in any way?

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #10 from digi...@homemp3.dyndns.org ---
Checking the results of the DB-reconstruction shows that certain tags got lost
which is a showstopper for me. Pictures that have to tags in the EXIF info
containe in the file only show one of the two tags in Digikam now. One of the
two tags doesn't show at all in the overall tags list. I can't tell what's
worse: losing tags or not being able to sort by image creation date. I guess
I'll switch back to the old DB for now.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #9 from digi...@homemp3.dyndns.org ---
I now re-created the DB for the whole collection, and the timestamps have
properly shown up. What does that tell us?

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #8 from digi...@homemp3.dyndns.org ---
Created attachment 107824
  --> https://bugs.kde.org/attachment.cgi?id=107824=edit
Screenshot documenting the viewer settings

The viewer settings are such that the Camera Creation Date shall be shown.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #7 from digi...@homemp3.dyndns.org ---
(In reply to Maik Qualmann from comment #6)
> The problem is if the date can not be read from the metadata, the file date
> is used. An empty date can not actually occur.

You can see from the screenshot that the thumbnail viewer is not showing any
date at all, although it is configured to show the "Camera Creation Date". I'll
attach another screenshot to document the viewer settings.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[Maik Qualmann]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #6 from Maik Qualmann  ---
The problem is if the date can not be read from the metadata, the file date is
used. An empty date can not actually occur. I have here times my collection
with 40k images imported into an internal MySQL DB and the problem is not to
reproduce.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #5 from digi...@homemp3.dyndns.org ---
I can try that. It's roughly a 130k images collection, and the DB is running on
a different host on the local network, so it'll take a while to re-build the
DB, I presume. Just out of curiosity: if that "fixes" the issue, what are the
next steps then? Shouldn't the application always restore the file creation
time from the EXIF data when I explicitly tell it to re-read the metadata from
files?

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[Maik Qualmann]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #4 from Maik Qualmann  ---
Can you create a new MySQL DB for test purposes and check if the problem still
exists?

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #3 from digi...@homemp3.dyndns.org ---
So, is this still the correct component for the report? Or is there a separate
one for the MySQL connector?

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[Maik Qualmann]

https://bugs.kde.org/show_bug.cgi?id=384603

Maik Qualmann  changed:

   What|Removed |Added

 CC||metzping...@gmail.com

--- Comment #2 from Maik Qualmann  ---
Yes, I think it is relevant that the problem with MySQL occurs. I've never seen
this problem with SQLite.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

--- Comment #1 from digi...@homemp3.dyndns.org ---
Nota bene: I'm using digikam with the MySQL connector, if that changes
anything.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 384603] Camera Creation Date not set from EXIF data

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=384603

digi...@homemp3.dyndns.org changed:

   What|Removed |Added

 Attachment #107807|Screenshot showing how  |Screenshot showing how
description|Camera Creation Date is not |Camera Creation Date is not
   |display although EXIF data  |displayed although EXIF
   |is present  |data is present

-- 
You are receiving this mail because:
You are watching all bug changes.