Well the problem I see with that is that Plex uses the 32400 (or what ever port) to “advertise” what URL to access it self from the outside. You can only have one SSL going to a server from the WAN.
So how are you going to do that?
Maybe a group of static IP’s?
Maybe Plex devs allow single user account to resolve multiple public IP’s in the Plex environment?
I think the only way would be to develop a PMS dedicated load balancer that could be exposed to the internet on port 34200 and it would direct the traffic to specific internal PMS machines based on client requirements and current resource usage.
+1 I need this !
+1 using PRT Right now to do 2 transcoder nodes but would love native support
@Monsters_Grin said:
I think the only way would be to develop a PMS dedicated load balancer that could be exposed to the internet on port 34200 and it would direct the traffic to specific internal PMS machines based on client requirements and current resource usage.
They could have the main PMS do the load balancing.
@boboki said:
@Monsters_Grin said:
I think the only way would be to develop a PMS dedicated load balancer that could be exposed to the internet on port 34200 and it would direct the traffic to specific internal PMS machines based on client requirements and current resource usage.They could have the main PMS do the load balancing.
Yeah, but that way you would need at least one full fledged Plex Server constantly running.
I think that if you’d run the “load balancer” on a low power machine that could wake up servers on demand, you’d kill two birds with one stone 
.
Sure, this is doable with docker I would think… Have the one always on PMS, which you have anyways… then be able to spawn a bunch of virtual machines within docker to do transcodes, giving you unlimited scalability if needed on demand.
Docker is unnecessary in this case. Just adding another layer of complication where it is not needed - unless you have and afford a cluster that runs 24/7 anyway - in that case I envy you 
.
The same with one always-on PMS - not needed. The load balancer machine should be on the front, taking the connection from the users and determining their needs, and just being able to wake up baremetal systems that would then serve the users.
Yes, that would mean the balancer has to have all info about the media on each server and perform the assessment of the client machine capabilities and settings, and waking up an appropriate machine based on the current load and need for transcoding or just direct play.
I’m thinking about doing something simpler for now - I want to put the PMS on a desktop I’m about to buy, and have a RPi serving as a wake-on-lan agent for the users - automatically waking up the power hungry machine when needed.
Docker is irrelevant – that’s merely a nicety for management of the app at deploy and runtime. What we really need for this to work is for Plex to break out their transcoder along with a small, specialized client that registers with the server and listens for incoming transcoding requests.
TBH it wouldn’t be difficult to do, but as an operator you would need to ensure all of the machines running transcoders have performant access to the media. What’s more, you’d need to either proxy all the requests through the server directly, or forward a port for each transcoder.
And SSH session is plenty enough to be able to send transcode jobs via blocks if you wanted to. I think that is how PRT is doing it now, however since there is little to no support from the plex team, reverse engineering is what those guys are down to trying to figure things out, that and every release Plex changes something in their codecs or breaks something else.
There are TONS of ways to get this done, real PMS load balancing via encrypted tunnels to each PMS transcoder slave, distributive CPU pools where the slaves just share their CPU pools outright (think like SETi does), hypervisor based pools, just tons of ways this could work.
We have plex running on a pretty under powered NAS and for the most part it’s fine as I pre-transcode most of the big stuff to 720p etc giving user the choice of either full HD 1080p but if that won’t stream there due to there connection, there is a 720p fall back - however for the odd time when transcoding is needed it would be great if the PMS could call on the horse power in some thing like an Nvidia Shield (we have sat under the TV - connected on LAN). There pretty cheap, can do other fun stuff and for such a little device pack plenty of horses under the hood.
Yes I know I can move the PMS over to the Shield but there is no way of moving all the libraries and would request setting everything back up - my life is short enough!
After reading through this multiyear there a couple things are the same and a couple things have changed.
- People still use low powered NAS units for Plex Server
- Over time, more and more streams are added
- Over time, higher res. transcoding is occurring.
The availability of more powerful processors brings a question for others to ponder. If we can assume this is for home use (ie no hotel scenarios) and If we can assume you are running a 10TB+ collection with say 4+ concurrent streams (1080p or 4k), is this not beyond the designed functionality of said (drobo/synology/10yr old desktop) box? As time goes on and people have kids, do they still keep coupe or get a larger vehicle for the whole family? Why not pickup a more powerful box that easily handle the load?
I use to have a small NAS box that fell over when trying to handle multiple 1080p streams, the box got replaced with a used server for a couple hundred (ie less than the cost of less than the cost for a pair of 6TB Red’s).
I think like many of us we come to Plex after we have purchased the NAS not realising the likely need or even understand transcoding etc. We learn and then create solutions to deal with low power CPU but feel than having a solution which would allow the PMS to utilise a more powerful CPU on the network - i.e. a desktop or Shield without the need to try moving the library (which from reading is only compatible if the new server is running the same operating system) or going through the pain of setting up PSM on another system as loosing all your user information.
It’s just a nice option to have before the time comes to invest in more horse power.
@Patrick_ said:
After reading through this multiyear there a couple things are the same and a couple things have changed.
- People still use low powered NAS units for Plex Server
- Over time, more and more streams are added
- Over time, higher res. transcoding is occurring.
The availability of more powerful processors brings a question for others to ponder. If we can assume this is for home use (ie no hotel scenarios) and If we can assume you are running a 10TB+ collection with say 4+ concurrent streams (1080p or 4k), is this not beyond the designed functionality of said (drobo/synology/10yr old desktop) box? As time goes on and people have kids, do they still keep coupe or get a larger vehicle for the whole family? Why not pickup a more powerful box that easily handle the load?
I use to have a small NAS box that fell over when trying to handle multiple 1080p streams, the box got replaced with a used server for a couple hundred (ie less than the cost of less than the cost for a pair of 6TB Red’s).
The problem is not necessarily low-powered hardware as scaling vertically (building a single powerful server) is always more expensive than scaling horizontally (building several lower powered servers on which the load is distributed).
There’s a reason why the entire IT industry does it this way.
I can only speak for myself; I am currently only able to share my PMS with my immediate family since my NAS (Intel i3-4370 - 4 threads @ 3.8Ghz + 16GB RAM) can only handle 3-4 consecutive transcodes.
I would like to invite friends to use my PMS, but I just can’t handle that load.
Granted I could build a new system using either an AMD Threadripper or Intel Xeon (even multiple socket setups) processor, but that system would still be limited to a finite number of consecutive streams; this is not a long-term solution.
I’ve read a lot of people’s opinions in this thread stating that there’s no need for PMS to be able to handle such load; for a great many people, that is true, but it’s not true for all of us. Just because a solution works for 1 person does not mean that it works for all people.
I agree with many people in this thread in that people should not be selling subscriptions to others to use their PMS… I am not supporting that.
I am however supporting the idea of being able to leverage additional horsepower already in ones home to increase transcoding capacity of a PMS to allow for the sharing of that PMS with friends and family.
Horizontal scaling is not a new idea, it’s been the standard way that most of the industry handles large server loads.
1 Like
People must keep in mind, those of us with large families, and households at anytime can easily have 10+ transcodes going on. “Buy a bigger processor” is not always the best or cheapest route to achieve what is wanted, and with 4k/8k out that cpu demand has skyrocketed. Few single boxes under a few thousand dollars are going to handle multiple 4k transcodes at all, much less 5 or 10. As quality of video continues to scale, our current solution here does not.
Why should we try to buy some quad socket e5-2699s or something when I can get 4 single proc servers (or 2 dual proc) for half that cost? Or why would someone not want to just add a transcoder box to simply scale out their current setup, quickly and easily instead of having to try to completely rebuild and migrate their current system and all associated 3rd party apps? If someone has a Synology DS1515+ and it is hosting their PMS and a few other things why not allow them to have the ability to add a slave to take care of their transcodes if they decide to share wither their family or a room mate?
You do not dictate what options you give your customers by what they COULD be used for. You have terms of service and EULAs to dictate that. If Plex was to go by this philosophy for everything, it would not exist at all as anyone can host pirated materials or try to sell access. While yes, I will 100% agree having the ability to make a easy to scale out system means that people could have a easier time trying to setup their own ghetto pirated netflix, that should not be Plex’s concern or worry at any point, and we as a community should discourage that type of behavior, but as stated just because something can be used for a reason is not a reason to not have it in the first place.
edit Lastly, I do want to say, some of us are a LOT more technical than others, and like to virtualize our infra. Options like this allow people like us to be able to create on-demand transcoders from our systems, and scale as we need when we need and even convert these to vapps. In the virtual world just throwing PMS on a system and throwing a ton of CPUs is a huge waste and slows down everything on the system, not only from rdy/wait but also just a massive waste of resources. Work smarter, not harder is typically the motto.
1 Like
+1 for this feature. It’s been around for years in other products (like Final Cut Pro/Compressor) so it’s not a matter of technical feasibility. The feature request has been around for 3 years. I’m walking into this cold. Is there any indication from the Plex team that they’re working on or even considering this?
Currently, nothing from them on this in over 3 years.
They could even enable on device transcoding. My iPad is way more powerful than my NAS and is already running plex. Why can’t the NAS stream the original file and transcode on my iPad? You would want to make that optional, obviously, but I would allow it to happen.
@justflie said:
They could even enable on device transcoding. My iPad is way more powerful than my NAS and is already running plex. Why can’t the NAS stream the original file and transcode on my iPad? You would want to make that optional, obviously, but I would allow it to happen.
Because that wouldn’t make sense - apart from client device performance, transcoding is also a way to lower network bandwidth usage.
