Unwanted File Timestamp Updates

I have a master library on my main PC which I then sync to multiple other locations, and may have to sync back as well, but I have difficulty identifying which files need to be synced.

It ought to be possible to use the Archive flag, but Windows doesn't make it very easy to copy according to whether that flag is set. I could probably write a batch process to do it, just not got around to that yet (note to self).

If I turn off timestamp updates in MP3Tag, I can't identify updated files by their timestamp. If I turn on timestamp updates, MP3Tag seems to "touch" files even if I accidentally double click a field in the listing, thus opening it for edit.

Have I got some setting wrong? Am I doing something wrong? Does anybody else see this / not see this? What do other people do to keep multiple deployments synced (I resort to copying the whole lot at times, which is lengthy and not useful if there have been alterations in more than one place)?

I have Foobar2000 in the mix, which is also capable of updating tags in audio files.

All comments and tips welcome.

This thread is still valid:

In my configuration, the timestamp in Mp3tag is activated.
I copy all touched files periodically to all my various backup destinations with the above mentioned ROBOCOPY.

In this (german) thread, another (GUI-) Tool called FreeFileSync was suggested:

Don't you have trouble with unwanted timestamp updates?

TBH, I can't tell you for sure.

Every double click on a file in the main File List of Mp3tag automatically save it.
Please also check your Tags options:

Every time I run Robocopy I have to copy thousands of files, so it doesn't really matter, if some more "untouched" files will be transferred.
The copy process runs in background, I can do something else in the meantime.

Maybe this question/answer (do not be confused by the title) can help you too:

From the link to my posting above you know that I use FreeFileSync. This software has 3 alternative options for detecting the necessarity to sync:
Filetime and Size
File Content
File Size

The only practical way for me is "Filetime and Size". I try to prevent mass change of the timestamp in Mp3Tag, which can occur if you don't make use of filters and apply changes on your unfiltered complete library. The few accidently happening changes of the timestamp don't really slow down syncing.

The option "File Content" could be a solution to not using the timestamp but detecting different content between files takes much more time than unnecessary syncing files with accidently changed timestamps.

i must make some time to do trials: find out what exactly MP3Tag (and FB2K) does to files under what circumstances and according to settings. It doesn't work for me to just turn off timestamp updating completely (unless the archive flag can act as a substitute), nor copying files "just in case". And do my current copy operations preserve timestamps? Not sure.

There is a risk of specific files being marked "changed" (whether that be by archive bit or by timestamp) in two places, so then I need to check whether there was an actual change in one or other of the copies to be treated as "master", and if there was an actual change in both flag that up for manual inspection and repair. Obviously it would be best not to mark a file as changed unless it really has been!

I wasn't aware of the robocopy command, but I see it has a plethora of command switches available. That might well form the basis of a series of BATs.

Thanks all, will report back.

1 Like

I have concluded MP3Tag (3.18) has some undesirable behaviour, in that it touches files (ie sets the A attribute, and updates the timestamp if not disabled in settings) when it doesn't need to. I'll take this up in the appropriate area of the forum.

I am not very confident that you will get MP3tag to change the behaviour to write back the tag data once you have opened the file.
MP3tag does not compare whether you have made any changes.
Getting into edit mode for a field is action enough to assume that you as the user wanted to modify something.

Also, instead of changing MP3tag's behaviour it would be an idea to change a workflow which seems to include more or less random changes to files instead of having a master collection and then a number of slave installations into which all files that seem to have been modified in the master can safely be copied.
To avoid allegedly unwanted changes, the extensive use of filters helps to narrow down the files that really need treatment.
All this as a firendly hint on how to overcome the problem until the

has been changed.

See here: Alteration Request: Make MP3Tag Not Touch Files Unless It Has To

Is it? You've never had a slip of the mouse?? That is a lazy assumption by the software and not user-friendly.

Just because it doesn't, doesn't mean it couldn't. Write comparison need not be required, just a flag to register input has occurred and not just that the tag field was highlighted. I would also suggest nothing should be committed unless Enter/Return gets pressed (which is the data-processing meaning of that key!). People who do want changes committed regardless could have an option setting.

Change the user to suit the software rather than the software to suit the user? Hmm.

I know that a number of features have been introduced to MP3tag in the meantime that where out of the question until otherwise.

Form my point of view it is always a question of give and take.
MP3tag offers you a couple of features (as a freeware program) and you see the advantages and perhaps the problems.
You have now a problem coming from a certain workflow - and I cannot judge how pressing that problem is.
If it is a bad problem, then currently the only way around is to avoid the steps that lead to the problem. Suggestions have been made.
If it is no real problem then you can probably live with it until the function is implemented in the program.
So, I do not know what your approach will be.
You have written the request which is the only way to do it.
But as always with requests it is not easy to find out whether the request aims at the implementation of just one particular function or whether it is a plea for help to find a way around it.

Of course I have double-clicked on places that later on proved to be not the right ones.
But perhaps your use of MP3tag is not the optimum way.
MP3tag is a tagging program, so the first purpose is to make tagging as easy as possible. The double click or the simple click is therefore assumed to start editing - not playing a track.
If you have the workflow that goes through your collection manually and only occasionally, you want to edit the data, then perhaps the use of a dedicated player like Foobar would be the better approach.
That usually plays a track instead going into edit mode.
And if you want to use MP3tag for editing, then simply drag&drop the entry from Foobar to MP3tag. This would avoid the ambiguity of your intentions.