Bug 367649

(Using Digikam 5.1.0 and exiv2 v0.25 on OpenSUSE LEAP 42.2 alpha.
My workflow includes renaming imported picture files to the yyy-mm-dd_hhmmss_camera.jpg format, and using the batch tool to ensure the last modified file timestamp equals the exif data.  I do the latter to ensure that when exporting albums to Google Photos, the albums sort correctly (if some pictures have modified file stamps with a later date, Google Photos will use those dates in the date-range the album, resulting in incorrect album sorting).

When using the Batch tool to update the File Last Modified timestamp, it will make zero-byte files out of MP4 files in the selection - effectively deleting them.

Steps to reproduce:

1. Goto an Album folder that include both JPEG files and MP4 video files
2. Select all files in the album (I usually click the album header in the main panel)
3. Click the Batch Queue Manager button in the tool bar
4. Select the Time Adjust tool in Metadata in Base Tools
5. Choose settings for target folder and behaviour if target file name already exists
6. Click run

The effect is  that all JPEG files get their File Last Modified timestamp updated, however any MP4 files processed end up being a 0-byte file.   This happens whether you chose Overwrite or Rename as behaviour.  However, I usually choose Overwrite behaviour because I want to update the timestamps of existing files.
This results in the ORIGINAL MP4 files being zeroed out and thus gone forever!

I have tested this with MP4 files created by an Panasonic FZ220 camera and a Samsung Galaxy S4 phone, the result is the same.

Proposal:
I propose that if digikam is unable to read the created/original timestamp EXIF info (via exiv2 tool), then it should not attempt to update the file at all.  Processing should skip the MP4 files.