[X] Sort by _FILE_MOD_DATE not always lists files in the exact correct order because it often messes up the time

I have observed this a long time ago on many occasion, but now I have the empirical data to back this up


If you have a Column set to

Value: _FILE_MOD_DATE
Field: _FILE_MOD_DATE
Sort by: _FILE_MOD_DATE

and load up these two files

Edit: removed file links

that were Modified [converted to FLAC from WAV] on the same day of 2018 03 28, they will not be listed in the correct order if you sort them out by this Column. This will be apparent when you add to Mp3tag also some other files, created at least a day before and a day after 2018 03 28

And so [at least for me] the order is

...
2018 03 29 XX:YY:ZZ
2018 03 28 23:05:10 [file "1"]
2018 03 28 23:23:56 [file "2"]
2018 03 27 XX:YY:ZZ
...

instead of being

...
2018 03 29 XX:YY:ZZ
2018 03 28 23:05:10 [file "2]
2018 03 28 23:23:56 [file "1"]
2018 03 27 XX:YY:ZZ
...

But this is not a simple bug [or merely a setting] where Mp3tag just lists the files in an ascending way by date and at the same time in a descending way by hour [or the other way around, depending on how many times you click the Column]- because other files I have created during that session [on 2018 03 28 near midnight] are listed correctly in Mp3tag

So to sum up: some files [like that example "1"] in spite being older by hours / minutes are listed as earlier ones than the actually early ones [like that example "2" and some others files that I have]; even if all of files loaded to Mp3tg are in the same folder and have the exact same tags [or are all wiped clean of any data]


But is it the fault of Mp3tag or of the software used for conversion [or to put it in other words: is it the fault of how the files are read or created]? I have no idea. But for example in FreeCommander XE 2018 Build 770 32-bit public and ACDSee 3.1, the sort order of these two files by Column described as Modified is correct. And this has been happening in precious versions of Mp3tag and most likely also with MP3 and WV file formats [but his time after stumbling upon by a mere accident on yet another manifestation of this issue, I took time to pint point and export examples and also tests them thoroughly]


And here is what is even more weird: this issues somewhat comes and goes. I just tempered with these files long enough and suddenly the right order was on- but then I started repeating the steps and there it was again [and by repeating the steps I mean loading the originals files and making copies of them named "1" and "2"]. Or it was only manifesting itself in one way but not in the opposite way; i.e. they order was messed up but after clicking the Column it got corrected- but then again after clicking the Column one more it was again messed up [and so on]. And also try this for yourselves: just copy the "1" and name it "A" and also copy "2" and name it "B" [and also later on you might copy the folder that has "1", "2", "A" and "B" to add more variations] and load them with some other files. Because the you might get something completely nonsensical like:

...
2018 03 29 XX:YY:ZZ
2018 03 28 23:23:56 [file "2"]
2018 03 28 23:05:10 [file "1"]
2018 03 28 XX:YY:ZZ
2018 03 28 23:05:10 [file "A"]
2018 03 28 23:23:56 [file "B"]
2018 03 27 XX:YY:ZZ
...

On just what basis does Mp3tag do that buggish behavior? The order in which the files are loaded to it? In that it takes notice of the date but disregards the dates to some extent, substituting the date with some weird rule based on names of files?

All of this is not merely annoying for me but simply counterproductive. Because sometimes I need [in search for potential errors] to go through files from the newest one to the oldest ones from a given period- but having the ability to stop my search at the first file that does not have the signs of error [assuming that to this point all of the others had it]. And so: if I have even one file not listed correctly among a hundred, then I need to go thorough all of 100 of them and not just by the first 10, assuming that the one without error happened to be the 11th- because how am I suppose to know that the 99th should not be the 9th?


Please temper with does two examples: rename them, add tags, re-load them and re-open the Mp3tag- and you will experience this chaos for yourself. Just remember to somehow mark them correctly as the newer one and the older one; and to double check the results by using the Properties option available in Mp3tag at the bottom of the right mouse button menu [when being in the main window with list of files]

instead of

use
Value: _FILE_MOD_DATE
Field: _FILE_MOD_DATE
Sort by: _file_mod_datetime_raw

Like that you should get the correct results.
see also:
http://help.mp3tag.de/options_export.html

Yes, I did; so thank you

But I can only assume, that this is the answer to the problem- and that this will not happen again. If it will and I somehow take notice of it, I will get back to report this



But on the side note:

I had to use lower case

%_file_mod_datetime_raw%

becuase with capitals

%_FILE_MOD_DATETIME_RAW%

the Column did not work- I clicked it and nothing ever happened. So it seems that this is another manifestation of this already semi-fixed bug:


\

So it is not a bug, just an example in difference between Unix Time and... time? [And that Unix Time thing is also why I keep stumbling upon that 1970 date when tempering with files creation date]

But if it not a bug, then why two files created with the same software [converter] within a span of less than an hour cannot be displayed in the correct order [with the %_file_mod_datetime% version]? It is not like between them "happened" thousands of leap seconds that coud somehow affect the saved time, right?

The Unix time is an integer that counts the seconds since 1st of January 1970. It is the exact time and date for a file and has not to be reformatted according to your local preferences.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.