INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Query - What's the reason for the different copy / move behaviour?  (Read 3508 times)

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

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_Files
http://wiki.jriver.com/index.php/Rename,_Move,_and_Copy_Files

First 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 Observations
Moving Files
When 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 Files
When 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 Future
As 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?
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Query - What's the reason for the different copy / move behaviour?
« Reply #1 on: April 24, 2016, 08:28:18 am »

I've said it before, but I'm going to say it again.  Several points:

1.  RM&C is a fantastic, amazing tool.  It's a large part of the sophistication and flexibility of MC.  I couldn't live without it.
2.  However, because of the types of behaviors you describe, when moving large files (across drives), I prefer to use an external tool.  If I'm just moving a file or two, I'll use RM&C.  If I'm moving a dozen files or more, I use an external tool because the lack of feedback from MC bothers me.  This makes it a two step process:  Use external tool for moves.  Then update MC with RM&C in update only mode.
3.  The ability to show progress exists in the Handheld Sync tool.  If that style of feedback was employed by RM&C I wouldn't feel the need to use anything external.

Apparently #3 is difficult because it's been suggested several times and I've heard no feedback from the JRiver team.  Or maybe it's just ultra low priority.  I dunno.  I just know that this feature is near the top of my list for improvements.

Brian.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Query - What's the reason for the different copy / move behaviour?
« Reply #2 on: April 24, 2016, 10:29:20 am »

I've said it before, but I'm going to say it again. 

So have I. I'll just link to it though:
https://yabb.jriver.com/interact/index.php?topic=97980.0

It would be better in every way if RMCF operations ran in the Action Window, with:
* A progress indicator
* A cancel button which functioned as an Undo.

Also, this:

2.  However, because of the types of behaviors you describe, when moving large files (across drives), I prefer to use an external tool.  If I'm just moving a file or two, I'll use RM&C.  If I'm moving a dozen files or more, I use an external tool because the lack of feedback from MC bothers me.  This makes it a two step process:  Use external tool for moves.  Then update MC with RM&C in update only mode.

I understand completely where your preference comes from, but you totally don't need to do that. RMCF does work quite well, even for massive moves. I've used the Copy Modes far less frequently than the Move modes, but the Move ones work perfectly, and have for years.

There's just no progress and no easy/safe cancel-and-undo. I completely agree with you on the other points, and I agree that this would be my #1 request for MC right now, above all others.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: Query - What's the reason for the different copy / move behaviour?
« Reply #3 on: April 24, 2016, 10:49:52 am »

Regarding my using an external tool to move large files...

I understand completely where your preference comes from, but you totally don't need to do that. RMCF does work quite well, even for massive moves. I've used the Copy Modes far less frequently than the Move modes, but the Move ones work perfectly, and have for years.

I believe you that it works.  I've used it for maybe 15 GB of moves at a time.  But if I'm moving several hundred GB of files from disk to disk, I'm not even close to comfortable with MC doing it.  Why?  Not because I think it will fail.  But because it doesn't tell me anything.  I might close MC.  MC might crash (though it doesn't happen very often).  I'm just plain not confident in where things might end up in the event of a failure of some sort.  Using rsync instead, I have progress over the entire operation.  As a bonus, rsync doesn't really understand "move", so I'm really just doing copy and then delete once MC's file pointers have been updated.  This means that any failure isn't really a failure.  MC and the files are all still there.

If I haven't said so before, I've spent a lot of my professional career as a sysadmin, so maybe I'm more focused on these types of issues than other people might be.  I need to see progress on large moves and have confidence in how I would handle various failures.

Maybe we should bump your old thread?  It covered all of this, but got hijacked into a discussion about copying to client machines.

Brian.
Logged

Arindelle

  • Citizen of the Universe
  • *****
  • Posts: 2772
Re: Query - What's the reason for the different copy / move behaviour?
« Reply #4 on: April 24, 2016, 11:13:22 am »

The only thing that bothers me really is I also think that would be very cool to not lock the UI. At least not to stop playback on files that are not effected by the operation when copying

Regardless, the copy command seems to just use windows' pop-up which is fine with me, comforting. I like the copy command as doing this externally, it is a real pain to select directories to copy .. RMC can recreate the directory structure on the fly.

The move as he mentions, just does its thing (seems faster too).

I'd be fine having the windows pop-up show for both ops, just allow the UI to work during the process (or if for safety reasons, at least allow the track to play - I can understand if you are changing paths via Move, that might not be possible.)


The first link you posted Astromo is marked outdated .. I think Glynor was the nice guy that put a lot of effort in rewriting this section (if I'm wrong thanks to whomever did this :) ), so maybe it should be removed?
Logged

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251
Re: Query - What's the reason for the different copy / move behaviour?
« Reply #5 on: April 24, 2016, 11:49:44 pm »

Thanks for all the feedback.

I've totally missed the previous threads where this kind of thing has been raised before. If I'd spotted them, I would have chipped in with support. The thought did cross my mind that this must have come up before somewhere, sometime.

Let me say that my intention here is not to poke at any bears or anything untoward but if it bumps a couple of old threads that went adrift, I'm glad to have offered some assistance.

I really just wanted to tell my story and offer an outlook from a personal perspective of how I roll. Heartening to know, that there are some like minds out there, as far as shared expectations of the platform's function.

I would like to hear back from the JRiver crew to provide some insight into the philosophy that's involved here. Or, maybe it's a case of a design fork that's been purely organic in nature. Whatever the explanation, I'm keen to find out what it is and what's the scope for getting functionality aligned and hopefully improved.
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251
Re: Query - What's the reason for the different copy / move behaviour?
« Reply #6 on: May 01, 2016, 04:04:36 pm »

 ?

Any further feedback on this?
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT
Pages: [1]   Go Up