Are there specific reasons that I would want to use multiple servers to host my content? Are there specific reasons to NOT do this?
What if I were to host the same content on both servers but one has lossless rips and the other used transcoded files that were much smaller? Would that potentially be useful if I were to provide remote access to only one server?
I’m trying to understand the various use cases that might be out there for multiple servers to understand if it might make sense for me to spin up a new one. Or two. Or whatever. I have a virtualization environment and can easily add server instances to it for something like this if there’s value.
If the virtualization environment you have share the same CPU pool then I can’t see why it would be of much benefit to have that. I know that there exists some 3rd party solutions regarding distribution of and using several servers together, but none work perfectly. Main issue is that Plex uses SQLite as its database (afaik). So, I’d recommend assigning as much power you can spare from your CPU(s) in that virtualization enviornment to one Plex server - that way you would not get any issues with viewstates and so on.
Having two copies of the same media, one high quality BD-remux or such and one low quality, is still a good and viable option with one server so as to avoid transcoding.
Thanks for the reply.
Why is SQLite a “main issue”? Issue with regards to what? Is this in reference to replication of information across servers or something different?
How do you store multiple copies of the same content with different resolutions so that they are leveraged properly? For example, I want remote viewers to be limited to 720 and I can create those files easily enough. But how do I ensure that Plex uses those versions for remote connections while using the full 1080 versions for local?
I’m also looking at using VPN between two locations, and it seems that Plex sees these connections as “local” instead of “remote” and that interferes with transcoding settings. Since I want to centralize the control of resolution for these clients, it would seem easier to spin up a new server instance where I can have different streaming settings. No?
Whether the virtualization environment shares CPU or not (I have multiple physical servers, so I can separate them) seems less important in the scenario that I’m thinking of where I simply want unique controls for streaming on that server.
SQLite is a nifty, and quite powerful in its own rights, database management system - but it is not suitable for being shared amongst servers in such sense as you want it. If you have two servers, you will have two databases - and all users will have to maintain two viewstates. If user A watches Movie B on his phone from your Server C, and then gets home to his HTPC and wants to watch said Movie B - but from Server D that holds the high quality copy - it will not know where that user left off. As I said, there are 3rd party tools that try and fix this (exactly how - I do not know, just that they have not worked perfectly). Plex are aware of the limitations that SQLite gives but it is not an easy task to change such a diverse environement to MySQL or other.
https://support.plex.tv/hc/en-us/articles/200381043-Multi-Version-Movies
Multiple Versions of the Same Movie
You can gather multiple versions of the same movie together (that have different resolutions or encoding formats) and collapse them to a single item. For example, you can have 3 versions: ones suitable for a mobile phone, a tablet, and a 1080p TV. The multiple versions will be collapsed to a single item in the library. When a Plex app goes to play the collapsed item, it will automatically request and play the most suitable item by default. Many apps will also allow you to select a Play Version action, where you can choose which version to play.
I’m familiar with SQLite and its uses, as well as some of the limitations. So, your comments make sense to me. It would be great if there were an option within Plex to change the DB to something that -isn’t- serverless so that multiple systems could connect to and use the exact same db so that things could be shared across servers. I suspect that the number of deployments that use multiple servers is small, so this likely won’t get any traction anytime soon.
Thanks for the note on how to store multiple resolutions of one piece of media. I guess I’ll write a script to start going through my library and creating 720 resolution versions of 1080 content. 
I’d be curious to know if there are still other use cases that would benefit from a multi-server environment.
