- Rename, Move, and Copy Files never worked properly in this kind of setup, and was thus removed. I was hoping for an actual solution to that, but I guess it simply can't be done, or it's beyond the scope of JRiver. I would like some clarification on this.
- One is unable to paste cover art in to a file from the clipboard on the client to server assets. I'm not sure why, but the end result is that, in order to add cover art to anything, one needs to access the server, copy the cover art to that clipboard, and paste it there. Get from Internet... doesn't do the job, either, despite it still finding results. This is ridiculously unintuitive in this kind of setup.
Both of these issues relate to the fact that you are not able to import or upload files from the client side of a connection to the server side of the connection. I don't think it is impossible to fix, but it would take quite a bit of work (because HTTP POST is limited in file size, so you'd have to build, essentially, FTP-like functionality into the server). But, the net result is that any function that needs to add files to the Server's storage, or change file locations on the server's storage, are non-functional. That certainly includes tagging cover art, which would have to upload the artwork file to the server.
I
certainly agree that I'd like RMCF functionality fixed when used from the client, and have posted about it before. This aspect of using MC in a client-server setup has gotten
worse over time.
One thing you
can do now (admitting that it is pretty clunky) is:
* Share the Library filesystem location as a network share on the Server.
* Add this Library as a secondary Library on your Clients using the UNC path to the share. I name mine like this: Home (on Server) for the "regular" one and Home (Direct) for the directly-connected-to-the-Library location version.
* Make a "temp" Library for the Server (I call mine "On Hold") which doesn't really have anything in it, and is just a Library to "park" on the Server while you do what you need.
Then, when you need to do RMCF or cover-art tagging, you can:
*
Close all Client copies of MC (this is important or the sync will get all messed up).
* Switch the Server copy of MC to an alternate Library. This makes the real "main" Library available in Read/Write mode (otherwise if you connect to it, it'll be locked to Read-Only mode). You can do this with a script I wrote exactly for this purpose.
http://glynor.com/files/MCUtilities/MC-Switch_Library-1000.zip* By the way, I do this instead of
closing the Server copy of MC, because if you
close MC on the server, then it won't be running and "listening" for MCWS commands anymore. So, there will be no way to send it a command to re-launch remotely (and you'd have to use something like Remote Desktop to do it yourself). So, instead, I switch it to an "On Hold" Library that doesn't do anything other than give it a place to sit while I finish.
* Then, after that is done, you can re-launch your client copy of MC with the /Library
Command Line option to load a specified Library, and load the "Direct" version.
* Do whatever work you need. Performance will not be great
because it is using a Library on a network share, but you can get away with it for RMCF and other similar tasks.
* When you're done, close the "client" again, and then re-run the script to switch the server back to the normal Library.
* And, lastly, you can re-launch any clients again. Do this with the /Library command line option to make sure they open pointing to the "real" Library (and not that "Direct" version you made). I have all of the Windows shortcuts on my Clients "pre-set" with the /Library command all the time. By default, MC always re-opens whatever Library was loaded last time, but the /Library command lets you specify it, so I just always specify it (and then have a special shortcut only used for this purpose that opens the Direct version).
Clunky, but this
works. I use it at work all the time to do RMCF tasks on a server that runs on a VM.
The most important thing is to make sure that ALL clients are closed before you start. Otherwise, bad things happen. The clients won't know that the server has switched to a different Library, and will keep trying to sync changes. The problem is that the "temp" Library you load on the Server (in order to make the "real" Library not-in-use) probably doesn't have much of anything in it. Any connected clients, though, don't "know" it is a different Library and they keep syncing to it, and they'll basically obliterate their "synced" copies of the Library. Then, when you switch the Server back to the "real" Library, they'll keep syncing, and sync all of that chaos back onto the "real" Library.
You can script the closing of Clients too if you know what they all are called and if they also have the Media Network features enabled. I don't have a ready-made script for you for that (because it doesn't matter for my purposes), but it could be done.
Again, all that said... Clunky. I agree some improvements here would be welcome.