Bug 361137

Summary: Inconsistent timestamp display for MP4 video files in Album View after adjusting date/time
Product: [Applications] digikam Reporter: Jens <jens-bugs.kde.org>
Component: Metadata-VideoAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 4.14.0   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In: 7.5.0

Description Jens 2016-03-29 11:26:58 UTC 
I have a MP4 file (created using HandBrakeCLI) in one of my albums that I created before remembering to set daylight saving time on my camera. So I used "Image > Adjust date and time" to take one hour off the timestamp of the video file. I chose to modify XMP, file timestamp and Digikam database timestamp since videos have no EXIF information. (Right?)

Result: "Properties" tab shows the new timestamp value. "Metadata" tab shows the old value. Value below thumbnail shows the old value. Only after doing the same again and checking all fields (EXIF dates as well) was the timestamp and sort order in Albums View correctly updated.

This seems inconsistent to me. All tabs should show the same value. Or there should be a hint which value is used for the Album view.

Strangely, for other MP4 video files (several at once) this was not necessary, there it worked without having to selecting to modify the EXIF dates.

Reproducible: Always
Comment 1 caulier.gilles 2016-03-29 14:08:29 UTC 
The video file time stamp is handle by Exiv2. Which version do you use ? 0.25 i hope.

If your Exiv2 is not able to handle video time stamp, the FS time stamp will be used instead to populate the DB.

Gilles Caulier
Comment 2 caulier.gilles 2019-07-23 20:58:14 UTC 
it's a duplicate of #401964 ?
Comment 3 caulier.gilles 2020-08-02 13:16:48 UTC 
digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best Regards

Gilles Caulier
Comment 4 caulier.gilles 2022-01-10 15:53:37 UTC 
Fixed with bug #401964