SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** I have a combination of JPEG and MOV files taken with an iPhone, in both California and Scotland. I live in Connecticut. The timestamp on the phone, as well as in the OS X Finder after I upload them at home, displays the date and time they were taken in those locations. But when I load them into Digikam and try to group them together in albums sorted by date, they don't sort correctly. The metadata for the video files from California shows a time 3 hours later than the time they were taken, while the video files from Scotland show a time 5 hours earlier. In effect, both appear to be adjusting to EST based on the original GPS location of the photos/videos. But JPEG photos taken at the same time with the phone do not show this adjustment, as the metadata correctly shows the time the photo/video was shot in that time zone. As a result, without manually adjusting the time in the metadata for each of these videos, they will not sort properly alongside photos taken at the same time. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
This is a long discussed problem. Depending on the camera model (iPhone, camera, Android), we evaluate the time zone stored in the video metadata in order to come very close to the actual result. Unfortunately, some set the time zone correctly, others not. he current result is based on a long series of tests by users who have provided us with video samples. We need an image and video sample to analyze the problem. Maik
Created attachment 151082 [details] attachment-26530-0.html Dear Maik, Thank you for the quick reply. I am sending links to a JPEG and MOV that were taken about 3 minutes apart in the same location, in a time zone 5 hours later than my current one. In Digikam the JPEG has the time 2:08 PM, which was correct in that time zone, while the MOV has the time 9:05 AM, which was the time in my current location. My assumption would be that GPS data shouldn't be used to modify times, since the time considered as the proper time when viewing images and videos should be the time of day they was taken locally, regardless of the time zone. While I don't understand fully how different devices register time stamps on files, it seems that in this case the JPEG and MOV files have the correct timestamp in the file properties, as they appear on disk, so I wouldn't see any need to adjust this. Anyway, thanks for looking into it. Here are the links: http://gofile.me/6Z828/3Xh4j2VeLhttp://gofile.me/6Z828/bdNENHL8i Alec McLane On Tuesday, August 2, 2022 at 04:24:47 PM EDT, Maik Qualmann <bugzilla_noreply@kde.org> wrote: https://bugs.kde.org/show_bug.cgi?id=457421 Maik Qualmann <metzpinguin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WAITINGFORINFO CC| |metzpinguin@gmail.com Status|REPORTED |NEEDSINFO --- Comment #1 from Maik Qualmann <metzpinguin@gmail.com> --- This is a long discussed problem. Depending on the camera model (iPhone, camera, Android), we evaluate the time zone stored in the video metadata in order to come very close to the actual result. Unfortunately, some set the time zone correctly, others not. he current result is based on a long series of tests by users who have provided us with video samples. We need an image and video sample to analyze the problem. Maik
Hi Alec, does the link still work for you? I get an error page that it could not be found after an animated page that the connection is being established. Maik
Created attachment 151096 [details] attachment-6234-0.html Sorry about that! It happened to me the first time, but then after that the links worked. If they still don't work, try them here in Google Drive: https://drive.google.com/file/d/1DAwqmSEeeAOBU61eFPMoZfKB-EOIOzvr/view?usp=sharing https://drive.google.com/file/d/1Ji-ka59GB3LbE5FPl7Zse3SdHz3_mrMs/view?usp=sharing Thanks again. Alec On Wednesday, August 3, 2022 at 02:02:20 AM EDT, Maik Qualmann <bugzilla_noreply@kde.org> wrote: https://bugs.kde.org/show_bug.cgi?id=457421 --- Comment #3 from Maik Qualmann <metzpinguin@gmail.com> --- Hi Alec, does the link still work for you? I get an error page that it could not be found after an animated page that the connection is being established. Maik
Git commit 5592aeec4b1f7a51170b94cc6ffa9c07534190c8 by Maik Qualmann. Committed on 04/08/2022 at 06:02. Pushed by mqualmann into branch 'qt5-maintenance'. ignore creation date timezone from Apple video files FIXED-IN: 7.8.0 M +2 -1 NEWS M +11 -0 core/libs/metadataengine/dmetadata/dmetadata_video.cpp https://invent.kde.org/graphics/digikam/commit/5592aeec4b1f7a51170b94cc6ffa9c07534190c8
To correct the creation date, the metadata must be read again from the video files with digiKam-7.8.0. Either via the item or album menu or with the maintenance tool. Maik
Git commit cd2641ac5678b297dfe52834be52eabac1d7790e by Maik Qualmann. Committed on 04/08/2022 at 17:58. Pushed by mqualmann into branch 'qt5-maintenance'. better handling of the time zone M +8 -4 core/libs/metadataengine/dmetadata/dmetadata_video.cpp https://invent.kde.org/graphics/digikam/commit/cd2641ac5678b297dfe52834be52eabac1d7790e
Created attachment 151115 [details] attachment-12100-0.html OK, thanks very much for your help. I don't see 7.8 available yet, so will wait for it to come out. Alec On Thursday, August 4, 2022 at 02:06:19 AM EDT, Maik Qualmann <bugzilla_noreply@kde.org> wrote: https://bugs.kde.org/show_bug.cgi?id=457421 --- Comment #6 from Maik Qualmann <metzpinguin@gmail.com> --- To correct the creation date, the metadata must be read again from the video files with digiKam-7.8.0. Either via the item or album menu or with the maintenance tool. Maik