Print

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

[Bannion]

Hi!

Can I keep the same date and time of the file if I modify the tags? How?

Thanks.

[jkauff]

If you've made changes that alter the file itself, the operating system will record the date and time when you saved the file.

Are you using Sidecar files? If you don't mind the disc clutter, I think you can choose to store the tags in a Sidecar file instead of in the file itself. Another option is to use a 3rd party utility that can change the operating system date/time stamp itself.

[Bannion]

I don't want to use sidecar files.
And I don't want to change the date/time stamp of the operating system either. Mp3tag and TagScanner, respect that stamp without altering it.

I'm just wondering if JRiver can be configured to do the same.

Thank you, jkauff.

[zybex]

If you only use MC you can disable tag writing completely - tags will only be kept in MC database, which you can backup. Otherwise no, any writing to the file will update the modified timestamp.

You can ask for a new feature to "preserve timestamps on tag update", but keep in mind that this is usually a bad idea as it hides files changes. If you backup your music files the timestamp is used to determine which files were changed, so you may end up with empty differential backups (unless the backup software uses the old A-attribute method).

[Bannion]

If you only use MC you can disable tag writing completely - tags will only be kept in MC database, which you can backup.

I want to modify the tags, but not the timestamp.

Otherwise no, any writing to the file will update the modified timestamp.

Mp3tag and TagScanner don't modify the timestamp and that's what I'm looking for in MC.

You can ask for a new feature to "preserve timestamps on tag update",...

How do I request that?

Regards.

[zybex]

How do I request that?

You just did, I guess. Dear JRiver team: ☝️

[Bannion]

: Why are there so many crazy answers to simple questions?

Simple question: Can you implement in MC that modifying labels (MP3, FLAC, etc.) does not also modify the day/time stamp, such as Christmas Gift...?

Best regards from Spain.

[Bannion]

You just did, I guess. Dear JRiver team: ☝️

Let's see what Santa says now...

Regards.

[JimH]

I want to modify the tags, but not the timestamp.[/b]
Mp3tag and TagScanner don't modify the timestamp and that's what I'm looking for in MC

That seems wrong since the file has been modified.  Why would you want that?  Backup?

[Awesome Donkey]

Uhhh, do you mean the file's metadata and the timestamp displayed by the system? If so, I'm not sure how you could pull this off, because you're modifying the file's metadata which is modifying the file itself when writing the metadata changes (which are stored within the file and are a part of the file) which in turn changes the timestamp.

The only potential ways around that, at least what comes to mind, is limiting any changes to the library and not allow MC to write tags or perhaps force the use of sidecars, but that seems like a waste and I'm not even sure if sidecars are used for files like FLAC.

I think you're going to have to elaborate on this one a little more.

[Bannion]

That seems wrong since the file has been modified.  Why would you want that?  Backup?

