Created attachment 107807 [details] Screenshot showing how Camera Creation Date is not displayed although EXIF data is present Digikam doesn't seem to read timestamps properly from image files into the "Camera Creation Date" property that can also be shown underneath the thumbnails. The EXIF information is all there, including "Date and Time" but randomly for about 30% of the images in an album Digikam does not show a date in "Camera Creation Date". Subsequently, sorting images by date isn't reasonably possible, turning chronological slideshows into a no-go. I've already tried "Item - Reread Metadata from Image" to no avail. Neither, the "Tools - Maintenance" feature was able to fix this.
Nota bene: I'm using digikam with the MySQL connector, if that changes anything.
Yes, I think it is relevant that the problem with MySQL occurs. I've never seen this problem with SQLite. Maik
So, is this still the correct component for the report? Or is there a separate one for the MySQL connector?
Can you create a new MySQL DB for test purposes and check if the problem still exists? Maik
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?
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
(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.
Created attachment 107824 [details] Screenshot documenting the viewer settings The viewer settings are such that the Camera Creation Date shall be shown.
I now re-created the DB for the whole collection, and the timestamps have properly shown up. What does that tell us?
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.
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?
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).
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).
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 f****d 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).
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