PMS 1.9.x, Buffering, and Bad "Limit Remote Stream Bitrate" Calculations

General Discussions
1

Posting this in Plex Pass discussion in the hopes that it gets more attention from Plex.

I finally upgraded my PMS install, after a holding pattern on 1.4.x, due to the Plex.tv client bug hammering old servers (this).

Like many others–a few Reddit threads, threads here on the Plex forums–I now have increased reports of bad quality and buffering from the handful of friends and family that use my server, where no problems existed before. I strong suspect there is some bad math happening on the Plex server side of things when it comes to buffer/bitrate calculation.

I am running 1.9.5.4339.

One indication of bad math is newly-incorrect “Limit Remote Stream Bitrate” calculations. Here’s a concrete example:

With my server set to 4Mbps stream limit:

And content at ~2.6Mbps, as seen by the PS4 Plex client:

mbDHKfz.png1060×587

The server is sending a massively low quality stream:

(It’s also visually quite evident that it’s a low-bitrate stream without checking PlexPy)

With higher-bitrate content, like movies, nearly everyone is reporting that their Plex client starts continuously buffering at 720p bitrates (3 or 4Mbps). This was absolutely not present in 1.4.x. My best guess is that Plex is doing buffer/throttle/whatever calculations wrong and just not encoding enough content for the bitrate/transfer that’s actually going out on the wire.

I doubt my server/network are a factor. They haven’t changed, and also I run Plex in a VM with 14 available cores, have transcoding temp directory set to a 16GB ramdisk, etc etc. It’s pretty far into overkill territory.

It was not hard for me to replicate these issues at home–I set up an old router to go through a VPN, plugged the PS4 into it, and started seeing some of the issues that people outside my network are seeing. Are Plex engineerings seriously not testing these use cases? It’s very, very frustrating that upgrading Plex introduces new issues (and the only reason I had to upgrade was because of the Plex.tv client bug).

I’m happy to extract whatever server/transcoding log files can illuminate the issue, if it helps. From other threads I’ve seen here, though, I’m very likely just yelling at the wind, and Plex will launch some kind of fantasy football integration long before they address issues like this :neutral:

2

What Quality are your players asking for? If they don’t ask for the quality, PMS won’t send it.

3

@ChuckPA said:
What Quality are your players asking for? If they don’t ask for the quality, PMS won’t send it.

In the PS4 example above, the client remote quality setting is set to 4Mbps:

745×561 528 KB

With the server-side “remote stream limit bitrate” set to 3Mbps or 4Mbps, the PS4 ends up playing a much lower-quality stream on 2.6Mbps original bitrate content. I don’t know what’s happening in terms of the back-and-forth with the server here (is this negotiation in the logs?), only that with my previous PMS 1.4.x install the client would correctly end up doing a direct play or direct stream in this situation.

With PMS 1.9.x, though, the client drops down to a much lower quality, unless I disable the stream limit or raise it to 8Mbps.

I mean, 2.6 < 3Mbps, so I expect the server to be okay with sending that quality as requested by the client.

Also, I’m not sure “If they don’t ask for the quality, PMS won’t send it” has ever been the real-world behavior I’ve seen with the server-side remote stream limit. With a limit in place, the client UI will still show “original” or “1080p” or whatever, even when the stream it’s actually playing is much less (as limited by that server setting). There has never been a client UI-side indication of the actual quality, beyond noticing 480p artifacts or checking PlexPy.

4

2.6 Mbps is the video payload, not the total cost of sending it. You must add that overhead.

When you set the limit to 4. overhead consumes approx 15-20 % of that .
Being conservative, 4 * 0.80 = 3.2 Mbps maximum combined audio/video bitrate

Setting the rate at 3 will give you effectively 2.4 Mbps video+audio usable bitrate.

5

The PS4 client ends up playing a low quality even with a server-side limit of 4Mbps.

The file in question (it does seem like the “2.6Mbps” in the PS4 UI is the overall bit rate):

Format                                   : Matroska
Format version                           : Version 4 / Version 2
File size                                : 432 MiB
Duration                                 : 22mn 23s
Overall bit rate mode                    : Variable
Overall bit rate                         : 2 694 Kbps

Video:

Bit rate mode                            : Variable
Bit rate                                 : 2 370 Kbps
Maximum bit rate                         : 3 555 Kbps

Audio:

Bit rate mode                            : Constant
Bit rate                                 : 384 Kbps

And, again, this behavior is new as of PMS 1.9.x (or maybe earlier, I don’t know–I’m coming from 1.4.x).

6

