You got most of the acronyms. Sorry, since you were talking servers, I made some assumptions about your level of knowledge.
RDC: Remote Desktop Connection. This is the remote desktop system built into Windows Pro and Server editions. There are a ton of other third-party options too, including VNC, which have various benefits and detriments.
VM: Yep, Virtual Machines. I run two different "server" instances of MC (on Windows Server) at the office which are both on VMWare VMs. The point is that these servers have no physical box, and certainly no monitor, keyboard, or mouse. They "live" somewhere in a rack of servers somewhere in Connecticut, I think. I've never seen them. But, I don't need to log into them more than once in a blue moon, in most cases. The thing that annoys me most is when I need to move files around, but I work around this using a system basically identical to the one I described above. I switch to a "local library" copy of the server's Library, use Rename, Move, and Copy from that computer to move the files (this "breaks" the original copies in the Server), but then Auto-Import picks up the newly moved copies and fixes itself. The only bad thing (if you care) is that this wipes your [Date Imported] tag, and you have to make sure MC can properly fix broken links while doing Auto-Import (which is usually not a problem unless you have a weird disk setup).
UNC paths: This is a way to have a filename path on Windows that points to a network (or local) file or directory that does NOT start with a drive letter. They're formatted like this:
\\servername.domain.com\share_name\path\to\the\file.flac
If you don't have a full domain name and DNS server (as most people wouldn't at home), you omit the domain.com part and just use:
\\servername\share_name\path\to\the\file.flac
More details:
http://compnetworking.about.com/od/windowsnetworking/g/unc-name.htmhttp://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspxhttp://msdn.microsoft.com/en-us/library/gg465305.aspxhttp://stackoverflow.com/questions/2787203/unc-path-to-a-folder-on-my-local-computerMC will accept UNC-style paths in
all places where you can enter a file or folder path (usually by hitting a browse button and finding the file or folder you want). Part of the beauty of this system is that they are connected "on demand", as opposed to Network Drives with a drive letter, which solves some problems when a machine is first booting up and the network might not be "up" yet (a drive letter network drive shows up as "missing" to the OS, where a UNC path tells the requesting application essentially "wait a sec"). The other big benefit is that it doesn't matter if the path is local (on a disk inside the actual computer) or on a remote computer, the path never changes.
So, the way my servers at the office work is that ALL files are imported using UNC paths (even those on the local C drive) rather than via their "regular drive letter path". That way, the "filename" looks the same to all connected clients, and can be accessed by those clients directly (assuming the logged-in user has appropriate permissions to access the file share), without having to go to each client and map a matching drive letter.
Auto-Import can watch these UNC style paths just like it can watch a folder on your hard drive. And because MC's Auto-Import system isn't dumb, it actually works well and doesn't cause performance problems.
The way MANY (dumb) auto-import type systems work in most other applications is that it does a periodic rescan (ever 15 minutes or whatever) and looks for new files, by checking every single file it can see and looking for new ones. That's terrible, especially with network drives and other slow drives because it "eats up" the network every 15 minutes scanning through a bunch of directories, most of which have no changes.
That is NOT how MC's works. Instead, MC registers for what is called Filesystem Events through Windows. When a file is created or modified in a "watched" directory, Windows tells MC about
just that file that changed, and it imports
just that file. You can search Interact for "auto-import" and my username for further details if you're curious, as I've explained it a ton of times in the past. The rub is, though, that as long as your network shares aren't on a broken NAS device that doesn't support Filesystem events (there are some of these things out there), MC's Auto-Import system seems like magic. It imports new files, almost immediately after Windows is done modifying/creating them, and does it without pummeling the network with a bunch of regular scans.
Windows file shares do have a permissions system that you'll need to learn about. In many home-user situations, this is simple to handle. Make the username and password the same on all of the machines, and set them to auto-login using that username. Then, all files "owned" by one user, will be automatically owned by the same-named users on the other machines.
If you are going to try to actually set up and manage an ActiveDirectory domain on your home LAN? Well... Frankly? You shouldn't be asking these questions because you'll be in way over your head. AD is NOT for the feint of heart. It might be a fun project if you want to learn, but you're going to annoy your family a bunch for the next three years while you learn it.
As far as your last point... The word "server" can mean a LOT of different things, in IT parlance.
MC is a
client application, which (like many other client-side applications) can run a server. Actually, it can run a few different servers, for different purposes, but that's getting way into the weeds. It is NOT, in the traditional sense of the word, a "server" application that runs as a service. It has many of the same characteristics, but there is no "server edition" of MC, and a separate client edition. The client is both a client and a server. This has many benefits, once you get into actual use-cases for MC, and the reverse has typically only niche benefits and edge-cases.
But, MC can be sufficiently automated that most tasks can be easily accomplished with a combination of connected client computers, and occasional direct access to the server instance. Client computers can add, modify, and delete tags. They can manage playlists, and perform a wide variety of other tasks depending on your network setup. They cannot:
* Manage files on disk using the Rename, Move, and Copy tool. This is server-side only.
* Modify the "setup" of the Library at all (construction of or configuration of Views in Standard, Media Network, or Theater Views).
* Import files.
The last one, as I mentioned, I agree would be handy.
However... There are sticky issues in how to implement this well. The big issue is that they cannot assume that the end-user has actually set up network shares where all of the clients can access filesystems directly that the server can also see. Remember, MC clients can connect to servers across the Internet, not just at a LAN. I'm at work right now, listening to music served by my computer at home. I can't get to my network drives right now (well, I can if I want because I could connect to the VPN I have at home, but I'm a huge nerd with a super-fancy firewall, most people can't do that).
But... If they let you import from a client, how does it transfer the files to the server? It can't just save them to a local disk, because then the server can't see or use them (unless the user sets up shares and is on a LAN, which they can't assume has been done). So, what if you're trying to import files that are 10, or 50, or 600GB in size? How does it send the files to the server? You can't upload files more than a handful of MB via normal HTTP POST system that a web server would typically use, and if you're on some kind of slow DSL connection at home and you try to "rip" a 50GB BluRay disc on a client? What does it do?
So... That solution is complex. I suspect they're thinking about it, but I don't think it is a simple fix because of the design considerations of MC's Client/Server system.
Author
Topic: Can I rip from a PC to the Server Library? (Read 6091 times)