SUMMARY Download videos from Canon EOS R7 have wrong names when renaming using date pattern for file name. I am using following pattern to rename files while downloading from my EOS R7 Camera [date:yyyyMMdd_hhmmss]_R7. The camera is set to timezone UTC-7 (Los Angeles) the PC is set to same time zone. Resulting files are named after UTC time and not actual Time Zone they where shot. This only affects videos. EOS R7 has latest firmware from Canon STEPS TO REPRODUCE 1. Set Canon EOS R7 Camera and PC to Los Angeles Time Zone (I guess any non UTC timezone would do) 2. Shot a video using the camera, take note of the date and time you shot the video 3. Download the video using Digikam using auto dtected camera. Make sure to use a custom renaming file naming scheme, I use [date:yyyyMMdd_hhmmss]_R7 but I guess any pattern containing a date would lead to same issue OBSERVED RESULT - Downloaded file name has wrong name. E.g. if the video was shot on May 1st 2024 at 13:01:27 resulting file name will be 20240501_200127_R7.MP4 EXPECTED RESULT - Downloaded file name should be named according to shot time, as per above example 20240501_200127_R7.MP4 SOFTWARE/OS VERSIONS Qt 5.15.10 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 13.2.0) on "xcb" OS: Debian GNU/Linux trixie/sid [linux version 6.7.12-amd64] ADDITIONAL INFORMATION - Running Gnome Desktop v46, Wayland - It seems that the EOS R7 is using UTC for file date attributes
We need a very short sample video to recognize the camera as a correct UTC date device. See also bug 479676. Maik
(In reply to Maik Qualmann from comment #1) > We need a very short sample video to recognize the camera as a correct UTC > date device. See also bug 479676. > > Maik Well I'm not sure how this would help, I checked the video file with VLC and it has no metadata. As soon as the file is on my PC it's attributes are the dates when Digikam imported the file. Anyway here is the file: https://drive.google.com/drive/folders/19wFW27YYRcmR6KWPuJyMDPTbbqp7iSBm?usp=sharing It was shot on 20240509_214213 (Los Angeles Time) and has been renamed to 20240510_044213_R7.MP4 on download. In the import window the correct time is shown.
Git commit 24c0ed017b776f5f7e96c5e168ff088e1ab76ba9 by Maik Qualmann. Committed on 11/05/2024 at 11:28. Pushed by mqualmann into branch 'master'. disable date/time reading with FFmpeg parser We now only use ExifTool. This also has the advantage that ExifTool can also read the set time zone for many videos. We will see if this behavior causes fewer problems in getting the correct video time. FIXED-IN: 8.4.0 M +1 -1 NEWS M +14 -13 core/libs/metadataengine/dmetadata/dmetadata_video.cpp https://invent.kde.org/graphics/digikam/-/commit/24c0ed017b776f5f7e96c5e168ff088e1ab76ba9
(In reply to Maik Qualmann from comment #3) > Git commit 24c0ed017b776f5f7e96c5e168ff088e1ab76ba9 by Maik Qualmann. > Committed on 11/05/2024 at 11:28. > Pushed by mqualmann into branch 'master'. > > disable date/time reading with FFmpeg parser > We now only use ExifTool. This also has the advantage that > ExifTool can also read the set time zone for many videos. > We will see if this behavior causes fewer problems in > getting the correct video time. > FIXED-IN: 8.4.0 > > M +1 -1 NEWS > M +14 -13 core/libs/metadataengine/dmetadata/dmetadata_video.cpp > > https://invent.kde.org/graphics/digikam/-/commit/ > 24c0ed017b776f5f7e96c5e168ff088e1ab76ba9 Thanks for the quick fix. Is there any build I could use to test it?
I will rebuild the Linux bundle today : https://files.kde.org/digikam/