Default All Clients to Max Internet Streaming

I legitimately hope I am alive to see this update rolled out.

1 Like

I wonder which comes first:

  1. This bugfix goes live
  2. George RR Martin releases Winds of Winter.
6 Likes

2 for sure

A Dream of Spring will surely be released before the solution to this issue. :stuck_out_tongue:

1 Like

lol, someone a while back said wwIII would start before they fixed this… well here we are

2 Likes

With the settings constantly getting reset(Edit… as others have mentioned Rokus settings keep resetting), I have had to resort to turning off the transcoder and telling my users that if they cant play anything or figure out how to, just go ahead and uninstall plex. Sad that it has come to this

Yeah, this is the single biggest issue. No matter how many times you ask somebody to fix it, Roku updates just keeping knocking it back to default. Literally everyone thinks to lower settings if you’re getting buffering, but nobody thinks to check and raise the quality. I just really wish they would fix it. It feels like they do not car about their subscribers. Honestly, if there were a decent alternative, I’d be jumping ship over this one.

And what people don’t realize is that too many transcodes can be the real source of their buffering, so more people lower their settings, and it makes things worse for everyone, not better. They’ve got to fix it.

5 Likes

This.

This is basically it. The arbitrary default settings makes things worse for everyone.

7 Likes

Here’s some help so you’ll never have to do this again, nor be held hostage by ongoing neglect —


I use Tautulli notification agents to detect certain stream conditions, and then kill the stream (by calling JBOPS script) with a helpful custom error message that gets propagated to the user in the Plex client itself.

My use cases are e.g. (of course) Plex-imposed default quality, unnecessary transcoding b/c of browser playback instead of app, etc. — things that detract from technical-need-based transcoding workloads.

And like @cwestemeyer mentioned above, yes, any given Plex client app’s updates regularly (to me, every 1-3mo constitutes “regularly” here) reset the previously fixed setting back to the unjustifiabl(e/y) imposed default — so you can make this a non-issue for yourself & everyone else too.


Here’s how:


First, start by creating a notification agent in Tautulli (Settings > Notification Agents).

I can establish some conditional logic for ~deducing that a stream is using the Plex-imposed quality default — bitrate golfing is a trap here; just start with media sources that aren’t already 720p.

I know the conditions below aren’t logically perfect, but they will perform their role.

You will not suddenly drop dead when the first thing your aunt watches after setup is your PAL DVD backup of some weird Slovenian claymation from 1958, which happens to trigger one transcode (and you — insofar as entertaining possibilities like this).

Personally, I just need to wall off Plex’s default, prevent 1080p->downward transcoding, and may as well account for a few edge cases in 720p/SD media (like container compatibility).

Your media & users’ needs might require more detailed conditions than what you see above.

Looking in Tautulli’s logs will give you a clear picture of expected vs. actual outcome when evaluating conditions.


Next, we’ll use the Configuration, Triggers, and Arguments tabs to decide what happens if the conditions we established are met — we want to kill the stream, and propagate a helpful error to the user.

  • In Configuration, point Tautulli to a chosen folder path (make sure it has access), and specify the kill_stream.py script from JBOPS.


  • In the Triggers tab, you’ll need to check off the event types that are relevant to what you’re doing. In this case, it’s the same ones as in the next step’s screenshot.

  • In the Arguments tab, specify the command-line params you’re passing to the kill script. Here’s mine:
--jbop stream --username {username} --sessionId {session_id} --killMessage "It looks like you need to change Settings : Quality : (video quality) to Maximum! If this is a false positive, please let me know."

You’ll need to put this in each of the highlighted event types (and, again, make sure those events are checked off in the Triggers tab).

There are two important things to remember when writing out your message:

  • avoid single apostrophes (Python will think it’s a string delimiter; script will break)
  • HTML chars won’t get escaped in display (-> e.g. A : B : C, not A > B > C)

That’s literally it! Now go pop Plex open and set either your overall quality (or just that stream) to the default hellsetting. Here it is one last time so you can say a proper goodbye, because you’ll never have to care again: 720p @ 4Mbps

And, boom!

  • the unnecessary transcode never happens
  • That Annoying Conversation we’ve all had to have 99999999 times never happens (hell yea)

and — with equal importance! —

  • the person watching never has to feel frustrated or confused at any point,
  • or like, feel dumb for not remembering something you mentioned once,
    • three months ago,
      • that they shouldn’t even have to do in the first place
  • they just get a quick helpful reminder, and they’re back to watching in 10 seconds!

