Well yeah years.
Or 17 hours since the last server update maybe.
As someone who runs their whole server remotely and thanks to docker has Plex, Jellyfin and Emby running (just because I can) this particular issue is a non event.
Set nothing in server limitations for bandwidth and the client will happily direct play at maximum quality on my Shield and Roku.
They also said the same thing with watchlist feature on our own libraries that theyre working on it, but it’s already 1 year already, they have not release it yet. I don’t know what’s up with that feature taking so long. Watchlist is already in Plex Movie and Shows.
This feature right here don’t need coding really. They could just set the default to max and boom all server are serving videos to max quality, but they don’t give sht about it either.
Only explanation to me why feature like this and the one I mention above not getting implemented right away…we don’t have choice but wait because we don’t have good alternative for Plex. I know there’s Emby and Jellyfish that we could use, but they’re not as mature as Plex. Plex have all say to whatever feature they want to release…either you stick with them and wait or switch to Emby or Jellyfin.
That’s the reason why we need Emby to mature soon to stir up competition. That’s how devs go work their asz off.
Standstill as in a semi unusable state for 1.5?years+
Not having enough client support and those that are available and i tested are just bad. The webinterface is buggy, the scanning is slow and bad. Metadata download flakes out on large libraries etc etc etc.
I test it every few month hoping to get away from plex.
But plex is still years ahead, the gap did not close, it got wider even though plex inc. spends most of dev time in “other” features
→ standstill 
They do have hw transcode support fr the pi4, which is nice.
I think you are misinterpreting me.
I agree with everything you say and I still only use Plex. I can and do run the others but actively use neither…At least not yet.
However we are talking about a specific issue in a thread about that specific issue.
The point being for this particular issue we are saying Plex is right in the default crippling of remote streams because it’s better?
Or just accepting it cos Plex knows (or thinks it knows) better.
I was replying to someone saying they are hoping jellyfin reaches feature parity soon, which does not look like it will happen anytime soon, or ever.
Yeah the default settings, regarding this issue, are way saner on jellyfin. Agreed.
No worries but you directly replied to me, so hence the confusion.
Personally I prefer the Jellyfin approach of only investing in fairly popular clients.
I know I mentioned Roku and Shield earlier but my go to client is the Apple TV. It’s a complete non event so far in Jellyfin but they are building it from the ground up, so I will give them some leeway.
It’s a subject close to my heart as Plex switch and change between the old player (native Apple TV) and the new player (MPV player). We now have a situation where Plex are deliberately switching back to the native player Apple TV player for Dolby Vision profile 5 in mkv.
All totally off topic for sure but right now it seems Plex have no clear plans going forward.
While Android clients wait for clickable actors images to bring them in line with with Roku, Apple and other devices to give results for a particular library (and that’s been at least 3 years)… that parity will bring them to about 5 years behind ANY other alternative such as Emby, Jellyfin and Infuse that also offer up that have always offered actor clicks regardless of the library being movie, tv or even music.
This will never happen. Trololo.
You replied to me first 
points fingers
Yeah I don’t see clear plans for the atv either, but they have at least plans.
Jellyfin has 0 plans for the atv, since they lack the devs for it
And at this point as the thread falls apart.
What won’t happen 
They’re actively working on it with Swiftfin.
Also I replied to you cos I was taking to you.
You replied directly to me and said you were replying to someone else.
Not that it matters. It will all be what it will be.
@esmarq the room is over to you.
That was a reply to morgedoo, which you replied to me then. still pointing fingers
Thats (good) news to me, what is Swiftin?
Compatibility. They want to make it work for everyone else using your plex server whether they got slow or fast internet that’s why it’s on 720p default.
Like everyone point out it’s not better for those plex owners who has clients capable streaming the videos to the max setting (original quality).
Majority of our users won’t bother adjusting the video quality to the max. Not all our clients are savvy with computer and devices. Do you think your parents, grandparents and friends would explore the setting under video quality if the movie they’re playing has no problems? No they won’t. So the 720p default quality would stay there forever unless you phone every relative and friends you have…to change those setting. Who would do that? Sure I’d do that setting to my parents devices but telling that my other users. hell no. Hence, it’s better for Plex devs to set this thing to max so it would try to play it max first. If it can’t that’s the only time it gets transcode.
A built from the ground client for Apple devices.
It’s in early development because unlike Plex Jellyfin accept they cannot stretch themselves too far.
Honestly if Infuse sort out their UI/UX Plex will be totally dead to me. Infuse innovates and Plex catch up years later or don’t catch up at all.
But while Plex have a UI like UNO and infuse has a truly painful UI then I have to live with both.
At this point I’m lost.
I’m not sure if you are arguing for or against Max quality streaming??
If the server can decide then what impact does that have on the client?
Right now we have both a server and client setting.
The server can be set for one thing and it will not matter in the slightest to the client.
I’m not sure how that can be a good thing.
Just adding my voice. Been watching this thread for over a year.
Please fix this!
@elan @DaveBinM any update on this?
I’d argue that (paradoxically) the longer this feature is in development and testing, the less confidence users will have in it.
Clearly there’s been a lot of unforeseen issues that have come up with it (see Elan’s comment above that this wouldn’t take more than a year almost 2 years ago). I don’t know if it’s because this is an overengineered solution, or the underlying platform needed radical changes to accommodate it (or both).
In any case, I’m willing to bet that the solution of defaulting clients to max, or giving server admins control over the default would have been implemented much faster.
Maybe throw your (paying) customers a bone, and fix this issue already. Then take however long you need to get your optimal solution ready.
Agree; please just offer server operators a field where they can set a suggested quality default for end-clients, and a panel stage during end-client setup to choose quality (with the suggestion as the default for the server).
This will be needed anyway, with or without an elaborate and indefinite-ETA auto-determination feature, and actually solves the actual problem at hand.
At this point, it feels like this hasn’t been implemented out of spite. Hundreds of paying customers (thousands if you look at the subreddit), have been begging you for years, and the CEO just flat out refuses to listen. It feels insulting.
If Automatically adjust quality was reliable and enabled by default I’m pretty sure this would solve the problem.
Yeah, this feels more like a bug needing to be fixed than a feature request. We really shouldn’t have to request a feature that allows streaming video to play at original quality by default, it should just do it.
