Server Version#: 1.40.0.7997
Player Version#: 1.86.1.4076-a3ab948d
I recently updated to Plex server 1.40, and this fixed my server-side HW accelerated transcoding (thank you!) … but it revealed a new twist on an old problem.
If I leave the Plex for Windows Player playing media for a few hours and come back to it, I will often - but not always - find that the quality of the video output has dropped, and it looks suspiciously like everything I play is being transcoded, even though the player is normally able to play the video in its original format. The ‘Quality’ option under the ‘Playback Settings’ menu will also disappear once this problem starts to occur.
Stopping/starting playback, or switching media seems to have no impact on this behaviour, but re-starting the player app resolves it, at least temporarily.
I used to - with previous server versions - get a similar, possibly related problem where - after a while of playing video - the player would say something along the lines of “This server is not powerful enough to convert video” when trying to start a new playback. I suspect that this is the same problem that I was encountering previously, but now that HW accelerated transcoding is enabled on the server, it’s playing back a transcoded version rather than showing the error that it used to.
This is all occurring on a local network connection, and with the exception of enabling ‘automatically sign in’, all of the player settings are - I believe - at their default values.
After encountering the issue a few more times, I’ve found a few interesting tidbits in the logs.
The following appears after the player has been active for some time, and I start playback of an item with obviously reduced quality.
server-log excerpt (needlessly transcoding)
Feb 15, 2024 01:26:15.531 [139916844243768] DEBUG - [Req#9910ed/Transcode] MDE: ***: Direct Play is disabled
Feb 15, 2024 01:26:15.531 [139916844243768] DEBUG - [Req#9910ed/Transcode] MDE: ***: no direct play video profile exists for http/mp4/hevc
Feb 15, 2024 01:26:15.531 [139916844243768] DEBUG - [Req#9910ed/Transcode] MDE: ***: no direct play video profile exists for http/mp4/hevc/aac
Feb 15, 2024 01:26:15.531 [139916844243768] DEBUG - [Req#9910ed/Transcode] MDE: ***: selected media 0 / 59131
Feb 15, 2024 01:26:15.531 [139916844243768] DEBUG - [Req#9910ed/Transcode] Streaming Resource: Calculated bandwidth of 4673kbps exceeds bandwidth limit. Changing decision parameters provided by client to fit bandwidth limit of 2000kbps
Feb 15, 2024 01:26:15.531 [139916844243768] DEBUG - [Req#9910ed/Transcode] Streaming Resource: Determining preferred transcode encoders through transcode only decision.
After shutting down the player, re-opening it, and playing the same media item with the expected quality, I get the following instead.
server-log excerpt (working as expected)
Feb 15, 2024 01:28:35.529 [139916844243768] DEBUG - [Req#9915c4/Transcode] Streaming Resource: Reached Decision id=51948 codes=(MDE=1000,Direct play OK.) media=(id=59131 part=(id=59379 decision=direct play protocol=http streams=(Video=(id=167855 decision= width=1920 height=1080) Audio=(id=167856 decision= channels=0 rate=0))))
A bandwidth limit of 2mbps smells of the limit for a relay connection.
Somehow during the sleep (or during waking up), the reachability of your server is deemed as “indirect”. Your server is not accessible directly, (at least that’s what the client thinks) and thus the bandwidth limit of 2mbps is applied.
Thanks for the suggestion, that makes sense and sounds like a viable cause.
I’m using the default power settings for a fairly recent reinstallation of Windows 11, and the system does go to sleep fairly regularly. It’s seems quite possible that this causes Plex Windows Player to switch to the relay, and it doesn’t switch back until I restart the app. It seems to me that a desirable behaviour in this circumstance would be for it to automatically try to recover the local connection.
I’ve found the setting for disabling the relay mode on the server, and I’ll keep an eye on it for a while, see if that has an impact.
Thanks OttoKerner, it seems you correctly identified the cause. Disabling the relay from the server-side appears to have resolved the issue, and I’m not seeing any negative effects from doing so.
That said, given that having the relay enabled appears to be the default setting, I suppose it’s possible this issue could be affecting some people without them realizing it … triggering some unnecessary transcodes, using some bandwidth, reducing playback quality, and so-on. This might be worth adding to someone’s to-do list somewhere, maybe.
