| Summary: | After the import, some metadata was not read from the image. | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | iain <iain+kde> |
| Component: | Setup-Metadata | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ag.olivier, caulier.gilles, emilise.victor, metzpinguin, michael.maier, mike, peter.heller, sse450, tom |
| Priority: | HI | ||
| Version: | 7.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | 8.1.0 | |
| Sentry Crash Report: | |||
| Attachments: | Screenshots and image | ||
digiKam Setup/Metadata/Advanced can be used to configure where to extract information from file metadata. But date is not yet managed in this hub. Gilles Caulier DigiKam determines the correct date here. Execute an "Item-> Reread Metadata From File". Why this sometimes occurs on Windows is unclear. My guess is that the file is blocked by another program during the scanning process and digiKam cannot read the metadata. Maik MAik, I read somewhere that application which do not come from the M$ Store has limited system access with restriction. The ultimate solution is to build push the application to the store officially. The problem for now: KDE binary build system with MSVC do not work, even if Windows CI from KDE work as expected. System are different, with separated config and of course the most important target build do not work, with digiKam. My investigation results: it's a too long build path problem on the binary build system. I tried to advance on this problem with the KDE team, but, nobody is interested to work on it, as usual... I explored other huge KDE application to see if a difference can be seen somewhere in CMakeLists.txt files with compilation rules. Nothing special, but... ...in Krita project i seen that MXE still in use to build target. The application is also published to the M$ Store, so, it's possible to backprocess MXE build with MSVC to make the UWP container to publish officially. The rules are here for Krita: https://invent.kde.org/graphics/krita/-/tree/master/packaging/windows/msix This is definitively the right way to go in the future... Gilles *** Bug 418669 has been marked as a duplicate of this bug. *** Maik - "Item-> Reread Metadata From File". This fixed the issue. Thanks! "My guess is that the file is blocked by another program during the scanning process and digiKam cannot read the metadata." - I'd agree. Gilles - I've developed application on Windows for years that aren't in the windows store and never seen them denied access to files, once you have said they can run. Files being locked is definitely a problem, in fact I used to see this in Lightroom before I switched to Digikam :-) Thanks you both for your help. *** Bug 428526 has been marked as a duplicate of this bug. *** *** Bug 428526 has been marked as a duplicate of this bug. *** *** Bug 426857 has been marked as a duplicate of this bug. *** *** Bug 431121 has been marked as a duplicate of this bug. *** *** Bug 460111 has been marked as a duplicate of this bug. *** *** Bug 462814 has been marked as a duplicate of this bug. *** *** Bug 463425 has been marked as a duplicate of this bug. *** Git commit 4b31f11f112cfda823237e85fa1810a6b1988b8c by Maik Qualmann. Committed on 05/02/2023 at 15:46. Pushed by mqualmann into branch 'qt5-maintenance'. fix scanning files when importing folders Related: bug 465312, bug 465045 FIXED-IN: 7.10.0 M +3 -1 NEWS M +11 -4 core/libs/database/utils/ifaces/dio.cpp https://invent.kde.org/graphics/digikam/commit/4b31f11f112cfda823237e85fa1810a6b1988b8c @iain, digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier Problem fixed with commit listed to comment 13 ...and bugs closed : https://bugs.kde.org/show_bug.cgi?id=465312 https://bugs.kde.org/show_bug.cgi?id=465045 |
Created attachment 130013 [details] Screenshots and image SUMMARY On some images Digikam is not recognizing the date from the metadata and instead defaulting to the Created Date. This results in: 1. Image being grouped into the wrong month in thumbnail view (see screenshot) 2. Image not being renamed correctly when renaming based on `[date]` STEPS TO REPRODUCE Attached example which produces this behaviour on my computer. This photo was taken on 20-June but imported onto the computer on 09-July. OBSERVED RESULT When grouping by month the image is listed under July When renaming by date, the date chosen is 2020-07-09 (I named the file manually to get the correct date) EXPECTED RESULT When grouping by month the image is listed under June When renaming by date, the date chosen is 2020-06-20 SOFTWARE/OS VERSIONS Windows: 10 Digikam 7.0.0-rc ADDITIONAL INFORMATION - I believe this is a digikam problem. exiv2 reports the correct date (see attached screenshot) - I haven't been able to determine what is the problem with this image. I have other examples taken on the same day with the same camera that are dated correctly.