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.
@RyanGoslingsBugle points out that including “sd” is necessary in order to capture Android mobile clients, since they report their stream metadata differently.
@Brando47 suggests using
Quality Profileinstead ofVideo Resolution, and demonstrates implementing a softer kind of stream interruption.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 thekill_stream.pyscript from JBOPS.

- In the
Triggerstab, 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
Argumentstab, 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, notA > 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
- three months ago,
- 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!