Print

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

[gulp]

Can someone please tell me how I can achieve this?

So far when I move the files to another directory I use the "rename, move and copy files" function and do a search/replace of the path.
When I then run the "auto import" again, all the files are newly shown in the "recent albums" view, which destroys it each time, as I then have old but updated albums again listed as newly imported.

Is there a way around?

[RD James]

This implies that Media Center is re-importing the 'moved' files as though they were new, which shouldn't be happening.
Are you actually using the RMC tool to move the files in "rename" mode, or are you moving the files in explorer and "updating" their location?
I recently changed the file structure of my entire music library using RMC to rename the files and that didn't happen for me.

[lepa]

It shouldn't happen if you are using tool to move files and not copying. Picture about your settings would help to figure whats happening.

[gulp]

These are my settings...and I'm moving the files in explorer and updating their location.

Any trick to get newly added albums out of the "recent" view if all this happened?

[swiv3d]

Unfortunately Date imported can't be edited so you won't be able to repair your recent albums view. Whenever you are moving files, don't use explorer and then import - because you are basically telling MC that these are new files so it gives them a nice new import date. You should do what RD James suggested and use the move function, then MC knows that it is just moving files and not re-importing them. Sorry to be the bearer of bad news, of course I might be wrong, I often am.

[RoderickGI]

To expand a little bit on above, what happened was (assuming Auto Import was on, because that is the only way it would happen):

1. You moved the files in Windows Explorer
2. Auto Import in MC found the moved files, because it detected file system activity, and imported them again. This can happen very quickly on a local hard drive. On a NAS I would expect it to take a little while. So maybe not all files where re-imported before...
3. You ran the RM&CF function to point MC to the new location. But it was too late anyway. MC had already re-imported at least some of them.

If you only did this recently, or over a short period of time not long ago, you might be able to fix the issue by:
a. Backup your current library manually just in case you need to revert to it, if something goes wrong.
b. Restore a library backup from before you made the changes. MC makes backups automatically, so you should find one. Note that you will lose any and all changes made since that backup, not just these move changes. So you may have some work to redo if you have been doing some tagging.
c. Immediately turn off Auto Import by unchecking the setting at "Options > Library & Folders > Auto-Import > Run auto-import in background"
d. Use the RM&CF function to point MC to the new location of the files you moved.
e. Turn Auto Import back on when the above has finished and you are satisfied it worked.


As a side note, I believe that you can update the [Date Imported] field using the "Data Fiddler" component of the "Swag of Tools" utilities. But if you wanted to do that, what dates would you set the field to for all your files? Restoring a library backup is the only way to get the original data back.

[RoderickGI]

I was offering him a way to fix the damage he has done. I thought he may appreciate that.

Of course in future he should use the Move function.

[fitbrit]

One thing you might try on a test album is to run the update RMC command BEFORE you move the files in explorer. That way MC updates its location for the new files, and doesn't need to run an auto import afterwards to keep track of where they are.

Ideally, however, you'd do the moving in the RMC tool itself like suggested above a few times. My idea may not work, but it might be worth a try in case you love doing the moving in Explorer.

[JimH]

The Etiquette Police made minor changes above.

[JimH]

The wiki has a topic on this subject:

https://wiki.jriver.com/index.php/Moving_Files

[gulp]

Thanks much for all your answers!

To clarify:

I didn't have auto import activated, but anyway all files were recognized as "new"

I understood, that the best way is to use the "move" function and not do explorer moves.

