[digikam] [Bug 367649] New: Adjusting File Last Modified timestamps makes 0-byte files out of MP4 video

[Roger Foss via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=367649

            Bug ID: 367649
           Summary: Adjusting File Last Modified timestamps makes 0-byte
                    files out of MP4 video
           Product: digikam
           Version: 5.1.0
          Platform: openSUSE RPMs
                OS: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: BatchQueueManager-Tool-TimeAdjust
          Assignee: digikam-devel at kde.org
          Reporter: roger.foss at gmail.com

(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.