IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
> [F] Mp3tag 2.81 changes file creation date
TAVOR21
post Mar 16 2017, 05:39
Post #1


Member


Group: Full Members
Posts: 8
Joined: 16-March 17
Member No.: 23192
Mp3tag Version: 2.81



hey guys,

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 dry.gif .... so i had to test further because for me thats not an option.

This post has been edited by TAVOR21: Mar 16 2017, 05:47
Go to the top of the page
 
+Quote Post
ohrenkino
post Mar 16 2017, 07:03
Post #2


Member


Group: Full Members
Posts: 8517
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.82



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.


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post
Florian
post Mar 16 2017, 10:24
Post #3


Developer


Group: Admin
Posts: 7863
Joined: 12-December 01
From: Germany, Dresden
Member No.: 203
Mp3tag Version: 2.82



Hi Tavor,

can you tell me which file system is used for the partition which is storing those files?

Kind regards
– Florian


--------------------
♫ If you like using Mp3tag please donate to support further development.

Go to the top of the page
 
+Quote Post
TAVOR21
post Mar 16 2017, 10:49
Post #4


Member


Group: Full Members
Posts: 8
Joined: 16-March 17
Member No.: 23192
Mp3tag Version: 2.81



QUOTE (ohrenkino @ Mar 16 2017, 07:03) *
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.


but how come there were these 2 files that wouldnt change, no matter what? and i tried both, changing tags and "empty" saving. also, why +1 hour??


QUOTE (Florian @ Mar 16 2017, 10:24) *
Hi Tavor,

can you tell me which file system is used for the partition which is storing those files?

Kind regards
– Florian


ntfs on all of them. oh and using windows 7 pro.

grüße smile.gif
Go to the top of the page
 
+Quote Post
ohrenkino
post Mar 16 2017, 11:53
Post #5


Member


Group: Full Members
Posts: 8517
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.82



ZITAT(TAVOR21 @ Mar 16 2017, 10:49) *
but how come there were these 2 files that wouldnt change, no matter what? and i tried both, changing tags and "empty" saving. also, why +1 hour??




ntfs on all of them. oh and using windows 7 pro.

grüße smile.gif

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.

So, for me it is very hard to reproduce.

This post has been edited by ohrenkino: Mar 16 2017, 11:54


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post
TAVOR21
post Mar 16 2017, 15:28
Post #6


Member


Group: Full Members
Posts: 8
Joined: 16-March 17
Member No.: 23192
Mp3tag Version: 2.81



QUOTE (ohrenkino @ Mar 16 2017, 11:53) *
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.

So, for me it is very hard to reproduce.


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...
Go to the top of the page
 
+Quote Post
ohrenkino
post Mar 16 2017, 19:36
Post #7


Member


Group: Full Members
Posts: 8517
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.82



ZITAT(TAVOR21 @ Mar 16 2017, 15:28) *
...
i could provide you some example files, 1 where the problem occurs and 1 where it doesnt. ...

Yes please. If it is a file problem.


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post
TAVOR21
post Mar 16 2017, 19:49
Post #8


Member


Group: Full Members
Posts: 8
Joined: 16-March 17
Member No.: 23192
Mp3tag Version: 2.81



QUOTE (ohrenkino @ Mar 16 2017, 19:36) *
Yes please. If it is a file problem.


hmm well im not allowed to use the private messenger so ill just put the links here:

file that is affected by the bug > http://www102.zippyshare.com/v/BGktGZ9Z/file.html
file that is unaffected by the bug > http://www102.zippyshare.com/v/13O3XbPL/file.html

these are rar archives with options "store modification time" and "store creation time" set, so you should unpack them the same way in order to increase the likelyhood that you can reproduce the bug.
Go to the top of the page
 
+Quote Post
ohrenkino
post Mar 16 2017, 20:17
Post #9


Member


Group: Full Members
Posts: 8517
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.82



At a first glance:
the file "not-affected" has V2.4 tags - something that the Windows Explorer does not read
the file "affected" has V1 and V2.3 tags which the WE should read.

The File affected has a creation date of 22nd of July 2016 and a modification date of 20th of July 2016 (amazing that).

The file not-affected has a creation data of 23rd of February 2017 and modification date of 23rd of February 2017

I then cut&paste the tags in both files and then the files still showed the original creation date but a new modification date just a couple of minutes ago.


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post
TAVOR21
post Mar 16 2017, 20:40
Post #10


Member


Group: Full Members
Posts: 8
Joined: 16-March 17
Member No.: 23192
Mp3tag Version: 2.81



QUOTE (ohrenkino @ Mar 16 2017, 20:17) *
At a first glance:
the file "not-affected" has V2.4 tags - something that the Windows Explorer does not read
the file "affected" has V1 and V2.3 tags which the WE should read.

The File affected has a creation date of 22nd of July 2016 and a modification date of 20th of July 2016 (amazing that).

The file not-affected has a creation data of 23rd of February 2017 and modification date of 23rd of February 2017

I then cut&paste the tags in both files and then the files still showed the original creation date but a new modification date just a couple of minutes ago.


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.

This post has been edited by TAVOR21: Mar 16 2017, 20:50
Go to the top of the page
 
+Quote Post
ohrenkino
post Mar 16 2017, 20:47
Post #11


Member


Group: Full Members
Posts: 8517
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.82



ZITAT(TAVOR21 @ Mar 16 2017, 20:40) *
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.

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.

This post has been edited by ohrenkino: Mar 16 2017, 20:48


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post
TAVOR21
post Mar 16 2017, 20:52
Post #12


Member


Group: Full Members
Posts: 8
Joined: 16-March 17
Member No.: 23192
Mp3tag Version: 2.81



QUOTE (ohrenkino @ Mar 16 2017, 20:47) *
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.


are you looking at the day only? because it changes only 1 hour with each save! changing the day would take a couple of times
Go to the top of the page
 
+Quote Post
ohrenkino
post Mar 16 2017, 21:09
Post #13


Member


Group: Full Members
Posts: 8517
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.82



ZITAT(TAVOR21 @ Mar 16 2017, 20:52) *
are you looking at the day only? because it changes only 1 hour with each save! changing the day would take a couple of times

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.


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post
TAVOR21
post Mar 16 2017, 22:06
Post #14


Member


Group: Full Members
Posts: 8
Joined: 16-March 17
Member No.: 23192
Mp3tag Version: 2.81



QUOTE (ohrenkino @ Mar 16 2017, 21:09) *
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..rolleyes.gif mp3tag so far has always been 100% reliable.
Go to the top of the page
 
+Quote Post
ohrenkino
post Mar 16 2017, 22:19
Post #15


Member


Group: Full Members
Posts: 8517
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.82



In a way you see me absolutely puzzled.

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.


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th May 2017 - 22:43