Print

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

[whoareyou]

1) I selected Rename (move files if directory changes)
2) Selected directories check box
3) Specified Base Path with same base directory as original files
3) Specified Disc[Disc #] to create new path in base directory
4) Executed

Upon execution everything looked to succeed,
However, the operation had silently failed. The new directory was never created (permission error that prevented the directory's creation) and
the files were never moved.
The database was updated correctly to the new path which did not exist

Edit: This was a network SMB drive

Of course this should fail, but JRiver should have presented an error message and the database should not have been updated.

Thanks




 

[EnglishTiger]

One of the things I've noticed about any Rename operation that involves moving files - it updates the database to reflect the "intended" new location of the files before it has started to move them instead of waiting until the files have been placed in their new location.

[The Big Labinski]

I fully agree with whoareyou. MC should display an error message. Would be very happy if this could be fixed very soon, it's somehow a very risky behavior.

[glynor]

One of the things I've noticed about any Rename operation that involves moving files - it updates the database to reflect the "intended" new location of the files before it has started to move them instead of waiting until the files have been placed in their new location.

All of these things are side effects of the fact that Rename, Move, and Copy operations in MC are tagging operations, and are done through the regular tagging engine. The RMCF tool is just an automated method of changing the [Filename] tag. You could change it yourself by hand, and it also moves the files (just like RMCF in rename mode).

Though I will say, two things: I haven't ever actually seen it not show an error message eventually if you let it go long enough. However, it will also wait on stuck files a LONG, LONG time. If a file remains in-use, the MC tagging engine (like any tagging operation that can't write tags to disk) will just keep trying until it succeeds. If you kill it while a RMCF is running, thinking it is done, that's where you'll get into trouble. I'm assuming that's what happened to the OP. Killed it, or rebooted or something, while MC was still trying to move the files (perhaps because some were read-only, or not writable, or otherwise stuck and so it was never going to finish).