Congratulations! You can now stop coming back to this thread out of desperate hope, and instead do it way less often out of morbid curiosity just to see what happens with low-effort but high-impact fixes that don’t have quantifiable ROI.

Enjoy!

3 Likes

Also, now I’m just laughing — when I first found this thread, @kegbeach told me I was basically dumb for crying about the issue of this default, because you could do this exact thing in Tautulli and walk away.

I argued with him, because to me, Plex shouldn’t be making this decision for us in the first place (let alone a choice so absurdly and impactfully wrong). Any approach I could think of that didn’t solve that problem seemed to suck too, and if we started celebrating a 3rd-party solution instead of Plex cleaning up a problem they didn’t have to create in the first place, then it would never get fixed, right?

The polite way to summarise my attitude now is that “the passing of time has refined my perspective”. Nobody believes harder than a convert, I guess.

2 Likes

Have you tested this solution with mobile clients? Because it doesn’t seem to kill the stream for Android app users in my testing.

EDIT: It appears the Android clients don’t report stream resolution the same way as the desktop client, adding ‘sd’ fixes the issue.

1 Like

Oh good find! I hadn’t needed to map out mobile clients’ tells; I’ll edit your findings in with attribution.

At least I don’t need to redo my screenshots.


Reminds me — for those new to Tautulli, or anyone having a tough time getting trickier conditions working, Settings > View Logs will show exactly how they’re being evaluated.

Look for the wall of True/False/pipe characters:

Cyan is the conditional expression for testing the property; green is what value the media/stream actually has for that property.

If something you’re trying to match on doesn’t seem to work, this will help you understand whether you should be expecting a different value, or it’s fine and something else must be the issue, or you should be checking a different property entirely, etc.

If anyone wants a slightly less black and white solution to this, I’ve been running a sort of compromised version for a long time with a custom script. It will only cancel the stream once per day, per user, per device, i.e. it just becomes a nuisance/reminder rather than a restriction, a user can simply restart the stream and continue about their day - it makes it possible if someone actually needs to use a lower quality profile. It also has a whitelist feature to selectively allow some users to use lower quality profiles. It wouldn’t be hard to modify it to have an additional blacklist that will force the restriction, but I haven’t needed it for any of my users (just a niggly reminder is usually enough).

You’re welcome to download it from here. It’s setup with a /scripts folder in a docker container volume mount in mind (but can be modified in the script - should be obvious enough), and just calls the JBOPS kill_stream.py script ultimately so you need to have that in the folder too. it also requires you to put {datestamp} {user} {player} {session_id} as the script argument.

The only other differences I have (not that they are breaking changes) is I use ‘Quality Profile’ instead of ‘Stream Video Resolution’ and ‘Transcode Decision’ and just set that to ‘contains 720p’ (same end result I think). And then I also do a check for ‘WAN Bandwidth’ that it’s below about 2/3 of my total upload capability that I have set under Remote Access in Plex itself, as Plex will start enforcing transcodes once you get close to using up your full upload bandwidth, and it’s obviously pretty frustrating for users to have their streams cancelled in that scenario.

Most of the differences are useful for my setup being in Australia and having ■■■■■■ internet, both on my end or the client’s end, so probably not useful for everyone but you get the idea.

2 Likes

I may have been abrasive before and that’s out of shared frustration. I apologize.

It may not be the perfect fix but it does help with sounding like a broken record to our friends and family…

1 Like

What am I missing here?

  1. Tautulli can override a Plex dumb default setting?
  2. Tautulli can kill a stream caused by a Plex dumb setting?
  3. Something I’m clearly missing the full discussion of?

I will assume it’s not the second one…That’s just too laughable to even be mentioned. So I know it can’t be that.

Edit…950+ posts is a lot to read to find what’s actually being discussed in this particular case.

Nah all good; there was no way I was going to understand your perspective without having seen the long-term tendencies first-hand. I totally get it now lmao.

And yeah, holy ■■■■ is it ever relieving. It’s impossible to properly verbalise how uniquely stupid and uncomfortable That Annoying Conversation is.

It’s indeed 2. Tautulli can kill a stream caused by a Plex dumb setting, + bonus & use the error message sent to the user to remind them how to fix it.

If you’re curious, I wrote out a summary + walkthrough in the post directly above what you’re quoting.

Silence. lol.

Is this stagnation as embarassing for Plex as it is for me to still be a paying customer?

3 Likes

This unfortunately only works for Plex Pass users :slightly_frowning_face:

1 Like

This speed test report shows that the average internet speed in many countries is more than enough for Plex to make that change safely. If their analytics still says that users are transcoding because of slow connections, perhaps their algorithm is broken.

2 Likes