OK - here's one for the developers.
I'd like to understand MC's apparent behavioural difference between the process of copying files and moving them. If there's something I need to tweak, then please advise. Apologies in advance if I've missed the forum post on this one and the advice provided on the Wiki doesn't give me any cues that I can see:
http://wiki.jriver.com/index.php/Moving_Fileshttp://wiki.jriver.com/index.php/Rename,_Move,_and_Copy_FilesFirst some background to set the scene ...I've finally got some time to myself around the house where I can put in a bit of MC library tidy up time to the MC TV recordings and other video files to hand. So, I fire up a playlist and have MC play some relaxing tunes while I'm on the job. So, for various purposes I'll be moving and copying video files within MC (as per the Wiki advice noted above) to make sure that library integrity is maintained using F6 - Rename, Move, and Copy Files.
Note that the file manipulation process (given the speed and grunt of my setup - JRMark 3065) can take a number of minutes to perform for multi-GB vid files and network speeds when transferring files.
Also, FWIW, I've got audio Options set to the recommended 6s pre-buffering and the box "Play files from memory instead of disk" is checked.
All good so far.
The ObservationsMoving FilesWhen I initiate a move, the only outward advice that I get that anything is happening is that MC is saving tag changes in the bottom right of a standard view window. When the job's done, I'm advised that MC is "Done saving tag changes". Refer the pics for info.
During this process I can still operate the MC GUI, listening to audio and (if I want) I can skip a track or pause playback.
Copying FilesWhen I initiate a copy, MC's behaviour is completely different in 3 key ways:
- Outwardly, the Windows standard copy process dialogue pops up giving explicit advice of the process progress (refer 3rd pic)
- The MC GUI is locked out. I can't make any moves within the application
- When the audio playback changes tracks, it stops until the copy process has completed (if this ends up being a few minutes, my relaxing audio environment becomes silence .. so, not how I'd like life to be)
The Questions- What's the reason for the fundamentally different behaviour between Move and Copy?
- How hard would it be to integrate the Move / Copy functionality within MC so that it's at least consistent?
- Would it be easy enough to apply the best aspects of how Move and Copy currently work in the 2nd point above?
A View for the FutureAs far as the best aspects of the current Move / Copy functions are concerned from my perspective, they are:
- Explicit advice to the user of Move / Copy process progress including an estimate of time to complete
- Concurrent functionality of the GUI and the playback engine, so that the user can still enjoy media playback and operate the MC GUI while the Move / Copy process is progressing
Feedback? Guidance? Thoughts?