MC 3.168: "Date Added" button shows modification order

Hi,

The "Modified" versus "Date Added" buttons don't appear to work correctly, as far as I can see the order is identical (and last modified).

Bye,
Dennis

Yes your running XP?

The behaviour of Xp & Vista are different in terms of when a document is edited & resaved "over the top".

XP thinks its new so the creation date is updated, Vista leaves it as it was.


I brought this up earlier with Billy when it was first implemented since it didn't work on XP as intended. MC is designed on Vista BTW.

I think the only way around this is to store the date created in the nfo. i.e. when it was created!

Cheers

StormyKnight wrote:

Yes your running XP?

The behaviour of Xp & Vista are different in terms of when a document is edited & resaved "over the top".

XP thinks its new so the creation date is updated, Vista leaves it as it was.


I brought this up earlier with Billy when it was first implemented since it didn't work on XP as intended. MC is designed on Vista BTW.

I think the only way around this is to store the date created in the nfo. i.e. when it was created!

Cheers

I am actually on 64 bit vista and the file properties are correct (at least for the one incorrectly sorted movie I checked), for example all files (including the NFO and movie) have 2008 created timestamps and the NFO has a recent "date modified" timestamp. So if Billy is indeed using timestamps its a MC bug not an OS one..

Bye,
Dennis

I am actually using Windows 7 (x64) to develop MC, although it is compiled for x86 machines.

nfo's now store the creation date within the nfo file, without this information MC uses the modified date, which has the disadvantage of pushing an edited file above new files. Once a movie has been edited then the current date is written to the nfo file.

There is no way for MC to know the actual creation date of nfo files that already exist, all I can suggest is that you use the option "Rebuild Movie nfo Files" it's the last item in the Movie menu. This rebuilds and saves each nfo file, adding the modified date as the creation date. The date will be permanent from then on, and any additional movies added should sort properly.

Thanks Billy, I wasn't aware that <createdate> was added. Also thanks for the workaround to get the nfo's current.

Cheers.

billyad2000 wrote:

There is no way for MC to know the actual creation date of nfo files that already exist,

.Net can't access a files creation time?

billyad2000 wrote:

All I can suggest is that you use the option "Rebuild Movie nfo Files" it's the last item in the Movie menu. This rebuilds and saves each nfo file, adding the modified date as the creation date. The date will be permanent from then on, and any additional movies added should sort properly.

Ok sounds good unless this will generate a lot of internet traffic etc. Does it just load and resave the data?

dbareis wrote:

.Net can't access a files creation time?

Yes, but if you are running on XP, the creation time is changed believe it or not Using the same code as on Vista or Win7 it does not...

So to be compatible with XP, this method was devised.....

dbareis wrote:

Ok sounds good unless this will generate a lot of internet traffic etc. Does it just load and resave the data?

For me it was very quick, 330 movies about 30 seconds, it must do that.

After the rebuild, & changing some data my lists are now different

dbareis wrote:

billyad2000 wrote:

There is no way for MC to know the actual creation date of nfo files that already exist,

.Net can't access a files creation time?

billyad2000 wrote:

All I can suggest is that you use the option "Rebuild Movie nfo Files" it's the last item in the Movie menu. This rebuilds and saves each nfo file, adding the modified date as the creation date. The date will be permanent from then on, and any additional movies added should sort properly.

Ok sounds good unless this will generate a lot of internet traffic etc. Does it just load and resave the data?

.Net can access the files creation time, but when the nfo is altered it overwrites the old nfo and the origional creation time is lost.

The rebuilding of movie nfo files generates zero web traffic, all that is done is that each nfo is loaded, and resaved to current specs, i.e missing data such as the creation date will be added, empty media info tags removed etc, the nfo data itself will remain unchanged.

billyad2000 wrote:

.Net can access the files creation time, but when the nfo is altered it overwrites the old nfo and the origional creation time is lost.

In my case the creation time is CORRECT...

If the code's logic is to recreate (not rewrite) the file then the OS is doing the correct thing by changing the "creation date" because its a new file, but in any case the creation date is not lost so this appears to be a simple MC bug (you are probably not reading the creation date but the modification time).

I just changed a movie .NFO last changed in 2008 and tried both clicking the "watched" button and clicking the "quicksave" button, neither caused the "created date" to be lost.
This is the before state:



This is the after (with the correct/original creation date):

billyad2000 wrote:

