Print

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

[Gatherum]

So I have a fairly complicated Media Server setup going. This will take some words to explain.

Plainly stated, I am using two copies of MC21 in a client/server setup: one on my HTPC (the server), which runs at startup in theatre mode, and one on my laptop (the client) for control. I also have mcEffect installed on my phone for remote control, but that's not really relevant.
The MC21 client performs well enough, except that it exhibits two arguably critical shortcomings that keep this whole setup from being a fully functional client/server relationship:

• 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.
  

As an attempt at a workaround to all of this, I tried using an extant installation of MC20 to perform the above operations, building its media library from the server assets on the spanned volume that hosts all of the content, exploiting that volume's mapping to the client as a network location with its own drive letter. This way, I can, indeed, perform the above operations, but there's yet another problem:

None of the tag changes I make on the client MC20 are reflected on the server MC21, and by extension, not on the client MC21 either. At best, it fills the Name field with the new file names, but that's it. The cover art is not retained. If I want these files to reflect those changes, I essentially have to do the same work all over again on the client/server MC21, which brings me straight back to square one because, again, cover art cannot be saved to server assets via a client.

These various issues really need to be fixed or mitigated somehow. MC is so close to being the perfect client/server media jukebox player, not to mention a metadata freak's dream, but with current shortcomings, the whole experience is just tedious.

I guess it's worth noting that this isn't so much a problem with CD ripping: if I fill out the tags for an album in MC20, and then rip the tracks to the server's network location volume, they will appear with the correct metadata in client/server MC21. But for downloaded files and DVD's with 5.1 surround mixes ripped via DVDFab (since JRiver does not have the option to rip the audio from a DVD)? Forget about it.

I would really appreciate a reply, even if it's just to say that all of this is impossible to fix. I'm not trying to sound like a jerk or anything, but I get some kind of response in maybe one out of every seven threads I post, and that's a little demoralising.

[glynor]

• 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.

[glynor]

None of the tag changes I make on the client MC20 are reflected on the server MC21, and by extension, not on the client MC21 either. At best, it fills the Name field with the new file names, but that's it. The cover art is not retained. If I want these files to reflect those changes, I essentially have to do the same work all over again on the client/server MC21, which brings me straight back to square one because, again, cover art cannot be saved to server assets via a client.

By the way, I'm not 100% sure why this method isn't working.  It would depend on a few different things being true, however.

* You'd need the Server's Auto-Import function to be turned on, and set to Update for external changes. The server may not see these changes instantaneously, depending on the filesystem setup (on a NAS if MC doesn't get filesystem events, you'll need to wait for the next "full scan" of Auto-Import).

* The Client copy of MC (and there's no good reason to use an old copy, just use MC21 and launch it with the /Library command line option to point it at the Library you want) needs to be set to write changes to the files (Tools > Options > General > Importing & Tagging > Update tags when file info changes).

* The Client copy of MC would need each Library Field that you want to be able to change set to Save in file tags (when possible), and the files themselves would need to be in a "taggable" file type (MP3, FLAC, APE, etc). If you need to work on video file types, you'll need to make sure Sidecars are turned on for both the Client and the Server copies of MC. Any Library Field that doesn't have this setting set (and many do not by default) won't sync because the changes are written only to the Library, and not to the files.

All that said, that's pretty fragile and depends on a lot of switching around anyway. You'd be better off, probably, using a scheme like I described above to work directly on the "real" Library (and not rely upon in-file tagging to cause the data to replicate).

[Gatherum]

...and the files themselves would need to be in a "taggable" file type (MP3, FLAC, APE, etc).

Ahhh...perhaps that's why. I've been working with straight-up DTS and AC3 files ripped from DVD's. I'm guessing those aren't taggable, much as they are playable in MC.
Also explains why the CD rips were working, since I always rip to FLAC.

Out of curiosity, is DTS and AC3 playback a common feature in media players, or is MC unique in that aspect?

[glynor]

Ahhh...perhaps that's why. I've been working with straight-up DTS and AC3 files ripped from DVD's. I'm guessing those aren't taggable

Yep. That's it.

Out of curiosity, is DTS and AC3 playback a common feature in media players, or is MC unique in that aspect?

I don't know if it is 100% unique, but it is relatively rare. Hendrik wrote the DTS decoder MC uses himself, and they've done a lot of work on those specific formats over the years.