Bug 472520 - Date for Videos should be sourced from Video metadata instead of filesystem file modify date
Summary: Date for Videos should be sourced from Video metadata instead of filesystem f...
Status: CONFIRMED
Alias: None
Product: kphotoalbum
Classification: Applications
Component: Backend (show other bugs)
Version: GIT master
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KPhotoAlbum Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-23 06:06 UTC by Victor Lobo
Modified: 2023-10-30 22:16 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Lobo 2023-07-23 06:06:35 UTC
SUMMARY
On initial setup, KPhotoAlbum processed my photos and videos. For each video that it found KPhotoAlbum assigned it the filesystem File Modify date. My expectation is that KPhotoAlbum would assign a date from the video metadata (CreateDate, DateTimeOriginal etc.) since most of my videos have that populated and those dates are correct (as compared to file modify date).

This behavior can also be observed in the KPhotoAlbum demo. The demo contains a video "movie.avi" with DateTimeOriginal value "2006:10:29 14:33:55" reported by ExifTool. digiKam also displays  "2006:10:29 14:33:55".  If I do one of the below then KPhotoAlbum assigns the file system file modify date (current date) to the video instead of "2006:10:29 14:33:55":
1. Select the movie file in the demo and then do (Maintenance --> Read Exif Info from Files... --> Check ONLY "Update Image Date" --> OK)
OR
2. Copy the movie file from the demo to a new KPhotoAlbum database


OBSERVED RESULT
After processing video files KPhotoAlbum assigns the file system file modify to the videos

EXPECTED RESULT
After processing video files KPhotoAlbum assigns the appropriate date time from video metadata (CreateDate, DateTimeOriginal etc.) 

SOFTWARE/OS VERSIONS
Linux: openSUSE Tumbleweed 20230714; Kernel Version: 6.4.2-1-default (64-bit)
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10

ADDITIONAL INFORMATION
1. Opening this as a bug as per discussion on the KPhotoAlbum mailing list: https://mail.kde.org/pipermail/kphotoalbum/2023-July/007002.html
2. Note that the video date may be captured in different metadata tags in different files (for example QuickTime:CreateDate, XMP-exif:DateTimeOriginal etc.)
3. Workaround suggested by Johannes Zarl-Zierl: Adjust your file modification dates
exiftool -FileModifyDate\<DateTimeOriginal movie.avi
or for a whole directory tree:
find /Images -regex '.*\.\(avi\)\|\(mp4\)' -exec exiftool
-FileModifyDate\<DateTimeOriginal \{\} \;
Comment 1 Johannes Zarl-Zierl 2023-10-30 22:16:27 UTC
Just some notes for a potential fix:
A good location to read creation_date would be in VideoLengthExtractor (although that needs some change at least in its name then).
The following command can be used to read the creation_date in addition to the video length:
`ffprobe -v 0 -show_entries format_tags=creation_time:format=duration -of default=noprint_wrappers=1:nokey=0`

One thing that needs working out if we use ffprobe, though: some video files have local time, some have UTC. I.e. some (most?) (phone-)cameras store the time as UTC, but no offset.