Remote buffering after hardware change

Plex Media Server Desktops & Laptops
1

Hello folks!

Recently I upgraded my debian poweredge from a single x5672 to dual x5675 processors. After the change I used sudo apt update, upgrade, dist-upgrade, and rebooted several times. I can stream locally and remote from my office on my own devices without issue. I have plex running in the offical docker image and I update pulled yesterday to the latest version (1.40.3.855).

However I have a remote user in another country who had no issues previously, was able to stream 1080p 10Mbps no problem, now has issues buffering above 4Mbps. He can connect to my friends server and stream the same content at higher speeds without issue. He is using the firefox web interface.

I ran tracert to his ip and the ping is never higher than 114ms. I have my server set to transcode 1800s ahead. My internet is 600/600.

I cleared the cache and codecs folders, which did improve things, but hasn’t fully resolved the issue. My question is after a hardware change like this do I need to update anything else? I moved this installation from a windows machine a few weeks ago and copied the ‘Plex Media Server’ folder right over to linux without any issues. Thanks so much for your help!

2

I don’t know much of the intricacies of Linux, but here are my $0.02:

As far as Plex is concerned, that is in fact a downgrade.
Compare the number of cores (per socket) and the “single thread performance”.
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+X5672+%40+3.20GHz&id=1308

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+X5675+%40+3.07GHz&id=1309&cpuCount=2

Plex is not able to use several cpu sockets for the same transcoding session. i.e. the second CPU is only of use to you if there is more than 1 transcoding session at the same time.

That is still kinda high. You may want ensure that the user is using a playmode of Direct Play, by carefully selecting the client type (maybe try the Plex Desktop apps instead of the web browser) and the type of media to play.

3

As far as Plex is concerned, that is in fact a downgrade.

That is interesting, I thought more cores (6 vs 4) would be better for transcoding, but maybe not? I also have x5687 I can try, but locally I haven’t seen any transcoding issues. (maybe some day I’ll get the coveted x5690)

That is still kinda high.

I hate to deflect the blame but I feel like the issue is somewhere between us and maybe on his computer. He was streaming the day before the upgrade without issues. Maybe firefox has a cache with the previous transcoder settings or something? I see in the plex dashboard the light orange bar is a bit ahead of his progress. I just can’t imagine the connection between us happened to change the day after I made this hardware change. I’ll try to get him to try the windows app, I just don’t want to drive him nuts trying different things when he can just use the other server.

4

Unfortunately, he’s having the same buffering issues with the windows app running in direct play.

5

Yeah, but those 6 cores are distributed across 2 cpu sockets, which cannot be used in tandem by the same transcoding job. Which means that a single cpu now has 3 cores.

6

There’s two x5675s with 6 cores each totaling 12 cores with 6 on each socket. So even if its only using one CPU for the transcode theres 6 cores working on it.

The speed is slower and I’m not against swapping in the x5687s cause why not, but I had my other friend try remote streaming a huge movie and he had no issues. He’s in the same country as me tho…

7

If I may add?

This is indicative of the network.

I would first confirm the point-to-point throughput.

  1. Install the iperf3 server on the PMS machine
    iPerf - Download iPerf3 and original iPerf pre-compiled binaries

  2. Now install iperf3 client on the other machine.
    (same URL)

  3. Run an up & down test from client to server.
    While you won’t get these speeds, it’ll look like this
    (Look at the bitrates)

Note: 192.168.0.20 is the IP of my PMS server. For remote access to it, Port Forward port 5201 (in the documentation)

[chuck@lizum ~.2001]$ iperf3 -c 192.168.0.20
Connecting to host 192.168.0.20, port 5201
[  5] local 192.168.0.13 port 33096 connected to 192.168.0.20 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.10 GBytes  9.43 Gbits/sec    0   1.52 MBytes       
[  5]   1.00-2.00   sec  1.10 GBytes  9.41 Gbits/sec    0   1.52 MBytes       
[  5]   2.00-3.00   sec  1.09 GBytes  9.41 Gbits/sec    0   1.59 MBytes       
[  5]   3.00-4.00   sec  1.10 GBytes  9.42 Gbits/sec    0   1.68 MBytes       
[  5]   4.00-5.00   sec  1.09 GBytes  9.41 Gbits/sec    0   1.68 MBytes       
[  5]   5.00-6.00   sec  1.10 GBytes  9.42 Gbits/sec    0   1.76 MBytes       
[  5]   6.00-7.00   sec  1.10 GBytes  9.42 Gbits/sec    0   1.76 MBytes       
[  5]   7.00-8.00   sec  1.10 GBytes  9.42 Gbits/sec    0   1.76 MBytes       
[  5]   8.00-9.00   sec  1.10 GBytes  9.42 Gbits/sec    0   1.76 MBytes       
[  5]   9.00-10.00  sec  1.09 GBytes  9.41 Gbits/sec    0   1.76 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  11.0 GBytes  9.41 Gbits/sec    0             sender
[  5]   0.00-10.04  sec  11.0 GBytes  9.37 Gbits/sec                  receiver

iperf Done.
[chuck@lizum ~.2002]$ iperf3 -c 192.168.0.20 -R
Connecting to host 192.168.0.20, port 5201
Reverse mode, remote host 192.168.0.20 is sending
[  5] local 192.168.0.13 port 55442 connected to 192.168.0.20 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  1.09 GBytes  9.38 Gbits/sec                  
[  5]   1.00-2.00   sec  1.10 GBytes  9.42 Gbits/sec                  
[  5]   2.00-3.00   sec  1.10 GBytes  9.41 Gbits/sec                  
[  5]   3.00-4.00   sec  1.10 GBytes  9.42 Gbits/sec                  
[  5]   4.00-5.00   sec  1.10 GBytes  9.41 Gbits/sec                  
[  5]   5.00-6.00   sec  1.10 GBytes  9.41 Gbits/sec                  
[  5]   6.00-7.00   sec  1.10 GBytes  9.41 Gbits/sec                  
[  5]   7.00-8.00   sec  1.10 GBytes  9.41 Gbits/sec                  
[  5]   8.00-9.00   sec  1.10 GBytes  9.41 Gbits/sec                  
[  5]   9.00-10.00  sec  1.10 GBytes  9.41 Gbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  11.0 GBytes  9.38 Gbits/sec    1             sender
[  5]   0.00-10.00  sec  11.0 GBytes  9.41 Gbits/sec                  receiver

iperf Done.
[chuck@lizum ~.2003]$

You can increase the duration of the test by adding -t N (number of tests) option.

Recommend having him run:

iperf3 -c your.wan.ip.addr -t 60 -R

This will test his ability to receive for 60 seconds.

After this , May I see DEBUG server logs ZIP which captures a playback so I can see what the server is doing?

8

Thanks ChuckPa, I’ll give this a try this weekend

9

Well, the issue seems to have gone away. I’ve made all sorts of changes since then so who knows what fixed it. Iperf3 is a great tool glad I have that now. Thanks for all the replies!

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.