@arb I’ve been working with iTunMOVI to update DIRECTOR and WRITER, and when I went to back up the updated records using Robocopy, no records were backed up. It appears that modifications to the iTunMOVI tag somehow bypass flagging the records as having been updated to they aren’t being backed up. Can that possibly be, or is something else going on? Is it even remotely possible that Mp3tag is updating iTunMOVI in the the metadata part of the mp4 container without flagging the mp4 container as having been changed?
Definitely nothing to do with Mp3Tag or the action but I’m not sure if the file having ITUNMOVI attached is being seen as a change as honestly, it seems like it should? It’ll contribute to the file’s overall size and change its last modified date…
I’m also not sure how ITUNMOVI is treated regarding the structure of an MP4 as it is effectively a custom, non-official tag made up by Apple.
Sorry but I’ve no experience with Robocopy; I’ve had a quick search on the forums and @LyricsLover might be able to assist, otherwise I’d advise looking into how Robocopy detects changes to a file that initiates a backup.
If there are any issues with what I’ve provided, I’m still happy to help out however I can. 
For the record, I’m grateful for your support, didn’t mean to impugn you or your efforts in any way whatsoever and I tagged you because I got the impression that you are remarkably well informed. I’ve done a little research on my own and it appears that mp4 container update flags are date and file size, and that there is often sufficient padding to keep the size of the container static for relatively minor changes and that it is possible to make changes that bypass updating the date. Thanks again for your help in the past.
Please check the options>General>Preserve modification time when saving tags.
It should be easy for you to check if a modification by MP3tag also sets a new modification date.
The “preserve modification time” box is not checked.
What happens to the file modification date if you apply an action?
If I apply an action and only an action, the record does not get backed up. And the only action I’ve ever used is “Create iTunMOVI.mta” so I don’t know about any other actions
So, if you apply that action - what happens to the file modification date? Please check it in the WIndows Explorer before and after you applied the action.
Forget it - I’m done. Thanks anyway.
So far, just to get it right:
Even if the padding in a file should be large enough for the modification, the OS still updates the "last modified date" - this could easily have been investigated by the OP.
The OS has to be forced to show the old date which can be set in MP3tag to preserve the modification date. As that is not the case, it is down to the functions of the third party program, Robocopy and the use of it.
In addition to @ohrenkino's answer:
ROBOCOPY does not check the contents of files. It only compares timestamps and file sizes, so any internal changes that do not update the timestamp or do not change the file size will not be detected.
If someone want to preserve the timestamp and the file size does not change due to minor internal modifications, ROBOCOPY is not the right tool. ROBOCOPY does not have a checksum feature, such as MD5, SHA-1 or SHA-256 comparison.
@arb - I think the Robocopy issue is related to your iTunMOVI action and here’s why:
I just thought of something that I think might be related to the Robocopy backup issue with itunMOVI tag updates. I noticed it at the time and it seemed weird but harmless. But now I'm having second thoughts. The thing is, after I run the "Create iTunMOVI" action, the changes seems to take effect immediately. Other Mp3tag changes require being saved to be committed. iTunMOVI action does not - and that's a good thing because that's what enables an entire selected list of titles to be processed with a single "action". So if the action updates don't require being saved, that might very well explain why the container never gets marked as having been updated and therefore, Robocopy has no reason to back it up.
What have you done to substantiate your unfounded speculations?
Excplicit saving is only required when working in the tag panel - as otherwise MP3tag would not know when you have finished the modifications and you would have to wait after each edit in a field.
Working on single files and single fields in the file list saves the modification immediately.
Actions also save the result without extra user interaction.
I also do not know of any special "updated" marker only for a container. It is the OS that governs archive flags, modification dates and reports about file size - all these are file properties, not tags.
No thanks, until and unless you come up with a better explanation I’m satisfied with mine. Cheers!
I tried out the action and several others on a file and “Date modified” does indeed change, implying the changes were saved when the actions were ran.
Sorry but you’ll need to look into other causes. 