It’s all client-side, so the end-user has total control over their experience
2 Likes
No, no indication at all, as it’s held entirely within the client
1 Like
It would be great if the client logged the following to the server (regardless of whether temporary client logging is enabled):
- Bandwidth detected by the client
- Any time mid-playback that the client needed to suggest a different quality setting.
This info would be very helpful for server owners to help diagnose problems with their users.
One other suggestion: it would be nice to have a quality setting between 20mbps and “Maximum”, as many 4K tv shows run about 25mbps - it would be nice to directplay those while still transcoding UHD bluray rips as needed.
Thanks for the work on this!
The client already logs all of that stuff in its logs and is always logging. The only temporary bit is them being available to download. This feature should also greatly negate the need to troubleshoot things like this, but the client logs will have the details if needed. We will be adding more qualities in future, but it’s a little complex due to some tech debt we need to work on
That’s great and all but that is practically useless to the server owner, since in a real world scenario with a technical inept person there is a 0% chance of ever seeing those logs and being able to help. This will just result in unneeded back and forth and frustration on both ends.
Please consider @millercentral 's suggestion, it is very valid.
1 Like
It’s no different to how it is today, with the majority of client-related decisions and actions being logged on the client themselves. We’re unlikely to change this behaviour. Splitting client-related logging over the server and client logs makes things even more complex. The whole point of this work is so that users won’t need help or intervention, and can get the best experience possible on their own.
That’s the issue.
Ideally that will be true.
Client related logging will not be moving to the server. The only times we ever have client logging sent to the server is if it is not technically possible to retrieve logs direct from the client itself. This is not something we have any intention of changing.
1 Like
Exactly. That is the problem.
I understand that you plan that everything works magically and I bet it works 99.9% out of the time but for the occasions when there is an issue, log files would help the server owner. The user is very very unlikely to a) know what log files are and b) interested in learning about them c) playing around with files on their phone and d) have the technical background to interpret them correctly.
That decision is making life harder as it needs to be.
I would also argue that the speed test is not strictly a client side issue, it involves both sides, maybe both sides should log the outcome. Just like iperf does for example.
The server knows when it’s being speed tested, the server knows how many bytes it transferred in what time to what client. There isn’t even need for the client to report the result back since the server has all the information it needs already, it just needs to append it to the Logfile, its not complex.
It makes no sense to obfuscate potential useful information for no reason.
Please at least think/talk about it.
The server does not know when it’s being speed tested, nor does it know all of the exact details of the client, everything is contained on the client itself. An actual “speed test” as you’re thinking of it, isn’t what’s actually occurring here (and I’m not going to detail exactly what we’re doing either). There’s no information being obfuscated and in the unlikely event you need the logs, any information you could need can be easily gathered from them (no mobile phone involved, as this is only for TV clients), and passed on as needed. There are support docs that detail the entire process as well. This is not making life harder, and the work is greatly improving the client experience, decreasing the time users spend buffering, and significantly increasing the bitrate they’re streaming at. This isn’t something we’ll be changing.
5 Likes
Thanks for taking the time and clarifying.
Just to confirm, we’d only know what quality they’ve been adjusted to just like as if they would change their quality manually?
I am extremely thankful that this method will attempt to try the highest bitrate possible. I have some PLEX users that have their evil ISP’s throttle PLEX even though their device is on 5Ghz and fiber. (for those curious, AT&T, and was confirmed by using a VPN)
Thank you for all you do! This is technically a Christmas gift for me from PLEX knowing what’s coming.
EDIT: Follow up question, would we see the consumption of said speed test in PLEX’s bandwidth dashboard?
Dave I appreciate the clarity here and I am super excited for the work on this feature. Thank you!
1 Like
Yes, you would be able to see what quality they’re using, same as if they had manually changed quality. There’s no evidence of the speed detection on the server side at all, nor would you see any changes or indications in bandwidth use
2 Likes
This!
We need to see the new feature working first but until then consider everything that was said with a grain of salt.
I’ve been tagged to this thread for a long time but hadn’t checked since 2020 as it didn’t sound like the change was coming any time soon (if at all) when I last contributed.
Today trying to catch up, I tried reading through the meatier posts and responses from plex employees (who always did so very gracefully).
This started as seemingly reasonable request to set the default resolution for end users on our servers (which generated a ton folks begging, pleading etc for this to be implemented).
If I understand correctly, was the end result- plex is rolling out a fancier client solution to auto adjust to users bandwidth but still doesn’t give us the ability to set the default resolution for people streaming/transcoding from our hardware.
Is that where we landed with this? I apologize if I missed a big piece of this.
Looking forward to this being rolled out to more players, been working well on android devices so far!
1 Like
After the first play, if the client/server detects that the detected bandwidth is only 8MBPS, will it automatically set the maximum remote quality to 8MBPS going forward, or will it always try for the maximum quality each stream, lag for the start, and then ask if the client would like to lower the quality?
Or does it run the bandwidth test before the stream starts, and choose the quality that is closest to the detected speed per stream so there is less of a lag at the beginning for users with lower internet speeds?
We won’t get into technical details of how it works, though it’s much more complicated than a once-off speed test before playback. If the client is capable of playing at a better quality, then we’ll give the user that option during playback too. But it will start at the quality it played at last time. So it will move up and down depending on the connection between the server and the client. The Maximum itself won’t change, just the preferred quality.
3 Likes
