They have a plan and they just weren’t going to give us a stop-gap. Now I think they are too dug in, or they feel like after all these years they are really close to their desired solution.
Somewhere there’s an obsessed Plex dev working on this in a room full of pee-jars, losing their mind like Leo in ‘The Aviator’.
“SHOW ME THE BLUEPRINTS.” ![]()
This topic feels more like its a forgotten line item in a list of legacy bugs than something anyone is obsessively trying to fix. But I would love to be wrong.
I think they don’t want the server operator to be able to remotely enforce bandwidth conditions for users (which does seem appropriate).
What I don’t see any issue with is a server-suggested default at library setup, where the user gets to choose their quality setting as a server-user through-relationship.
This is pretty bang-on. Their solution (WIP ~2y) is automatic quality adjustment, which relative to a config ask is enormously overengineered. That’s the first kind of work item that gets indefinitely sidelined when you are moving engineering stuff to backlog in order to complete investor-track features on time.
While a forced enforcement doesn’t make since being able to set the default wouldn’t change the client capability to change that default. If a default is enforcing bandwidth condition is not appropriate, they are already doing that by defaulting to 720p.
What I, and I assume other administrators want is just the ability to default to direct stream on client install, if that client doesn’t support direct stream it can fall back to w/e quality (extra points if they make this fallback configurable). The client/user can still be like nah, I want to stream my movies at 480p potato quality. If admins don’t want that they can use current workarounds (tautulli/nginx magic).
I think this is annoying to so many admins because we just have to live with plex’s defaults rather then being able to set our own. Why does plex have final say over OUR users?
Plex’s current solution has taken 2+ years and counting. The proposed request should probably take a 10th of the time (or less), they could still develop this overengineered solution, and release it when its ready without the hundreds of users in this thread hounding them about it.
Oh we’re on the same page — This reads almost exactly like the very first post I remember making in this thread . The part it’s especially nice to see other people echo is that Plex is overreaching, forcing a terrible default, and simply refusing to fix it.
Because they are not your users?
Hint: they didn’t go to www.xarin.tv to sign up for their account.
Plex’s defaults are stupid, but that doesn’t mean you should get to control someone else’s Roku/Fire Sick/TV set.
Being able to set a default for a specific plex server is quite a bit different then “controlling someone else’s device”, all software sets defaults…
Plex is acting as an auth server, that doesn’t make them not our users when they are connecting to our self hosted service. If your company lets users use amazon/facebook/gmail/etc. to login to your app, do you say they are not your users?
What if your idea of what the default should be is higher than what the user wants to use?
Plex’s services are usable without your specific server existing. In the case of Federated Identity providers this is not true (signing in with the Facebook option would do you no good if Plex’s servers were down). Your content just happens to be an additional option in this case. A more apt metaphor is online gaming. Just because a friend is playing a game you are acting as host on doesn’t mean they are not XBox’s users.
Its just a default, the user can still change it the same way they change it now?
Why wouldn’t it, if plex implemented that correctly the user would be able to auth, and connect to my server I’m hosting/exposing to the internet? I can already whitelist ip’s that can connect to my server without auth, and plex in house services don’t get involved at all.
Because that’s not how federated authentication works. It’s just Facebook/Google/Apple/etc sending a message that the person connecting has proven they really are David Jones to them, so Plex can move on believing they are without their own authentication. It doesn’t cover anything on Plex’s end regarding their gloried DDNS so they can find your server on the Net, the authentication of other Plex users to a given user-run server, content restrictions/language preferences, the Ad-supported TV and Movies, Watchlists, etc, etc.
if plex implemented that correctly the user would be able to auth, and connect to my server I’m hosting/exposing to the internet? I can already whitelist ip’s that can connect to my server without auth, and plex in house services and don’t get involved at all.
The authentication system is still on Plex’s end. Management of users, etc is all remote. When you allow unauthorized local access on a device all you’re doing is saying this device can connect without any restrictions in a local net. It’s not really a form of control. Managed users not working on it shows this.
You’re not going to be able to rationalize this idea you’re the “real admin” in some way as long as people are having to agree to a EULAs with Plex to open an account, and you have no real user management on your own personal iron. If you truly want that you’re gonna have to switch to Jellyfin. All we’re asking for here on this feature request is for Plex to stop installing clients with a low bitrate limiter enabled. Any further changes are outside that scope.
All we’re asking for here on this feature request is for Plex to stop installing clients with a low bitrate limiter enabled. Any further changes are outside that scope.
It seems we are going in circles, that was the point of my post, all I’ve been asking is for plex to give us an option to set that default nothing more? The client can still change the setting to any thing they wish.
You said plex was more then an auth server and services wouldn’t work without the plex backend, but they do… Plex does offer proxy services to make it easier to find your server, and recently-ish they started hosting content on there end, but neither of these are required to get a working plex server.
This being the case my/our users seems more apt then a video game service that requires a full backend to play together. I can currently expose a port, whitelist an IP, and “my” users can see my content. Just because plex hosts the MITM auth service it doesn’t make them plex’s users.
I’m not looking for a “real admin” experience, I’m asking for one configuration option to help facilitate users accessing my specific server because plex is never going to be able to pick a single default that is going to work well for every plex server admin. This in no way would take power away from the user to change it to what they prefer.
It seems we are going in circles, that was the point of my post, all I’ve been asking is for plex to give us an option to set that default nothing more? The client can still change the setting to any thing they wish.
You’re asking to be able to define the default setting on your side (the server), when the speed is a client-side control.
You currently have the ability to set an upper limit on streaming:

