i was just in the middle of setting up my media library in foobar with playback statistics by creating an action to write the file creation date %_file_create_datetime% to %added%, so i can import it in foobar. thats when i noticed something odd: since i force-sorted my autoplaylists by date-added and the date-added was now the date-created, the files kept moving further and further down everytime i changed a tag. upon looking closer i found mp3tag was changing the file creation date by +1 hour each time i saved the file!
the weird thing is, among roughly 10 files i tested (with various attributes) there were 2 files that were not affected by this. i have tested for length, bitrate, year (tag and filestamp), no tags, no cover, id3-version, renaming the file itself, different directory, rebooting, deleting mp3tag config - until i decided to just reinstall v2.77 and thats when the problem stopped. these were all mp3s by the way.
after i found the problem i decided to test for system time and whether my time zone has something to do with this, this is where it gets weird again: so apparently this bug only occurs between utc -2 and utc +3. so -1, 0, +1 and +2. curiously, it always moves 1 hour forward. and again, the same 2 files were completely immune to this.
anyway, i think this is important to address as fast as possible, some people might lose valuable information from this bug!! i almost wrecked an entire years worth of files if i hadnt tested it first.
bug occurs on v2.81 and v2.81a
EDIT: i forgot to mention, i always use the option "preserve file modification time". so when i turned that off, it also stopped changing the creation date - but then of course it changes the modification date .... so i had to test further because for me thats not an option.
Depending on the extent of the tag modification, a file has to be rewritten to cater for the new amount of data. So, MP3tag creates a temporary copy (which then has a new creation date), deletes the old one and renames the new file.
MP3tag usually does not reduce the padding ... so even empty tags could mean that the file does not get re-created with an intermediate tmp-file.
Do the files reside on an external drive like a NAS?
And: I checked a file that I know I modified yesterday:
Creation date is still the same (which could be determined as I have filled the field RELEASETIME) but the modification date is set to yesterday.
hmm, well i did try removing ALL tags and just "empty-save" them and it still did that..
no, all internal. occurs on single ssd and raid-0 hdds.
i could provide you some example files, 1 where the problem occurs and 1 where it doesnt. or if you could provide me with the version before 2.81 and i could try it on that. somehow i feel like it has something to with the new "portable mode" feature (i dont use portable mode), considering changing the time zone fixed the problem...
hmm, are you saying its because the creation-date is later than the modification-date? either way, ive never noticed this behavior before and in v2.77 it doesnt happen..
i tried different id3 versions, it happened regardless.
also, do you have "preserve file modification time" enabled? again, when i turned that off, the problem stopped. its just that i need to preserve the modification date so for me turning that off isnt a solution.
I just rechecked:
Even with the option "preserve file date" I can see nothing suspicious: right now the create date is the 22nd of July, the modification date is the 20th of July... just as one would expect.
So it does not seem to be a file problem but a file system problem.
You are right:
Preserving the modification date and saving increases the hour of the creation date by one each time you save the file.
Fascinatingly: as soon as you allow the modifcation date to be updated, only the modification date gets updated.
As soon as you turn that off again, each save increments the creation date by one hour.
But this only works on the files that you labelled as affected.
alright, im not at home right now, but when i come back i will reinstall v2.81 and try with files that dont have a later creation-date than modification-date.. maybe that is the culprit. indeed, i did not check for that when i tested the bug. also, again, v2.77 doesnt exhibit this behavior at all and i have never seen this before either, working with all kinds of files, doing all kinds of weird things with timestamps.. mp3tag so far has always been 100% reliable.
I cannot see what the difference is between a file that is affected and one that is not.
Even turning the "keep modification date" on and off leads to that one hour increment.
So: allowing MP3tag to modify the modification date shows nothing suspicious.
Not allowing MP3tag to modify the modification leaves the files as they are for "not affected" ones.
But the ones that were affected once return to their behaviour as soon as the modification date is kept. And that applies even when the modification date is younger than the creation date ...
I am at my wit's end as I cannot judge who the culprit is.
I think I have got it:
It is the daylight savings time.
Files that have been created during the summertime (with an offset of 1 hour to the current system time) get the date change.
Files that have been created during the wintertime (with no offset to the current system time) do not get the date change.
I wonder what it looks like in April - then the switch over to summertime has happened.
My current system is set to CET.
I checked it with 2 files: one with creation date 07.07.2015 19:04:21 (CEST)
the other one creation date 02.01.2015 07:07:42 (CET)
Saving the CEST file leads to a creation date of 07.07.2015 20:04:21
Saving the CET file leaves the creation date as it is.
Right now I think it is a bug in MP3tag when it tries to keep the original date attributes of the file - because then MP3tag has to "touch" the files again and overwrite the current file dates as set by the OS with the previously stored ones.
If on the other hand, you do not want to keep the modification data, MP3tag simply relies on the OS functions to update the dates, no further action by MP3tag is required.