Metadata dates are not preserved when merging video files

[Snelso91]

Share information to help me understand
No error report was given.
Lossless Cut Console Log

I have attached the full metadata of the 1st file and the merged file, as reported by MediaInfo:
Metadata of 1st file
Metadata of 1st file merged with a 2nd file via lossless cut

Describe the bug
When merging two mp4 files using lossless cut, the "encoded date", "tagged date" and "recorded date" fields (as reported by mediainfo) for both the overall file and each individual video/audio track in the file, are not copied over to the merged file.
This is unexpected, as usually when trimming clips with lossless cut instead of merging, each of the date metadata fields in the original file are copied over to the trimmed clip.
Changing the "Preserve all MP4/MOV metadata?" option from No to Yes has no effect (the dates are not copied for both options).

To Reproduce
Steps to reproduce the behavior:

1. Choose any two (or more) mp4 files with date metadata in them
2. Merge them using lossless cut
3. See lack of date metadata in merged output file

Expected behavior
I was expecting that the date fields (there are 9 of them total in this example - 3 for the overall file and 2 for each of the 3 tracks) from the first clip in the list of clips to be merged would be copied to the output (or at least there would be an option to do this), as in my case I often have several recordings that are recorded back-to-back with shadowplay and need to be merged into one bigger file for ease of use.

Preserving the mp4 date metadata of the 1st file in the list (i.e. the earliest one) would help with file sorting, because windows uses the "media created date" (aka "encoded date") field from the mp4 (if it is present) instead of "date created" or "date modified" when using the standard "date" filter/column in windows explorer.
Therefore, having a mixture of normal clips which have the date metadata preserved, and merged clips which don't is causing issues with sorting files correctly by date.

Desktop (please complete the following information):

• OS: Windows 10 Pro 64-bit Version 21H2 (OS Build 19044.1503)
• Lossless Cut Version: 3.42.0

[mifi]

Thanks for reporting. I have now fixed this bug and it should work in the next version! As a workaround until then maybe you can enable "Include all streams" when merging, as well as make sure that "Preserve original metadata when merging? (slow)" is set to YES in the export confirm dialog (then close the export confirm dialog and go back to the merge)

[Snelso91]

Thanks for reporting. I have now fixed this bug and it should work in the next version! As a workaround until then maybe you can enable "Include all streams" when merging, as well as make sure that "Preserve original metadata when merging? (slow)" is set to YES in the export confirm dialog (then close the export confirm dialog and go back to the merge)

Hi, no problem :)

Regarding your workaround, for my example above in the original post I already used the "Include all streams" and "Preserve all MP4/MOV metadata?" options when merging the two files, and metadata was not preserved, so I don't think it works...
I also just tried using those two options plus also using the "Create chapters from merged segments? (slow)" option, but the result was still incorrect (no metadata preserved).

In addition, after some further research I realised that my original request to copy metadata from the first clip in the list to be merged was slightly wrong, and it would actually be better to take the metadata from the last file not the first, since the metadata times are the end times of the file, not the start times (as per #1017).
Therefore, would it be possible to change the new patch to take the metadata from the last file in the list of files to be merged, or perhaps have the option to choose which file the metadata is copied from?

Thanks

[mifi]

can discuss in that issue. I'll close this because I implemented it. not sure why the workaround didn't work but we can reopen later if it doesn't work in the next version