# Possible to avoid updating files which have not changed
**URL:** https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492
**Category:** General Discussion
**Created:** [January 14, 2026, 3:01pm UTC](https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492 "2026-01-14T15:01:29Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Daksol](https://community.mp3tag.de/u/Daksol)
#### Post date: [January 14, 2026, 3:01pm UTC](https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492/1 "2026-01-14T15:01:29Z")
Definitely a priority two or three item. And may be more a question to the Developer on why certain choices made.
I have a Podcast I am listening to - and am downloading episodes (as mp3 files) as they come out every week or so. Once the new files added I need to update or populate their tags.
I do this for many tags by highlighting the new files along with some existing ones - that means I can use the selectors in the LH sidebar to set the Album, Artist fields. When I click Save **all** the selected files get a new “Last modified date” - even tho it is only the new files which have actually changed.
Is that the intended or the optimal behaviour? I would have thought it would be better to skip the unchanged files to minimize the related processing.
And from a file management point of view I see it as odd that the last mod date changes on files which have not changed. (And I have verified with a “duplicate detector” program that nothing has changed - eg the file’s hash value remains the same).
_PS: [https://www.conversationswithghosts.com/](https://www.conversationswithghosts.com/) highly recommended_
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [January 14, 2026, 3:05pm UTC](https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492/2 "2026-01-14T15:05:33Z")
These settings might help:
> [@Unwanted File Timestamp Updates](https://community.mp3tag.de/t/unwanted-file-timestamp-updates/59178/4):
>
> 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: [image] 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:
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 14, 2026, 3:16pm UTC](https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492/3 "2026-01-14T15:16:16Z")
> [@Daksol](#):
>
> even tho it is only the new files which have actually changed
It may be an option to fill the field RELEASETIME with the creation date of a file.
Also, it would be worthwhile to check if this field isn't there already as I see that field in a lot of podcasts already with data.
In General: MP3tag does not compare the current tag data with the already found tag data in the files but writes the tag data for all selected files. That leads to a new "modified" date.
---
### Author:  [@Daksol](https://community.mp3tag.de/u/Daksol)
#### Post date: [January 14, 2026, 3:43pm UTC](https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492/4 "2026-01-14T15:43:59Z")
> [@ohrenkino](#):
>
> In General: MP3tag does not compare the current tag data with the already found tag data in the files but writes the tag data for all selected files. That leads to a new "modified" date.
Indeed, that is how it works. My question was why do it that way? - surely not hard to detect the before and after state of the tags to be written, and skip the “write” step for those which have not changed?
The other linked thread mentions that “the application asssumes if users highlights a file then it is assumed it will be edited”. Well actually the earlier files are only being highlighted so I can copy info out of them, not because I want them to be modified.
It is not an issue - just feels like an odd functionality choice.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 14, 2026, 7:16pm UTC](https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492/5 "2026-01-14T19:16:00Z")
> [@Daksol](#):
>
> My question was why do it that way?
Just this thought: it may be just quicker to simply write that what is currently set in the memory and keep only this data in the memory than to either keep all versions in the memory or read the tags from files again, compare the contents and then write the new tag if there is a modification.
@LyricsLover showed you an option to keep the modification date.
---
### Author:  [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [January 14, 2026, 8:06pm UTC](https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492/6 "2026-01-14T20:06:38Z")
> [@Daksol](#):
>
> It is not an issue - just feels like an odd functionality choice.
Just an alternative view on this;
If I make a few changes to one or two tracks from a single album, I typically will then highlight all tracks from that album and save them again. Even without any field changes, this will update the file modification date and force it to be sync'd to various players as a complete album, and not just individual tracks.
There is an option in the settings where you can choose to have mp3tag NOT update the modification date on changes. But this is a universal selection and cannot be applied separately to different file selections.
---
### Author:  [@Doug\_Mackie](https://community.mp3tag.de/u/Doug_Mackie)
#### Post date: [January 14, 2026, 9:00pm UTC](https://community.mp3tag.de/t/possible-to-avoid-updating-files-which-have-not-changed/70492/7 "2026-01-14T21:00:22Z")
> [@MotleyG](#):
>
> Even without any field changes, this will update the file modification date and force it to be sync'd to various players as a complete album, and not just individual tracks.
This is a good point. In addition, when working my way through a great many files, the changed date serves to mark all of the files in the selected sub group that I have checked so far, regardless of which ones I had to modify. This is very useful when I later resume work on the full group of files.