Print

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

[EricTheBlue]

I've decided to store different media files on two different servers:  One for movie files (.MKV) and the other for music (.FLAC).  The reason is that both servers will play back their respective files locally in addition to serving content over my LAN, and the selected hardware is optimized for both types of playback.

Question:  Can clients on my network be configured to permanently access media from both servers (and by extension their respective libraries)?  If yes, can I use a single MC license to deploy both servers?  I would assume that if I do separate server installs, unique access keys will be generated for each correct?

Thanks in advance for your help.

[MrHaugen]

If you want to access two different server instances at the same time with ONE client, then no. This can't be done. Why would you user two libraries for different media types? One server is able to serve all types of media for all kind of clients and in any numbers. You will only create a ton of problems for your self, trying to separate it. I would only use this option if there are highly different user groups that are accessing each library, and that you HAVE to separate them because of some security issue. Otherwise, no.

And yes, you can probably use several server instances with the same license. JRiver usually allows using the license on more than one computer as well. If it's within your own household. Reasonable amount of clients is what's usually being said.

[EricTheBlue]

Thank you for the quick response.  I believe I (mainly) answered your question concerning the desire for two servers in my initial post, but I should elaborate.  Whether I use two servers or one, the server(s) will not only offer content to clients over the network but play back content locally.  The movie server hardware (deployed and active) offers average audio and video quality, which is fine as I am not a true videophile and don't need high-end audio quality when watching movies or TV (this server also provides HD cable TV/DVR service via Win8 WMC).  However, I am a "lightweight" audiophile, meaning I don't need Krell/Mark Levinson quality gear to be satisfied but want sound quality better than the typical AV Receiver.  In a few days I'll have the gear to build a dedicated, PC-based audiophile grade system.  I realize that I can always just configure MC on this rig as a client to access my music collection currently ripped on the server.  However, my audiophile instincts (and I could certainly be wrong about this) suggested that I might get slightly better sound quality on the audiophile rig from a local SSD vs. network streaming from a network server.  Hence the motivation for separate movie/tv and audio libraries.  However, the ability for all clients in the house to access all media content (sans TV) via my LAN trumps storing audio files on a separate server if doing so will cause problems as you suggest.  Put another way, having dedicated, separate movie/music libraries would be nice if MC natively and easily supported it, but it's certainly not something I feel I have to do.   

[goatherder]

Shouldn't be any problems in MC monitoring multiple shares which may or may not be on different servers.

[EricTheBlue]

Thanks for the input.  Perhaps I'll give it a try.  What's the worst thing that could happen (famous last words...)?   Seriously though I doubt I'll loose any media files in the attempt and if some type of client access problem occurs I'll simply change the new music server to a client and stream the content from the remaining server.

[MrHaugen]

What you should do it to make your "video" server a dedicated file server. Nothing else. Just share the video's through a UNC path. Then you build your new, hopefully faster machine and creates that as a server. Then you load this server with audio AND the video from the UNC path. Then you have only one library, a heck of a lot less mess, and you can stream and directly access ALL your media from one location. This is the preferable way for most, and I would bet my life this would simplify things for you as well.

Using an SSD might improve sound if you care about machanical elements drawing more power or introducing some kind of vibration. I do not think I would hear any difference, but SSD is certainly better than a standard drive anyway. So why not. BUT if you have a good amount of music, this WILL become expensive. I would first consider having the OS disk with thumbnails and other stuff on SSD. Then the media it self, if it's not too much data.

[EricTheBlue]

Unfortunately, because of the design of the pending music server/player case, I have to keep the Ceton tuner card I use for cable TV/DVR function in the PC that also serves/plays movies (mainly .mkv bluray rips).  The music server is handsome (IMHO) but physically small and only has one PCI(e) expansion slot which will be occupied by the sound card.  http://www.hd-plex.com/hdplex-h5.s-fanless-computer-case.html.

My current MC server is storing and playing (locally in living room) all media types.  It has a 7 channel sound card in it and functions as a prepro.  For movies and TV its performance is more than adequate.  However, for music I found its quality to be comparable to a $800-$1000 AV receiver, but not quite as good as the last flagship AV receiver I owned (Onkyo TX-NR5800-it had myriad HDMI handshake issues however and ultimately had to go).  Thus the motivation for a dedicated, PC based sound system.  It will allow me to easily experiment with different sound cards (internal and external) and really, I always wanted a dedicated music system anyway.  In terms of hardware, my plan for the music system is the inverse of what you suggested.  My current server is acceptably potent in terms of hardware (Intel i3 3225, 8GB RAM, 10TB storage via RAID5) for media playback and distribution, but I don't think I'll need such processing power or storage for a dedicated 2-5 channel music only system.  Thus, for it I'm going to use a spare AMD A4 trinity dual core CPU, a spare SATA II SSD for the OS and dual 256GB SATA III drives (mirrored for data protection via Windows for music file storage.  The SSD capacity will be more than enough for the foreseeable future.  My entire music collection via FLAC only occupies 106GB and at the rate I plan to buy music going forward it will take years to fill the remaining 150GB.

I see no harm in trying to establish two MC servers.  If it doesn't work, I envision two options:  1-simply stream the audio from my current server to the music system as a client.  2-keep copies of my complete music library on the main sever and music system, but only share music via the main server.   

[MrHaugen]

Then you use the Video server as the server, and the Music server as the client. You store all the media on the video server, or share the music from the music client, and then add the files to the library of the server. Connect to the server that now house all your media, and play what ever you want, where ever you want.

[EricTheBlue]

