PlexOS

Ok, so this might not be a hot request, but here we go…

I believe, with the direction that PMS has been moving over the years, that it would be incredibly beneficial to do a ground-up Linux distro built around the Plex environment (much like steam did with SteamOS). There are a number of feature requests that are currently heating up that center on the concepts of server management, server communication, LAG/LACP, master/slave relations, server administration, unified server clustering, dynamic transcode terminals, load balancing, stream cap mitigation, user logging, server usage state syncing, sharing optimizations, client control, and controlled testing labs.

If Plex were to move either toward more server friendly plug-ins & programs for server/virtual environments (CentOS, Windows Server, Hyper-V, etc.), it would be a tremendous boost of support for quite a few power users that I know of. If Plex were to move more towards BEING that server environment (or at least being heavily integrated into one, not asking you to reinvent the wheel), that would go a much longer way along all those veins of discussion than individual updates could ever hope to achieve.

TLDR;

What I’m essentially proposing, is that PMS ceases to be a media serving app, cocoon itself, and metamorphosize into the fire-breathing-death-dragon-puppy that is “PLEXos, the mildly mortiferous mega magnanimous medium of multi-media”…forgive my elongated bantering, I’m a budding morosopher :#

Cheers!

~P.S.~ Please note, I do know what I’m asking. Not exactly an “easy kill”. But there are a number of ways you could do it without changing too much of the source code you’ve already built up. Simply having a unified GUI’d Management Server would strip a lot of dev out of having to rework what’s been set in stone.

While a full PlexOS would be handy, the the current Windows/Mac/Linux PMS programs should still be supported. A good amount of users with PC-based PMSes also use them as gaming computers.

I’m not advocating for the removal of the current life of PMS. I’m looking more for the capabilities that would come from the ability to scale. If you have, say, three older computers that don’t really do anything in your garage, why not be able to throw a GUI-less light operating system as slaves.

An example of what this could provide in the situation where you have those three older computers to use to augment your media server:

Master == This is the administrator of other servers as well as user/plexpass authenticator. This will possess the GUI for simple management and assignment of tasks to slave servers. This server will serve as update portal, media portal, load balancer, directory, and auditor. Metadata and viewing stats would reside here. Unification of types of media libraries would be virtual and managed at this level (~i.e.~ MovieLibrary<-MovieLibrary1&MovieLibrary2)

Slave_Spare_Comp1 == No GUI; Long-term media storage; Movies and/or TV shows that have been transcoded and/or commercials removed; Generation of thumbnails and other scheduled tasks are completed; Failover for Slave_Spare_Comp3’s long-term storage transcode operations; Failover for Master transcode/media serving

Slave_Spare_Comp2 == Short-term media storage; Movies and/or TV shows are recorded and stored on here awaiting transcode and transfer; Failover for Slave_Spare_Comp3’s long-term storage transcode operations

Slave_Spare_Comp3 == Backup and Cache; Movies and/or TV shows are transcoded for long-term storage; Master setup config backed up; Photo backup; Highly rated/synced content backup; “On Deck” cache; high usage media cache; optimized version storage; Failover for Master transcode/media serving.

That’s just an example usage scenario that would allow for cheap expansion of the current capabilities of PMS. There is SO much more that could be done, however, and would seriously allow Plex to destroy upstart competitors. By uniting their media serving platform with an operating system, Plex would have the capability to compete in the hole left behind by Windows Media Server.