I also understood, I could use a restored old library status and try again, but I suspect, the same happens again...they still show as new (as I didn't have auto import activated before). I want to avoid to undo the explorer file changes and user "move" as it was a lot of data.

I also understood there's an option with "data fiddler" to modify the "date imported" field and I will look into this. I could simply set it to a few weeks ago, that would do it for me in this case.

The wiki link unfortunately just shows the method I used and didn't work (which is shown in my screenshot), as well as the "move" practice which I just want to use as a very last option as I'd have to undo the whole explorer movement before.

[gulp]

In case of a restore of a previous media library backup: Is there an option to pretend to do a complete "move" with the "move" function although the files are already moved to the destination by explorer?

I'm just looking how to fix the situation if files are moved already, but the library is not yet touched.

[gulp]

One more question:
The "Date imported" field exported with the fiddler shows values of i.e. 1532771983

How can I conclude a date out of it?

But as I also use the QNAP version of JRiver for the same NAS content, I will have no fiddler option there anyway I guess. So my previous question of one post before at the moment is the most important.

[lepa]

In case of a restore of a previous media library backup: Is there an option to pretend to do a complete "move" with the "move" function although the files are already moved to the destination by explorer?

I'm just looking how to fix the situation if files are moved already, but the library is not yet touched.

If you do Library Restore from backup it will restore your database  as "untouched" so MC isn't able to currently find the files. Assuming you don't have auto-import on, you can then do "uodate database to new location (no file rename, move or copy)" to your songs which are now "missing".

If source (=filename in DB) and destination (=filename known by OS) matches in the RMC tool, your database entries will now be pointing to this new location on disk (destination) and import date stays the same. You don't have to do import as the files are now linked to database again in their new destination

[RD James]

If auto-import is disabled, using the RMC tool in update mode should mean that the files retain their original import date.
The issue is if auto-import marks the files as removed from the library, and then as new files once the move is completed in explorer.

[gulp]

If you do Library Restore from backup it will restore your database  as "untouched" so MC isn't able to currently find the files. Assuming you don't have auto-import on, you can then do "uodate database to new location (no file rename, move or copy)" to your songs which are now "missing".

If source (=filename in DB) and destination (=filename known by OS) matches in the RMC tool, your database entries will now be pointing to this new location on disk (destination) and import date stays the same. You don't have to do import as the files are now linked to database again in their new destination

Thanks...I did exactly this now and I also understood from the meaning of this function, JRiver should then leave the date untouched, but it doesn't. Everything is newly imported and shown as newly added...

[gulp]

If auto-import is disabled, using the RMC tool in update mode should mean that the files retain their original import date.
The issue is if auto-import marks the files as removed from the library, and then as new files once the move is completed in explorer.

Auto import was disabled and anyway it behaved as described above.

[lepa]

Thanks...I did exactly this now and I also understood from the meaning of this function, JRiver should then leave the date untouched, but it doesn't. Everything is newly imported and shown as newly added...

Are you sure you don't have those songs now twice in your DB? You shouldn't do any importing if you are using "update database to new location (no file rename, move or copy)"

I use this method all the time when replacing files with lesser quality with new rips and for me it has worked as expected so something strange is happening here. Though I don't usually use Search and Replace function

[blgentry]

I have done the operation you are describing quite a few times on all 3 major MC platforms (Mac, Linux, and Windows).  I've never had the import date get updated while doing an update to a new location.

It is highly likely that your files are being re-imported.  It's also highly likely that you have Fix Broken Links set to YES.  I would recommend setting fix broken links to NO.

It's mildly possible that you are using DLNA as your Media file source.  This is complicated because not only are you using a NAS, you're also using the QNAP version of MC at the same time as MC for Windows.  So it's not 100% clear what your library source is.

This is not to imply that you are doing something wrong or trying to prove you wrong in any way.  I'm offering my experience that I have used these techniques, without the issue you are describing, many times.  So it's likely that there is a setting or a setup issue that's causing the import dates to get reset.  Again, the files are almost certainly getting imported again.

To be explicit please verify the following settings under Tools > Options:

Library & Folders > run auto import in background > (should be unchecked)
Library & Folders > configure auto import > Tasks > Fix Broken Links

Restoring a recent backup and then playing around a bit is probably the way to go.  Your restore will take you back to the state you want (correct import dates).  ...and the great thing is you can try several times, since the restore will always take you back to where you started from.

Good luck.

Brian.

[lepa]

It is highly likely that your files are being re-imported.  It's also highly likely that you have Fix Broken Links set to YES.  I would recommend setting fix broken links to NO.

I think this could be it

[gulp]

Thanks a lot really to all of you, great support!

I had „fix broken links“ set to „yes, protect files from missing drives“. But this was not the problem or at least I got around the problem and found a solution by this way:

Instead of doing an auto import after using the „update to new location“ with search/replace of the new path, I at first just newly imported the new locations path and after that did a whole auto import of all folders.

This prevented the update of the „date imported“ field.

[lepa]

Glad you got it sorted