Interesting!  Let me make sure I understand what you're suggesting.  Keep the movie files on my existing main server.  Store the music files on the dedicated music PC for local playback but incorporate them into the server by using the add files feature on the server by sharing my music folders on the music system so the server and all clients can see it.  Doing so should allow all clients to use one server and one library (with the music files literally stored on the music PC but virtually stored on the server):  Clever... .

I don't remember the specific menu for this but if memory serves I'll have to set the client music system to allow auto sync with the server, plus also configure the client to look for the music files locally first before playing from any other network host correct?  IMS there are client settings for both items. 

I am following correctly?

[glynor]

Right.  MC doesn't particularly care where the media files themselves are stored.  That's the beauty of the database!  I have a Server copy of MC that runs at the office that doesn't have ANY local files (it is in a VM, in fact, with very little local storage outside of room for Windows and MC).  All of the content in its database lives on various SAN locations on our corporate network.  I have a bunch of different shares added to Auto-Import via their UNC paths (I don't know exactly how many right now, IT keeps rearranging my shares because they're big, I think).

One tip, though, if you go this route... Add all the files to MC via their UNC paths (\\servername\share\path\to\media.flac) rather than via their local pathname (D:\media\music\path\to\media.flac) and it'll work better.  The reason is that you won't have to muck about with drive letters and mounted network shares to make sure all the pathnames match on the client and server.  Plus, if all the machines are on the same LAN, then all of those files will be treated as Local playback (and won't have to be streamed), assuming that each box has permissions to connect to the share (they all use the same username/password, or you ensure that all users have read/write access to the files and shares in question).  The terminology can be a little confusing, but by "local" in the context of this option, it means "can the client get to the actual file via the same exact path that the server uses to access it?"  Network drives and UNC paths, if they're accessible (and named identically), count as local in this context.

The option to play local media if one matching is found is enabled by default, so you don't need to worry about that.  You will want to enable authentication (to allow tagging changes to propagate back to the server from clients), though.

So, if you add the media to your Server via UNC paths (even to "itself" for content that actually lives on the server box), you'll have good results on the clients (which will be able to access the files via the same exact "path").

So you're aware, though, even without "locally matching files", the Server will stream the files that the client can't find "locally".  This is handy for playing files from your server on a laptop when you're "on the road" or whatever.  It works way better with music than it does with video, currently.  However, this will cause all of the "streamed" content to be transcoded before playback, which causes some latency, and impacts seek performance (you have to wait for enough of the file to be streamed in before you can seek substantially in the file, in many cases).  To have this feature work outside of your home Firewall, you will need to open the port to the Media Center server.  Also, even inside your LAN, you might need to open the port on the Windows Firewall if you have that enabled (or any other software firewall).

All of this stuff is configured via: Options > Media Network.  The important stuff is:

Options > Media Network > Authentication: Enabled
Options > Media Network > Client Options > Auto sync with server: Enabled (turn on for each client, though I believe it defaults on, but check it)
Options > Media Network > Client Options > Play local file if one that matches: Enabled (is by default)

The stuff under Client Options is client-specific, so it doesn't matter what they're set to on the Server copy of MC.

Then, on the server box, enable Auto-Import, and add all those same UNC paths to the Auto-Import watched folders list.  It can handle UNC paths just like it handles any other drive letter.  If the box that serves the file is down or missing, Auto-Import will just ignore it until it comes back to life (though those files will be unplayable during the downtime).  However, make sure that you don't change the default Fix Broken Links setting in Auto-Import to anything other than No or Yes (Protect files on missing drives) (the default), or it'll remove the "missing" files when/if the host goes down.

[EricTheBlue]

Great information Glynor: Thank you!  I do have one question though about authentication.  If I'm only playing media within the my local LAN at home, is client authentication really needed?  Note that I will set up some access control between clients and the server media shares via Windows share permissions.  If I ever decide to ever stream content remotely to a MC client in the future, then I would absolutely enable authentication but again, is it really required for local access only?

[MrHaugen]

Yes, it's needed. If you want to sync stats from client to the server. That is stats like play counters, last played date, bookmarks and so on.

[glynor]

Yes, it's needed. If you want to sync stats from client to the server. That is stats like play counters, last played date, bookmarks and so on.

Also, client copies are only granted read-only access to the database if Authentication is not enabled.  This means that all tagging changes made on the client-side (which it does allow you to do, unfortunately) are lost when you disconnect/reconnect or resync the Library.

That's, in most cases, not acceptable if you want the clients to be useful and full-featured "members" of the system.

[glynor]

I should note... The authentication requirement is not dire in any way.  MC handles this pretty seamlessly, except for on WebGizmo (for which, it can make using it on iOS more challenging, but there's JRemote for that in any case).

Client copies of MC just have to provide the username/password once, the first time you connect to a particular server.  After that, they remember their username and password, and never bother you again, unless you change servers or change your username/password.

The only problem with WebGizmo is that the server uses simplistic htaccess style authentication, which causes iOS to not offer to remember the username/password entered.  As soon as your session expires (usually something like 24 hours, but JRiver folks would have to chime in on the details), you have to re-authenticate to load the pages.  This isn't a problem on desktops as Firefox and Chrome (and probably others) can easily be set to remember htaccess-style authentication credentials.

But iOS's Mobile Safari does not.  It allows you to "save passwords" for most normal usernames and passwords you encounter on the web (including the Interact forum credentials, and anything else where you login on a page with a form).  But it does NOT remember, or offer to remember, these htaccess-style passwords.

So, that's really the only issue with enabling authentication, as I see it.  If you are concerned with the client copies of MC being more difficult to use, this is not a concern.  My wife doesn't even know that MC has a username/password system of any kind.  She's never had to deal with it, nor even seen it, and I've been using the server system for years now.