But you have no way to define a standard speed the client will follow. Does the client even support the ability to recognize a bitrate speed defined by the server (beyond the one determined for direct play/transcoding)? Does the client have the ability to recognize these limits on a per-server basis? Probably not on both questions. To allow a normal speed set by server owners requires a reworking of all client apps, otherwise we get “what happens when a person is connected to multiple servers? Which server gets to set the rate?” which DaveBinM has brought up earlier in this thread I believe.
All Plex clients are connected to one server when they are first installed (Plex Movies & TV), any user-run server added and we hit this “multiple server” situation.
While I know what the very first post on this topic asks, this thread is at this point really asking Plex to change the default config on-install of clients to use the “Maximum” setting, and then users can reduce this if they wish. It is not asking for any reworking of clients, advanced configuration options, or server-side controls. Asking for a change in default client config is a MUCH more attainable goal, because it requires zero work on Plex’s side. It’s just a simple value change. But the effect is the same:
- No more issues with servers transcoding unnecessarily.
- Higher quality streaming for users.
- No more hassle for server owners and users having to get client configuration changed after a new/clean install.
And it avoids the issues in the original feature request:
- Development/support for a new Plex client feature.
- Development/support of an additional (if minor) feature on Plex Media Server.
- Questions of authority/relationship between users and server owners sharing with them.
Edit: Also, regarding your wish for a server-side control, what happens if the server owner’s set “default” is higher than the user’s idea of a “maximum”. Should the user still be able to stream, transcoding if needed for bandwidth constraints, or should the server simply deny them access until they change their settings? Half the reason for this original feature request is server owners running low-power servers getting bogged down by remote users transcoding. Keep in mind this could become “I can only stream on wi-fi and mobile data will not work” when it comes to mobile clients, since those are two separate speed controls. This is getting kinda complicated, huh?
And it avoids the issues in the original feature request
To be fair to me, the title of the feature request more accurately describes what I was requesting ![]()
What if your idea of what the default should be is higher than what the user wants to use?
Then the user can change the setting.
The point is, most end users have no idea about the setting. If they do they can still select the quality they need.
Personally, I see two separate groups of PMS owners that want this default changed.
- The My server cannot handle hardware transcoding in the slightest/I don’t like Transcoding
- The 720 is a crap resolution and no one likes it.
I think Plex is moving in the right direction with the Convert Automatically option. But that depends on the PMS being able to transcode efficiently. To that end They are working better hardware transcoding support for things like the NAS devices like Synology. If they are going that route to make Convert Automatically the default and let the Client and PMS server deicide the best, then the default remote quality is irrelevant. They would also need to add better handling of PMS owners that do not want transcoding to happen at all.
note: this is only my speculation/opinion.
What if your idea of what the default should be is higher than what the user wants to use?
They have the freedom to decide if it’s worth the bandwidth. They aren’t customers, we are sharing our personal libraries and legally we can’t charge anything for that (obviously).
So if someone borrows a DVD and they prefer it to be more scratched than it currently is, fair game?
hey have the freedom to decide if it’s worth the bandwidth.
My question was more “what action should the server take?” Is the speed the server requesting the player use a required minimum, or a “preferred”? I’m bringing up all the complexities this feature request (as it is originally written) entails verses just changing the default quality setting to Maximum with no other changes.
Oh I see. For the past several years this thread has been going many of us use Tautulli scripts. I think standard practice is to stop transcodes when the reason is their quality setting with a message explaining their options and how to fix it. You can apply that per-user and have exceptions like mobile data, which works great. When the transcode reason is something other than the quality setting, it doesn’t get stopped. HEVC 1080p to AVC is all good if a device needs that. Some cheap Roku TVs need 1080p h264 transcoded to 720, that’s disappointing but acceptable and it passes.
Yeah this touches on another painfully pointless rigidity, which is that you only get to set one maximum bitrate and it applies to both direct play and transcoding uniformly.
You can’t provide the option to direct play stuff up to 20Mbps bitrates, for example, without being forced to beam every single transcode at 20Mbps as well. The consequences of this are a lot more plural and thorough than just this.
There’s no reason this should ever be a dilemma, as implementation-wise it’d LITERALLY video decision: transcode → use transcode limit instead of natural limit.
Almost every needless frustration/limitation with this platform comes from the same unhinged commitment to providing neither configurability nor reliable automation, and instead making an absolutely garbage decision for you either as a default or as something you’re irrevocably locked into.
^ I would make a feature request for this, but knowing better by virtue of having been around for almost two years now, I think I’ll just make a third-party shim that people can use or some Tautulli plugin or something.