INTERACT FORUM
More => Old Versions => Media Center 16 (Development Ended) => Topic started by: sskings on June 27, 2011, 07:23:01 pm
-
Trying to use Library Tools>Rename, Move, Copy Files... over a network. Rename dialog shows a path starting with IP address of media server computer. Renamed file ends up in C:/Users/.../J River Conversion Cache. Filename on media server computer is never changed.
Windows permissions on network are set correctly because I can do same operation in Windows Explorer.
Is there a way to change filenames remotely using JRiver Rename command? Thanks. Steve
-
From my experience, no. In essence, MC is transferring the files to your client and then the rename/move/copy operations are performed on the client computer. This is why the cache is made on the server during the transfer.
-
Thanks. Puzzling that one can edit files remotely (for example tags) but not rename the file. Do I have this understood correctly.
-
Thanks. Puzzling that one can edit files remotely (for example tags) but not rename the file. Do I have this understood correctly.
Tagging files is updating the media center library not the actual files in the filesystem, so there is quite a difference between the two actions.
-
Tagging files is updating the media center library not the actual files in the filesystem, so there is quite a difference between the two actions.
Doesn't updating the meta-data also cause the file's tags to be updated by the server (when update file tags is set)?
-
Yes. This doesn't work for the same reasons that the Send To -> External choices and the Drag-Drop to the desktop don't work from a Library Client machine. When you are connected to a Library Server, the "filenames" of the files are not direct pointers to the files on disk, because the system does NOT assume that you have the same filesystem mounted locally. It is designed to work without an accessible network share, and over the Internet.
This means that the "filenames" you access from a Library Server client, are basically just special pointers to the files on the Library Server, and not representations of the files themselves. That's what those weird URLs are that you see.
The system in MC works around this, by communicating with the server and applying actions there. It applies the metadata changes locally, and then syncs these changes back to the server. It also works for some "file maintenance" things, like deleting files, but even this doesn't work perfectly (if you delete a file on a Library Server client where the system would normally pop up the dialog asking to remove the empty folder, this dialog actually pops up on the Library Server machine itself, which might be useless if the Library Server machine is headless).
It is too bad. It ends up limiting me fairly often in practice. I think that ideally with some future version: If the filesystem is there, MC should be smart enough to use it and give you the full power and access to all the tools just like if you are on the server itself. If the files in question are not available on a "local" filesystem (network mounted drive, mostly), then it should gray-out those functions whenever possible (internet streaming mode, essentially).
-
I think that ideally with some future version: If the filesystem is there, MC should be smart enough to use it and give you the full power and access to all the tools just like if you are on the server itself. If the files in question are not available on a "local" filesystem (network mounted drive, mostly), then it should gray-out those functions whenever possible (internet streaming mode, essentially).
You're telling what I dream of at lonesome nights ;) Working with a MC client-server environment often means controlling MC via clients and leaving the server headless. A similiar topic is about changing theater view settings or view scheme settings on a client and synching them back to the server...