Because the modifications are simple (accents, cover art, wrong edition years...), and because finally, I always have to use Mp3tag or TagScanner that allow to keep date and time (if it's the will of the one who manages them).
I would find it useful to do that with MC.

I've been looking for that possibility in MC settings for a long time without finding it. For me, it is very important.

Regards.

[Awesome Donkey]

Yeah, makes no sense at all to me. I don't see how you can make any changes to the metadata in the file unless those apps are writing the changes in another location like an external file (sidecar). They shouldn't be able to bypass the OS timestamp when writing changes as the metadata is part of the file and if you write changes to the file, it should absolutely change the timestamp.

If those other apps are somehow doing this, I think that's the wrong behavior and I also think it's a bad idea to do something like this, IMO.

It should change the timestamp when you write changes to the file.

[Bannion]

Yeah, makes no sense at all to me. I don't see how you can make any changes to the metadata in the file unless those apps are writing the changes in another location like an external file (sidecar). They shouldn't be able to bypass the OS timestamp when writing changes as the metadata is part of the file and if you write changes to the file, it should absolutely change the timestamp.

If those other apps are somehow doing this, I think that's the wrong behavior and I also think it's a bad idea to do something like this, IMO.

It should change the timestamp when you write changes to the file.

Often, some things only make sense to those who find them useful.
Regards.

[Awesome Donkey]

Fair enough, but I don't agree with this idea, seems wrong to me and I certainly don't want MC doing this with the files in my music library. Allowing something like this would throw off the Beyond Compare app I use to sync changes between my main library, NAS library and my backup libraries.

If it's considered hopefully it's disabled by default.

[Bannion]

Fair enough, but I don't agree with this idea, seems wrong to me and I certainly don't want MC doing this with the files in my music library. Allowing something like this would throw off the Beyond Compare app I use to sync changes between my main library, NAS library and my backup libraries.

If it's considered hopefully it's disabled by default.

Then we will agree to disagree.
Regards.

[Bannion]

Uhhh, do you mean the file's metadata and the timestamp displayed by the system? If so, I'm not sure how you could pull this off, because you're modifying the file's metadata which is modifying the file itself when writing the metadata changes (which are stored within the file and are a part of the file) which in turn changes the timestamp.

The only potential ways around that, at least what comes to mind, is limiting any changes to the library and not allow MC to write tags or perhaps force the use of sidecars, but that seems like a waste and I'm not even sure if sidecars are used for files like FLAC.

I think you're going to have to elaborate on this one a little more.

Yes, we can.
As I keep repeating, so far I'm modifying that metadata with Mp3tag or TagScan; and MC or Windows, they haven't broken.

But I would like to be able to do it without leaving MC.
Regards.

[MusicBringer]

I am confused.
When I change a Tag in MC the file stamp in MS file manager is unchanged and remains the same as it was.
Using Win10 MC 30.

I have just changed a Tag - for example removed Album artist - while watching File Explorer [Date Modified]  Nothing moved. Nothing changed.
Cannot find it now but I am sure there is a setting in Options.

[JimH]

I agree with Awesome Donkey.  You're asking for a change that we won't make.

[Bannion]

I am confused.
When I change a Tag in MC the file stamp in MS file manager is unchanged and remains the same as it was.
Using Win10 MC 30.

I have just changed a Tag - for example removed Album artist - while watching File Explorer [Date Modified]  Nothing moved. Nothing changed.
Cannot find it now but I am sure there is a setting in Options.

I have MC version 29.0.55 installed and no matter how hard I looked in the configuration I couldn't find it.
But thank you for telling me that (apparently) there is a setting to respect the date and time stamp.
I'm just waiting for you to show me the route to get to it.

Regards.

[zybex]

Awesome Donkey - it's technically very simple:

1. read current timestamps (Stat)
2. open file
3. write changes/tags
4. close file
5. set FileModified timestamp to the value read in 1

So you just add steps 1 and 5 to your current code.

As to why people would want that... as I said above it's usually not useful, but some people do want to sort by date on the filesystem as a way to see the more recent files, for instance.
An option for this should of course be disabled by default, but it's trivial to add.

[Bannion]

I agree with Awesome Donkey.  You're asking for a change that we won't make.

I guess in your statement is the answer to my question: MC doesn't do what Mp3tag and TagScanner do. So I'll stop looking.
Thanks anyway; to you and the rest of the forum members.

Greetings.

[MusicBringer]

Sorry Not the Options setting but there is this under Library Tools

[zybex]

MusicBringer: you probably have the "update tags when file info changes" option disabled, so no tags are written to your files (as I mentioned above). OR you're using Sidecars. OR you have file formats not supporting tagging.

[Bannion]

...but some people do want to sort by date on the filesystem as a way to see the more recent files, for instance.

That's one of my most important reasons.

An option for this should of course be disabled by default.

Of course! The option should be disabled by default. 
My sincere thanks, zybex.

Best Regards.

[MusicBringer]

Hello zybex,
We have met before with your always helpful comments.
You are right first time.
"you probably have the "update tags when file info changes" option disabled"
Yes its disabled.

Because it says: update tags when file info changes.

I do not want MS "file info" to touch and update my MC Tags.

Still confused.

[Bannion]

Sorry Not the Options setting but there is this under Library Tools

I've got that taken care of.
Update tags from library, modifies date and time.
Update library from tags, does not modify the file.

Thanks.

[zybex]

Still confused.

When you change anything in MC for a given file, the info (tags) can be saved in 3 places:
1. in MC database ("Library") (always saved)
2. in the media file itself as an ID3 tag embedded in the file (this is what that option disables)
3. As a Sidecar.xml file saved next to the original file (this is to prevent modifying the file itself, and also to support file types that do not support internal tagging)

If you use other applications besides MC, you need 2 enabled because they will then see the same changes as you do in MC, and MC will also see changes you do in them.
Options 1 or 3 are only understood by MC, so changes will not be visible elsewhere. This is fine if you only use MC.

"Update tags (from Library)" will copy the information from 1. to 2 (updating the files)
"Update Library (from Tags)" will copy the information from 2. to 1 (updating the database/library)

With 2. disabled, nothing is ever written to the media file so the timestamp does not change.
Note that simply playing a file causes the [Number Plays] to change - if writing is enabled for that field, then the file timestamp will change each time a file is played.

[MusicBringer]

Dear zybex,
you have such a gift in writing clear and concise.
Understood every word
No longer confused, thanks to you 🙂

[markf2748]

As to why people would want that ... some people do want to sort by date on the filesystem as a way to see the more recent files, for instance.

Yes, sorting by "age" of the file can be quite valuable.  But I try not to depend on the operating system for age information (been burned too many times in multiple ways).

Perhaps this helps the OP:  For sorting within MC, add two custom fields, for example [Date Acquired] and [Date Acquired (raw sortable)], the latter automatically calculated from the former with =ConvertDate([Date Acquired]).  Fill in [Date Acquired] once, and forever-after you can do reliable age sorts within MC using the calculated field, even when other file tags change.  Also, if ever desired, one can easily alter the effective "sort age" of the file intentionally.  Note that for your current library, [Date Acquired] can be bulk initialized in the Tree to any of the human-readable date fields [Date ...] available within MC by using the "=[Date ...]" syntax.

[HPBEME]

Can't you simply use the Date Created library field/tag? That field/tag never changes regardless of whatever else is modified (unless you manually/intentionally modify the tag in MC).  No need for any tricks, custom fields, or extra work.

[markf2748]

Can't you simply use the Date Created library field/tag? That field/tag never changes regardless of whatever else is modified (unless you manually/intentionally modify the tag in MC).  No need for any tricks, custom fields, or extra work.

MC's [Date Created] is non-relational, i.e. it stores one value per audio track, and is totally out of my control AFAIK.
I define [Date Acquired] to be "Relational:  Store one value for each album" and is totally within my control.  Then I typically use the automatically populated [Date Acquired (raw sortable)] for album view sorts, like "Recently Acquired".  The only real overhead is remembering to set [Date Acquired] once per album.

The limitation (and it is a bad one) is when two different albums have the same name there is a tag interaction issue.  I believe this problem currently plagues all album relational fields in MC and is long in need of a general solution.  However you might get away with not making the custom fields album relational, in which case just select the album (or more tediously select all of the album's tracks explicitly) to put same tag value into all tracks.

Off-topic FYI:  In a more sophisticated application, I use this pair of fields in both my Audio and Image Data bases, the latter applied to covers and album art.  So if I have images assigned to the same album name as the audio tracks, then setting [Date Acquired] in the Audio database automatically populates it in the Image database.  Therefore I can display synchronized "Recently Acquired" sorts between views of Albums and Album Artwork.  That was my original motivation for setting up this scheme.  It works very nicely, again as long as two different albums don't have the same name.  I've raised this interaction issue for other album relational fields in another post,
 https://yabb.jriver.com/interact/index.php/topic,134481.msg931475.html#msg931475

[HPBEME]

It is not totally out of your control - you can manually change the Date Created if that is your desire.  Regardless, I take your point, and your approach clearly works for your purposes.
Update: I swear I have changed the Date Created field/tag in the past, but just to check after I so confidently posted the above... turns out I am not able to modify it.  Either way, the OP should still be able to sort on the date created field, since it does not update when other tags are modified.

That said, the OP was asking for the date to not to change on a per file basis, not per album:

Can I keep the same date and time of the file if I modify the tags?

[markf2748]

That said, the OP was asking for the date to not to change on a per file basis, not per album:

I strongly suspect that MC's per file [Date Created] field depends on the OS for its information.  In Windows, if you do a simple file copy between folders, then Date Created on the copy is by default the time you did the copy, not the "original" file creation date.  So for example, if you copy files from a backup, those copied files lose the original Date Created information.  I'd be concerned that the loss of original information likely gets carried over into MC.  There are ways around vagaries of the OS, using Beyond Compare, dedicated file copy apps (robocopy), etc. to preserve time stamps but you need to be careful.  That is another reason why I prefer storing album acquisition dates in a custom field with manual maintenance.  I think what I describe is more robust and useful in an archival sense than what the OP, strictly speaking, originally asked for.