I have a few mp4 files taken on the same camera a a few days apart. They are listed by digikam as having dates many months apart even though their file modification times and exif dates are correct. Also they show no exif information (probably because digikam uses exiv2 where exiftool is needed for mp4 files), so I would not expect very good date interpretation based on that. I named two files a.mp4 and b.mp4. relevant part of exif data for a.mp4, from exiftool: File Modification Date/Time : 2012:12:10 08:46:12+09:00 Create Date : 2012:12:10 16:46:13 Modify Date : 2012:12:10 16:46:13 Track Create Date : 2012:12:10 16:46:13 Track Modify Date : 2012:12:10 16:46:13 Media Create Date : 2012:12:10 16:46:13 Media Modify Date : 2012:12:10 16:46:13 and for b.mp4 File Modification Date/Time : 2012:12:05 19:45:20+09:00 Create Date : 2012:12:05 10:45:20 Modify Date : 2012:12:05 10:45:20 Track Create Date : 2012:12:05 10:45:20 Track Modify Date : 2012:12:05 10:45:20 Media Create Date : 2012:12:05 10:45:20 Media Modify Date : 2012:12:05 10:45:20 digikam shows file a.mp4's date correctly but shows b.mp4 as march 12 2013 So I do find . -name a.mp4 -printf "Access time: %a \nStatus change time: %c\nModification time: %t\n" and get: Access time: Sat Mar 2 01:05:34.0000000000 2013 Status change time: Tue Mar 12 00:12:22.0821103309 2013 Modification time: Mon Dec 10 08:46:12.0000000000 2012 and for b: Access time: Sat Mar 2 01:05:32.0000000000 2013 Status change time: Tue Mar 12 00:12:08.0697812115 2013 Modification time: Wed Dec 5 19:45:20.0000000000 2012 So everything that I have found so far looks basically the same. But digikam says that file b has the correct date of 12/05/12 7:45 PM where it lists file a.mp4 as: 3/12/13 12:12am The only field that I found that matches the wrong date is thus the status change time, but that has the wrong date for both files, so I probably haven't fully tracked down what digikam is doing here. I'll try to have a look at 3.0.0 ( I have a buggy windows version of it installed in windows) and see if it's doing the same thing. One note, actually modifying the file (with touch) changes both the status time and the modification time, whereas copying the file with cp -a only changes the status time, so modification time is better. Of course metadata is far better than either. Reproducible: Sometimes Actual Results: some mp4 files are listed by the wrong time, aparently file status change time. Expected Results: All files are listed by meta data creation time or at worst, file modification time.
To clarify, digikam references dates in a couple of places. The date listed in the properties side panel or in the tooltips is correct. It is the date listed under the thumbnail (if date display is enabled) that is wrong. The most important point though is that the date sorting is based on the wrong date, the one shown under the thumbnail. Before noticing this bug I was not use the date display for thumbnails. I noticed the bug because of the wrong sorting and was puzzled since the tooltip date disagreed with the date sort. I then turned on thumbnail date display and noticed the incorrect date shown there.
Video metada have been supported with 3.0.0 release, not 2.9.0. video metadata are managed in background by Exiv2 shared library which is not yet released. All your remark about MP4 files metadata cannot be interpreted properly for the moment. If you want to test video metadata, update to last digiKam 3.1.0, which must be compiled against current Exiv2 implementation from svn/trunk (next 0.24 release) Best Gilles Caulierr
Ok. I may check that soon and, as I indicated, I'm not surprised by the answer since I did notice that metadata is not displayed and implicitly noticed that the time that is used cannot possibly be related to metadata. However, this doesn't explain what filesytem data is being used (why isn't it ONLY the file modification date?), or why two files handled in the same way showing the same date characteristics are treated with very different dates by digikiam, or (especially) why the date used for sorting and filtering and thumbnail view disagrees with the date shown by the tooltips or properties view. The ultimate solution might be a feature enhancement and might be underway, but the problem still represents a bug in 2.9. I don't know if you apply bug fixes to previous versions or just move forward with something like this to improve the new implementation instead, but there does seem to be a true bug in 2.9. So I'm setting this back to uncomfirmed, but if you still disagree I guess I'll leave the status alone next time. I have a number of my own metadata manipulation scripts so I'm aware that at least the command line form of exiv2 isn't even able (or hasn't been) to even read video metadata. (but I still use it for images because it's MUCH faster and fall-back to exiftool for video metadata read operations). Actually I can use these scripts to batch reset the filesystem dates to match the metadata dates. Hopefully if I set both status time and modification times this problem will go away for me at least, but that obviously doesn't make the bug fixed.
Created attachment 78128 [details] snapshot of conflicting dates Here's a screenshot of the thumbnail label and tooltip both showing with conflicting dates. The thumbnail date is partially obscured, but you can easily see enough to notice the conflict.
Here, you can see that Exiv2 0.24 support MP4 video files http://dev.exiv2.org/projects/exiv2/wiki/Supported_video_formats digiKam is already ready to read and manage everywhere video metadata, since 3.4 release (4.0 is better) : https://www.flickr.com/photos/digikam/14390869744/ Gilles Caulier