Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mecedo]

Can you implement option "don't modify file time stamp" after altering tags in media files? Some people (like me) want to have original dates when files was created\obtained

[EnglishTiger]

MC has a Date Created and Date Imported tags/fields neither of which MC modifies/changes

[AndreaT]

Hi mecedo, the solution is here: https://yabb.jriver.com/interact/index.php/topic,132246.msg916640.html#msg916640
By default setup MC changes date and data of played audio files.
Regards, Andrea

[jctcom]

I don't think it's actually possible to make any changes to imbedded tags without making a change to the file which prompts Windows to change the last modified time.

I think the only option is to set MC not to write any changes at all to the file tags.  Which could be a real bummer if your MC Database went kaput for some reason?

Carl.

[markf2748]

I think the only option is to set MC not to write any changes at all to the file tags.  Which could be a real bummer if your MC Database went kaput for some reason?

I just posted a flexible solution using custom fields that works for me:
https://yabb.jriver.com/interact/index.php/topic,132246.msg922408.html#msg922408   (Reply #3).

[jctcom]

I just posted a flexible solution using custom fields that works for me:
https://yabb.jriver.com/interact/index.php/topic,132246.msg922408.html#msg922408   (Reply #3).

I did read that.  But the fact is anytime you edit any tag within the file the time stamp is going to change for that file.

Edit:  Sorry I must have been reading something else and combined it with this.  For some reason I thought the Op was attempting to stop something from syncing because it saw the changed time stamp on the file?
My mistake.

Carl.

[zybex]

The file modification date serves another purpose - it tells the backup/sync tools that the file was changed since the last backup and thus needs to be backed up again. So keeping the modified timestamp when the file is changed (when writing new tags) is usually not desired.

Many backup tools can also rely on the A attribute for this, but most nowadays just check the modified date.

[mecedo]

Thanks but all examples you gave me are poor and inconvenient. Many audio tagging tools has "don't modify time-stamps" option and it's very handful. Is it hard to implement it in MC?

PS. I don't bother about backup tools.

[EnglishTiger]

Can you implement option "don't modify file time stamp" after altering tags in media files? Some people (like me) want to have original dates when files was created\obtained

The Date Created Tag/Field, which is the Date & Time a file is Added (original date  when the file was created/obtained) to your PC, is set by the Operating System and NEVER MODIFIED by MC

[mecedo]

But it's possible to remember "Date Created Tag", make some modifications to file and restore remembered "Date Created Tag" after that. That's a way another software is doing it.

[zybex]

It's possible and even easy to do, but it's wrong.

Date Created is the original file date. This is what you want and can be displayed both in MC and in Windows Explorer. It's there, why not use it?

Date Modified, as the name implies, is supposed to be updated whenever the file contents are modified. When MC changes the file to update the tags it correctly updates this timestamp; keeping it unchanged is wrong as it implies the file is still in its original state. If you don't want MC to change the file there's an option for that, but if the file *is* changed... then the modified date should change.

Other apps do it, yes, and they're doing it wrong.

[mecedo]

I appreciate it in other applications very much. Even if it's wrong. You can switch it on or off. If I like it then I can turn this option on. If you think it's wrong then you can switch it off. You are happy and I'm happy. I'm I true?

[zybex]

Yep, an option is fine if MC team wants to do it.
As a workaround, it's easy to have a script running that just sets modifiedDate=creationDate on all files of a given folder.

[markf2748]

The Date Created Tag/Field, which is the Date & Time a file is Added (original date  when the file was created/obtained) to your PC, is set by the Operating System and NEVER MODIFIED by MC

Date Created is the original file date. This is what you want and can be displayed both in MC and in Windows Explorer. It's there, why not use it?

Both of the above are true, except they are NOT what I personally want in a date acquired field, because they are subject to change by the operating system.  For example, if I copy an old audio file to a new directory or different disk, then Window's Date Created is changed to current date and time, which is dutifully reported by MC's internal [Date Created] field.  There are file copy utilities which can preserve the original OS Date Created, but that is certainly not the Windows default behavior.  If I re-rip a CD, same thing happens, [Date Created] contains the re-rip timestamp, not the original date created.

So I implemented a simple custom field (linked in Post #4 above, and similar to other suggestions in the past) to meet my requirements, i.e. it preserves my manually-entered original "historic" date when I first acquired the album, in the most bullet-proof manner I know of. 

Yep, an option is fine if MC team wants to do it.

I oppose the added confusion of any option to change the Date Created field behavior.  Granted the naming convention is subject to misinterpretation.  However for better or worse, the OS Date stuff it contains is fundamental and very useful as is, it's just not sufficient to meet all needs.

I suppose MC could introduce a special date acquired field which is auto-initialized to OS Date Created once only, purely for convenience, then only user-writable thereafter, but that's going a bit far afield

[Manfred]

Date Created is the original file date.

It's not absolutely true. If you must restore your files from a file backup to a new disk you must re-import the files into MC and date created is the import date and not the original Date Created?

[zybex]

I mean the filesystem Date Created (DC), not the MC field.
And yes, the original DC can also be lost by copying the files, and DC in Linux doesn't even mean the same as it does in windows... But it's usually pretty static compared to Date Modified.

Restoring from backup usually also restores the original timestamps, and you can also copy/move files while preserving the timestamps with appropriate tools.

[Manfred]

Restoring from backup usually also restores the original timestamps, and you can also copy/move files while preserving the timestamps with appropriate tools.

No - I had the case today  , that I must restore some of my files (MS Storage Space Problem). And the Dates in MC are not the same like before.

[zybex]

That really depends on a few factors:
1. the tool used for backup/restore must support timestamp backup/restore
2. the target OS must support it (Linux CTIME is actually not the same a Windows CTIME, and is harder to set. Many NAS are linux-based...)
3. the protocol must support it - restoring via network using older CIFS versions usually does not preserve CTIME

- Windows 10 preserves it when you do a Move, but not a Copy (makes sense).
- Archiving to 7z using a recent version of 7ZIP only preserves/restores CTIME with the -mtc=on option
- Archiving to ZIP using a recent version of 7ZIP automatically preserves/restores CTIME
- my QNAP (linux based) actually works fine with Windows and 7ZIP to preserve CTIMEs. Other NAS may be different.
- most backup tools use 7Z or ZIP formats for archiving; if they don't set the proper options, CTIME is not preserved
- With other tools and filesystems... it may work or not, it needs testing.

So... YMMV.