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 this date 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, or just one/a few files shown with the import date in question (1/31/2025 2:35:02 pm)?

[slavad]

This is wierd. Cue and log files have imported date newer than imported date of the track.

[markf2748]

This is wierd. Cue and log files have imported date newer than imported date of the track.

I don't use Cue files and generally delete Log files after CDs are successfully ripped.  However I see similar weirdness for many other non-audio sidecar files (*.txt, *.pdf, *.lrc, *.xml, *.docx, *.7z, ...) when viewed in MC's "Drives & Devices > Explorer > Mode: All files > [x ]Show files in subfolders".   I selected my top level music folder in the Organization Tree, so as to list contents of all the album subfolders.  Then ordered the resulting list by Date Imported.  These sidecar files are typically many years old, yet MC shows them here as imported today.  Their Date Imported timestamps have a spread of less than 3 seconds.

I don't see this behavior for audio files, at least not usually, which suggests the weird sidecar import behavior is not necessarily related to the root cause of your unexpected audio file import. 

Again, I am curious about how many of your audio files are shown with the same recent import date, and how large is their spread in time.

Updated today for clarity.
Win11 Pro 64-bit | MC 33.0.63

[slavad]

Hi, there are not many files with updated imported date. For example:

[zybex]

What's Date improted?

[slavad]

Date imported is field in MC database. I suppose it have  contain date of importing track. But is was update recently somehow.

[zybex]

Yes, that's Date Imported. But your screenshot is showing a "Date improted" field. Not the same.

[slavad]

This is because it is actually expression to round date-time to date only - formatdate([date imported,0], %Y-%m-%d)

[zybex]

OK, that's fine. Is that the full expression? Can you check if the actual [Date Imported] matches that [Date improted] for the files that have wrong date?

[markf2748]

Why is the Date Imported for Mark Knopfler all over the map?

Reply #    Date of Screenshot     Date Imported
    1             1/31/2025                 1/31/2025
  12             2/3/2025                  10/11/2024
  14             2/6/2025                  12/29/2024

Are these different albums and tracks?  Do they all refer to audio files, and not sidecars?

For troubleshooting, there may be a clue in the full date stamp which includes times with 1 second resolution for every track.  For a given album, how much do the Date Imported times vary between tracks?  In my experience, there is no variation for Date Imported between tracks, while Date Created reflects the CD rip time per track.

Could your "Date Improted" actually be the last time the album was played or otherwise accessed?  Those dates are sequential, roughly a day apart for top 6 listings in Reply #14.

[slavad]

OK, that's fine. Is that the full expression? Can you check if the actual [Date Imported] matches that [Date improted] for the files that have wrong date?

Yes it matches, expression is straitforward.

[slavad]

Why is the Date Imported for Mark Knopfler all over the map?

Reply #    Date of Screenshot     Date Imported
    1             1/31/2025                 1/31/2025
  12             2/3/2025                  10/11/2024
  14             2/6/2025                  12/29/2024

Are these different albums and tracks?  Do they all refer to audio files, and not sidecars?

For troubleshooting, there may be a clue in the full date stamp which includes times with 1 second resolution for every track.  For a given album, how much do the Date Imported times vary between tracks?  In my experience, there is no variation for Date Imported between tracks, while Date Created reflects the CD rip time per track.

Could your "Date Improted" actually be the last time the album was played or otherwise accessed?  Those dates are sequential, roughly a day apart for top 6 listings in Reply #14.

The first and second tracs are different. About third track I dont know what is it.

[slavad]

The main question is: why date imported was changed by MC whereas date modified was not changed by OS? How does MC decide to re-import file? What other information except date modified can be?

[markf2748]

The main question is: why date imported was changed by MC whereas date modified was not changed by OS? How does MC decide to re-import file? What other information except date modified can be?

I agree that is your fundamental question.  For Auto-Import, presumably MC monitors File System Events received in notifications from the operating system, per:
https://wiki.jriver.com/index.php/Auto-Import
The complete list of events which MC reacts to is not clear to me, in particular which events can trigger an import when the file itself predates the import date by a long time and presumably has not changed recently.  Could it be a change in directory/path event?  In which case I would expect all audio files in the folder to be imported within at most a few seconds of each other while the files themselves could retain their old Date Modified. 

Short of a definitive answer from JRiver, you might look at your operating system's Event Monitor if you have the date/time of the import.  For Windows, search on Event Viewer (warning - this can be tedious  ).  If the behavior is reproducible, then also consider starting a new MC log file, try to capture the import, stop the log, and wade through the log file looking for a  hint.

One other farfetched thought - do the questionable import dates correspond to MC starting up after a relatively long shutdown, in which case it is "catching up" on an old event trigger?

2/8/2025 - Add MC log file suggestion. Edit for clarity.