if the max bit rate, based on your post, is 3.555 Mbps; add 3555 + 384 = 3939. Multiply by 1.25 to get the maximum upstream (Non-LAN) 4923 Kbps.

7

Look: What I am saying is that behavior has changed with my PMS upgrade, and it has changed for the worse. In addition to bad transcode decisions induced by the server-side remote stream limit, buffering has increased across the board for people trying to run 720p streams who could easily run them before (I suspect the two issues are related).

I yanked the last 1000 sessions out of my PlexPy database, since stream resolution over time isn’t an available graph:

select datetime(history.started, 'unixepoch'), info.transcode_height
from session_history history, session_history_media_info info
where history.id = info.id and info.transcode_decision='transcode'
order by history.id desc
limit 1000

gICuX88.png1143×708 52.2 KB

Looking at that row of 480p resolution transcodes–when do you think I performed the PMS upgrade?

8

If that’s the case,

On a completely quiet PMS server (no other users), with Debug logging only, Recreate the problem.
As soon as you see it, count 5 seconds and then stop playback.
If you can gather Player logs, please do so. https://support.plex.tv/hc/en-us/articles/201869908-Log-Files
Settings - Server - Help - Download Logs will present you with the server ZIP file I need to give to engineering.

9

Probably easier to just spin up two VMs for the different versions to pull logs, compared to waiting for dead air on the weekend. I’ll try to get that done tomorrow!

10

Here’s what happens with 1.9.x and low-quality transcode streams, when previously players would direct stream or direct play. I guess this probably started happening when DASH was introduced.

Previously with 1.4.x, this situation would just direct play or direct stream. I’d have to pull a backup of my VM to verify, though, since codecs are no longer available for 1.4.x installs.

Anyway, here’s what’s happening with very low-quality transcodes on content around the server stream limit:

So, firstly, despite this in the web player preferences (and automatic quality disabled):

QVaBQUt.png872×196 114 KB

I guess DASH now requires everything to be transcoded, according to the server log:

Oct 23, 2017 17:20:12.871 [4264] DEBUG - MDE: E5 - The Trolley Problem: Direct Play is disabled
Oct 23, 2017 17:20:12.887 [4264] DEBUG - MDE: E5 - The Trolley Problem: media must be transcoded in order to use the dash protocol

I guess this would explain the transcoding increase across the board in general? (Not just me, but other threads as well).

So yeah, with server limit at 3Mbps:

Oct 23, 2017 17:20:12.887 [4264] DEBUG - Streaming Resource: Changing decision parameters to fit bandwidth limit of 3000kbps

It fails the server limit after scaling up:

Oct 23, 2017 17:20:12.887 [4264] DEBUG - Scaled up video bitrate to 3465Kbps based on 1.500000x fudge factor.

And settles on this as first calculation:

Oct 23, 2017 17:20:12.887 [4264] DEBUG - Streaming Resource: Reducing playback quality for 2857kbps stream bitrate: video resolution to 720x406, audio channels to 2, quality to 84

This is that same file with mediainfo output above. This is already weird, because the source file is 720p at about that bitrate already. Not ideal, but at least it will be a lot of bitrate for that resolution…

…except, no, the server is going to lower bitrate because the resolution dropped:

Oct 23, 2017 17:20:12.887 [4264] DEBUG - Scaled maximum bitrate for resolution reduction to 1099Kbps.

So final decision, with content near the server limit of 3Mbps, is that a 1Mbps/406p stream goes out the door instead?

Oct 23, 2017 17:20:12.887 [4264] DEBUG - Streaming Resource: Reached Decision id=3 codes=(General=1001,Direct play not available; Conversion OK. Direct Play=3000,App cannot direct play this item. Direct play is disabled. Transcode=1001,Direct play not available; Conversion OK.) media=(id=1 part=(id=1 decision=transcode container=mp4 protocol=dash streams=(Video=(id=1 decision=transcode bitrate=1099 encoder=libx264 width=720 height=406) Audio=(id=2 decision=transcode bitrate=232 encoder=aac_mf channels=2 rate=48000))))

Full logs attached, if it helps at all.

I guess I’ll try to get a 1.4.x server working so I can A/B test the 720p buffering issue separately.

11

I’ve always left mine around 8megabit, and had clients set for around 3, even just one running on LTE would buffer too often, less likely but would still sometimes on a wifi connection external. I’ll try setting mine to original (unlimited) on the remote access page settings, and just make sure all clients are set to 3megabit or less to see if this fixes everything.

12

Have any of you upgraded to 1.10 and verified the condition still exists?