The rebuilding of movie nfo files generates zero web traffic, all that is done is that each nfo is loaded, and resaved to current specs, i.e missing data such as the creation date will be added, empty media info tags removed etc, the nfo data itself will remain unchanged.

I will do this if I have to, but I'll hope for a MC fix first.

Thanks,
Dennis

StormyKnight wrote:

Yes, but if you are running on XP, the creation time is changed believe it or not Using the same code as on Vista or Win7 it does not...

So to be compatible with XP, this method was devised.....

This problem didn't occur on my (previous) WINXP but I do remember the discussion.

The "work around" to me does'n't make sence, current situation:

* Use tag in NFO
* Fall back to modification time if no tag

So basically it fails for everyone until tag created, whereas this has the advantage of working on all modern OSes (with and without the tag):


* Use tag in NFO
* Fall back to creation time if no tag

If you are correct (on WINXP issue) it ALWAYS works on Vista onwards, if I am correct it works everywhere.

Bye,
Dennis

dbareis wrote:

StormyKnight wrote:

Yes, but if you are running on XP, the creation time is changed believe it or not Using the same code as on Vista or Win7 it does not...

So to be compatible with XP, this method was devised.....

This problem didn't occur on my (previous) WINXP but I do remember the discussion.

The "work around" to me does'n't make sence, current situation:

* Use tag in NFO
* Fall back to modification time if no tag

So basically it fails for everyone until tag created, whereas this has the advantage of working on all modern OSes (with and without the tag):


* Use tag in NFO
* Fall back to creation time if no tag

If you are correct (on WINXP issue) it ALWAYS works on Vista onwards, if I am correct it works everywhere.

Bye,
Dennis

For simplicity I would much prefer to use your suggestion.
In my case, where the majority of stuff is located on a NAS, the issue remains. On changing the data, be it changing the watched status, or saving edits, the creation date changes. It seems likely that the Server sees the command to overwrite as a batch to delete then create a new file.

It may be the case that I need to re-examine my methods, only overwriting a file if it does not exist. It would be fairly simple to open a file and write to it anything I want without appending, this would avoid the issue.

Got my hands a bit full at the moment, but I will experiment a little over the next week or two.

billyad2000 wrote:

For simplicity I would much prefer to use your suggestion.
In my case, where the majority of stuff is located on a NAS, the issue remains. On changing the data, be it changing the watched status, or saving edits, the creation date changes. It seems likely that the Server sees the command to overwrite as a batch to delete then create a new file.

It may be the case that I need to re-examine my methods, only overwriting a file if it does not exist. It would be fairly simple to open a file and write to it anything I want without appending, this would avoid the issue.

Got my hands a bit full at the moment, but I will experiment a little over the next week or two.

No hurry, you should be able to "reset" timestamps after the fact as well (the OS is certainly capable of doing it hence "touch.exe" type utils etc). Your NAS issue could perhaps be a feature with that brand (my drives are currently usb attached although I did start out with a nas).

OK - I don't think this is going to happen,

My NAS uses the ext3 file system, and I dont think it supports both modified and creation date, only the last modified date.

No matter how I try it, the only date returned to windows is the modified date - the creation date is always identical.
I've tested this a number of ways, the easiest way is obviously to create a text file and save it, as you would expect the last modified and creation date are the same. Now if I open the file and save then close, the modified date changes, and so does the creation date.

I have tried every way I can think of to get a different result without success.

I also checked the specs on Wikipedia that appeared to back this up.
NTFS:
Dates recorded. Creation, modification, POSIX change, access
Ext3:
Dates recorded. modification (mtime), attribute modification (ctime), access (atime)

Looks like the creation date is a feature only for NTFS filesystems, and ext4, but ext4 is not widely used.

Hi,

billyad2000 wrote:

OK - I don't think this is going to happen,

My NAS uses the ext3 file system, and I dont think it supports both modified and creation date, only the last modified date.

No matter how I try it, the only date returned to windows is the modified date - the creation date is always identical.
I've tested this a number of ways, the easiest way is obviously to create a text file and save it, as you would expect the last modified and creation date are the same. Now if I open the file and save then close, the modified date changes, and so does the creation date.

Looks like the creation date is a feature only for NTFS filesystems, and ext4, but ext4 is not widely used.

Maybe I'm missing something, but if you are saying that the creation date can be returned for all filesystems but on some it will be the same as the modification date, then what is the problem? You have improved the situation for those filesystems that support it while not making it any worse otherwise?

Maybe I'll just perform the rebuild, but I'm assuming that will lose the current info, or will the current creation date info be retained?