The second thing is that I agree it could use some work. A progress bar, cancel button, and completion queue, similar to a Handheld Sync would be my preference. It could still process them as a tagging operation as it does them, but because moves and renames are often a much higher "latency" (when moving from disk to disk, certainly) than a normal tagging operation, often long-running, they really need special treatment. The Status Bar status is not appropriate for them (and doesn't even show constantly, as you switch around Views). It needs a progress dialog, and the cancel button, if hit, should prompt whether the operation should be cancelled and left as-is, or rolled back to before the operation was started.

And, while you're at it, it really needs to handle overwrite collisions itself, rather than throwing that to the OS. As it is now, it too often pop-ups constant "Are you sure?" dialogs if it has to overwrite files on disk (usually when moving sidecar files and other metadata files). It is impossible to get it to just "continue", or even cancel, the whole batch as it is because the OS dialogs get called 1-by-1 and not in a "batch" (so checking the "and don't ask me again" checkbox doesn't work because it only applies to that one move, and not the next). MC should, instead, handle this internally prompting the user as needed with its own "keep going and overwrite, create a copy, or cancel" dialog with a "and apply to the rest" checkbox, that actually works.

[EnglishTiger]

Upon execution everything looked to succeed,
However, the operation had silently failed. The new directory was never created (permission error that prevented the directory's creation) and
the files were never moved.
The database was updated correctly to the new path which did not exist

Edit: This was a network SMB drive

Of course this should fail, but JRiver should have presented an error message and the database should not have been updated.

Thanks

Glynor - The user did not kill the operation! A "permissions error" prevented the moving of the files from there old location to the new one.

But because updating the location of all the files in the database happens before it tried to move the first one whoareyou ended up with files that hadn't been moved, because either MC or the OS could not move them; and a Database that was saying it had moved them.

When it comes to overwrite collisions, I agree it does need more work, On my set-up when carrying out the first part of the process MC will tell me if one or more collisions will occur but it does not tell me how many there are or provide a list of "Possible Collisions" before asking for permission to proceed.

[whoareyou]

Just clarifying that the operation was not cancelled, but rather completed without error message. 
When I went to play the files, I realized something went wrong.

Was curious to see what would happen, so I "repaired" the database with the same exact operation (simply changed the template back to the original location) and "moved" them back to their original location.  No error message with that move either, but that too should have failed because the source files did not exist.

It just updated the database, which is what I wanted to happen.

Honestly, I am still not sure what happened with the SMB permissions, but somehow the directory was foobarred.  It would not allow directory creation (Windows explorer returned a permission denied error).

My assumption was that if explorer was displaying an error message, then JRiver should have received exception, but failed silently.

Thanks

[EnglishTiger]

It would appear that using the Copy option, with and without updating the database, is the safer way of moving files around because MC, openly, hands the copying of files over to the OS (see attachment) and does report any problems it encounters. Plus if the "copy and update database" option is selected the database update doesn't happen until the file(s) have been copied.

[wer]

Safer, perhaps, but inefficient: enormously slower, and it leaves all the originals around for cleanup.  That's not a solution.

RMCF is a hugely important tool, and a great asset to MC. It should be as bulletproof as possible.

I have had it fail on me occasionally in the past, and I wonder if you guys are seeing manifestations of the same thing.

I think it might be a good thing if RMCF had journaling.  That way the process could be interrupted and resumed without problem, and also reversed if necessary.

[whoareyou]

Journaling would be great and gold plate the entire process.  It would be a great feature to add. 

As a first step, I would appreciate if the code's error handling could be reviewed and improved where necessary. 

[glynor]

Just clarifying that the operation was not cancelled, but rather completed without error message. 
When I went to play the files, I realized something went wrong.

I think you completely misunderstood my point, and still don't understand something about how it works. I'll say it another way:

How do you know it completed?

Because, it didn't, until the files moved. The database always updates immediately, and the dialog closes. That does NOT mean RMCF is done. It will always update the database and close the dialog immediately, but it can take hours, or days, to complete, depending on what it is doing. While it is in progress, the only indication of the activity is occasional updates to the Status Bar.

You saw the Status Bar process all files successfully one by one and they hadn't moved? Because that would be shocking.

I've seen it error in cases where permissions are messed up like that before, and it took a few hours before it would give up and report an error.

[glynor]

And, just to be clear, again: I'm not defending that behavior. It is bad. I'm only explaining it, and that is how it works. And, generally, if you wait it out, it "does the right thing". But you really, really have to wait it out, and carefully check the status bar (over minutes if you're also navigating around because it only updates it periodically) if you think it might not be doing anything.

[whoareyou]

I think you completely misunderstood my point, and still don't understand something about how it works. I'll say it another way:

How do you know it completed?

...

Thanks, your explanation is very helpful as I never would expect such behavior, but it does not explain what occurred.

It was a very small batch (10?) of files which should have finished quickly.  More to the point, the permission error made it impossible for the operation to complete.

Note that when using Windows Explorer, attempts to manually create the same sub-directory failed with the permissions error. 

That Explorer error was how I quickly understood why JRiver had failed.

The JRiver operation now works as expected since correcting the network issue.

(Only thing I can add is that the cause of network issue remains a mystery). 

[glynor]

It was a very small batch (10?) of files which should have finished quickly.  More to the point, the permission error made it impossible for the operation to complete.

Right. That's the part you're not getting. It doesn't matter if it was only one file, it can still take hours and hours to "fail" if it encounters a problem like that. With any tagging operation, MC will continue to retry on write failures over and over and over. MC doesn't know why it failed, only that the OS reported "access denied" (which is the same thing it gets if the file is in-use). That behavior is useful in most circumstances when applying tags: For example if you are playing a file and you change the tags on it (to add a rating, for example) while it is playing. MC will silently keep retrying over and over until it succeeds (when you stop playing the file).

If it tried once and errored and stopped trying, it would be super-annoying. You couldn't use MC to tag any file that was actively playing, open in another application, or temporarily locked/in-use for any other reason. So, for basically all tagging operations, silently failing and retrying is the desirable implementation.

As I said above, RMCF operations are tagging operations. Therefore:
1. The database updates immediately.
2. Then these changes are synced to the files on disk.
3. If any files are locked, it retries silently over and over until it succeeds.

There is some maximum limit on how long it will retry in #3, and then it shows an error dialog, but it is LONG. Maybe 24 hours or something?

I do agree that RMCF operations should be treated specially, but they're not. It is no different than adding a Rating or Comment tag. It behaves identically.

[whoareyou]

That's the part you're not getting. It doesn't matter if it was only one file, it can still take hours and hours to "fail"....

Ok.  I finally get what you are saying.  I never considered that an individual file operation could be retried for (24?) hours. 

As far as the status bar and if it was showing progress that went unnoticed by me?  Not 100% sure. I could have missed it. 

I will say that when tagging operations have been in processing in background, and I closed down JRiver, a dialog box is displayed detailing the operation in progress.  I do not know if that should have happened in this case, but there was nothing that indicated JRiver was working on anything at shutdown.

Anyway, not sure what else there is to say on this.  The feature is what it is, and it is mostly good. 
Worth improving?  Not sure people utilize it that frequently ( I certainly do not).

@glynor - Thanks for the input. 

[EnglishTiger]

I agree that using the "Copy" option to move files and then telling MC to delete the original files and then import the Copied Files is less Efficient, in terms of Human Activity, than using the Rename + Move Option.

Yesterday I carried out a couple of "small" experiments to compare using Win Explorer to copy a bunch of files that MC knew about, from one SSD to another SSD, against telling MC to carry out the same task.

The files I chose were from a group of older Compilation Albums that had been ripped by either MC25, MC26 or Win Media Player and were held in an Album Type/Album Artist/Album Name folder structure using a Disc # - Track # - Title file naming rule. Since the Album Artist was set to "Various Artists" there was only 1 folder at the second level with 113 Album Name folders below that.

For the Windows Explorer only test I simply told it to copy the Top Level Folder from my F drive to the Music folder on my C Drive. It took Win Explorer almost 83 minutes to copy 12,670 files in 115 folders at some very noticeably different rates, at one point it was copying at 1.47Mb's/second at other times it was copying them at around 400Mb's/sec.

I then deleted all the files that had been copied to the C drive Music Folder and told MC to copy only the files it knew about, all the .flac files. This turned out to be a 3 stage process the "Checking" phase, the "Working" phase and then finally the actual "Copying" phase. It took MC86 minutes to copy 11,563 files in 114 folders. Even if you deduct the 60 seconds it took for the 1st 2 stages/phases that is still longer then it took Win Explorer to copy more files and folders. N.B. I'd issued the "Copy" command in MC from a View where the albums/folders and tracks/files within those albums/folders were in exactly the same order as they were for the 1st test.

One thing I noticed when using MC to do the copying was that when I used Win Explorer to watch what was going on in the destination folders MC created all the folders before doing any file copying, from the date stamps on those folders it looked like this had happened during, or immediately after, the "Working" stage/phase, Whilst Win Explorer had used a create each folder then copy it's files when a change in folder name occurred.

Now for the bit of information I have intentionally held back till now. During both tests MC was "supposed to be" playing tracks from a playlist that included tracks from some of the albums/folders being copied although I'm pretty sure that MC was not trying to play a track whilst either test was trying to copy it.

At no point did the 1st test impinge on MC's ability to play tracks, switch from track to track, or it's ability to update the screen in a timely fashion.
But when I ran the second test the MC screen within seconds of the Copy operation starting the player window and progress bar FROZE, the track that was playing did play through till it's normal end but MC did not advance onto the next track either whilst the copying operation was running or after it had completed. Partially confirming a suspicion that I've had for a long time - that MC is assigning a higher priority to it's background tasks than those it is carrying out in the foreground. I've seen MC stall/temporarily freeze when I've thrown as few as 10 tracks at all variants of the  File Rename, Move & Copy functionality.