Print

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

[slavad]

 For already imported tracks date imported is updated unexpectedly. What whould cause this?
For example this track was imported in 2024 but date imported was updated today.

[markf2748]

One possible explanation is that at least one of your fields was updated and written to the file as a new tag value.  That causes the operating system file date to change and MC may then re-import it if the folder is being watched.  In your screenshot, "Date Modified" looks like MC library data.  Does it agree with current operating system date for this file?  However, it's also interesting that your "Date Tagged" field is empty.  Has this version of the file ever been seen and tagged by MC before?  Which tags does it contain (look at Action Window > Tags > Tag Dump)?

You can see a list of all fields that could possibly be written to the file with: Tools > Options > Manage Library Fields > Library & Folders > Show only fields saved in tags.  You can uncheck the box "Save in file tags (when possible)" for any of these fields you are actually using, which in principle should avoid the tag update file issue in the future.

If you have copies of both the original file (say from a backup drive) and the recently imported file, then a binary file compare is a great way to look into the files and see exactly what has changed.  For example, the program Beyond Compare (BC) does an excellent job of this, at least for flac files.  It clearly identifies the tags at the top of the files and shows them side-by-side in human-readable text separately from the binary music data which follows.  I have never seen changes in the music data - it is always the fields which change.  Sometimes their values are the same but they have been re-ordered.  This will also be evident.

Have you selected Tools > Options > General > Importing & Tagging > [ ] Automatically import files when played, and then played the file from a different source?

Another challenging issue is when the Windows file "Date modified" mysteriously changes and BC shows the old and new files are binary identical!  This wrecks havoc with file synchronization/backups based on file dates.   I see this occasionally (maybe 1-2 times a month), always for whole music albums (all tracks updated to the same new "Date modified" timestamp, while sidecar files and folder dates are unchanged), multiple albums at a time, and often the same albums.  I'm in the process of tracking this behavior more carefully and will open a separate post when I have more definitive information (unless anyone can explain the puzzler now!).


Correction:  I do not mean to imply that simply updating tags always results in changing the import date.  Normally that should not happen.

[mwillems]

There's also another potential explanation.  If the file is on a remote or networked drive and JRiver loses the connection to that drive, sometimes the files are removed by auto-import's fix broken links function.  But then when the connection is restored they are then automatically reimported, but with a new date imported. 

If that sounds like your situation, the way to fix the issue is usually to turn "Fix broken links" to the "protect missing drives" option in the auto-import settings.  If you're already using that setting, try setting fix broken links to "off" and see if it stops happening as a test.

[marko]

There's also another potential explanation.  If the file is on a remote or networked drive and JRiver loses the connection to that drive, sometimes the files are removed by auto-import's fix broken links function.  But then when the connection is restored they are then automatically reimported, but with a new date imported. 

If that sounds like your situation, the way to fix the issue is usually to turn "Fix broken links" to the "protect missing drives" option in the auto-import settings.  If you're already using that setting, try setting fix broken links to "off" and see if it stops happening as a test.

My money's on this one. As well as remote or networked, if 'fix broken links' is set to 'yes', if files are in the library that are on a removable drive that is removed, then reconnected whilst MC is running, then the files are gonna be removed and reimported. Also, if the drive letter for that removable device hasn't been set so as to always be the same when reconnected, more chaos will ensue

-marko

[markf2748]

Whatever the root cause turns out to be here, anyone seriously interested in preserving the original acquisition date should be using a custom field to do so.  A new custom field can be easily mass initialized from current data, and then manually maintained for new entries going forward to avoid vagaries of MC and the operating system.  Yes, a price to pay in terms of maintenance, and all files will be updated if the new field is written as a tag.  But this problem has been brought up many times in the past, and I am not aware of any other equally or more robust solution entirely within MC.

[marko]

Personally, my library is over twenty years old and I've never had any problems with date imported. My broken links setting has always been protect missing drives.

Difficult to find a fits all solution with so many different setups, workflows and use cases out there.

[markf2748]

Personally, my library is over twenty years old and I've never had any problems with date imported. My broken links setting has always been protect missing drives.

Difficult to find a fits all solution with so many different setups, workflows and use cases out there.

@marko - Interesting, thanks for the info.  Today I created a smartlist to check MC's Date Imported field against my custom Date Acquired field.  It found thousands of files in which Date Imported is more recent than Date Acquired.  In those cases, most of the more recent Date Imported values cluster around just a few specific dates, suggesting there were times and events in the past when I did not use the setting  "Tools > Import > Fix Broken Links: Yes (protect files on missing drives)", or MC otherwise hiccuped.  That could have resulted in a silent, massive loss of accurate data wrt to what I mostly care about, namely the historically original import date.  It was precisely for protection against those kinds of "accidents" (which I experienced more than once) that I added this custom field several years ago.  I've now changed the Import setting as you suggest, and will run the smartlist again from time to time, but for peace of mind I'll keep using my custom field (actually, two fields, a string input and a calculated raw sortable expression field based on the string). 

[slavad]

There's also another potential explanation.  If the file is on a remote or networked drive and JRiver loses the connection to that drive, sometimes the files are removed by auto-import's fix broken links function.  But then when the connection is restored they are then automatically reimported, but with a new date imported. 

If that sounds like your situation, the way to fix the issue is usually to turn "Fix broken links" to the "protect missing drives" option in the auto-import settings.  If you're already using that setting, try setting fix broken links to "off" and see if it stops happening as a test.

Thank you for answer. Files are on local drive and looks like was not changed recently.

[markf2748]

Thank you for answer. Files are on local drive and looks like was not changed recently.

What exactly do you mean by "local drive"?  For example, is it a local USB drive connected by cable to the computer?  If such a drive is disconnected and reconnected, or becomes unavailable for some other reason (powered off?), its operating system file dates would remain unchanged.  But meanwhile if MC was running it could have marked the files as unavailable, then re-imported them with a new import date when the drive became available again (depending on the Import setting).  I think that is the point of the posts by @mcwillems and @marko.

[slavad]

Files are on the usual SATA hard drive. Drive was never disconnected.

[zybex]

Anything you may have done, like renaming/moving folders or restoring an old backup?

[markf2748]

Files are on the usual SATA hard drive. Drive was never disconnected.

Another test:
In a MC Standard View file list that includes all files in the library on that drive, add a column "Date Imported" (by RMB click on an existing header and selecting), then click on the column header once or twice to order the list by Date Imported.

Are all files, a big subgroup, a or just a few files shown with the import date in question (1/31/2025 2:35:02 pm)?