Constant buffering on all Plex devices since yesterday

Plex Media Server Desktops & Laptops
, , ,
1

Server Version#: 1.27.2.5929
Player Version#: 1.47.1.3086-6c3d964f

Server stats:
system:
Distro…: Ubuntu 18.04.6 LTS
Kernel…: Linux 4.15.0-188-generic

Uptime…: up 1 minute
Load…: 7.94 (1m), 2.53 (5m), 0.89 (15m)
Processes…: 215 (root), 20 (user), 235 (total)

CPU…: Intel(R) Core™ i7-3770 CPU @ 3.40GHz (8 vCPU)
Memory…: 654M used, 29G free, 31G total

storage:
/…: 605G used, 1.3T free, 2.0T total
/boot… 165M used, 552M free, 755M total
/mnt/unionfs… 605G used, 4.6P free, 4.6P total

So since yesterday I have not been able to play anything on Plex and I’m having trouble understanding why.

I have tested on the following devices
Nvidia Shield Pro 2019
Nvidia Shield 2017
Windows
Samsung Galaxy S21+

A video will play for about 10 seconds before it stops or stutters and cannot play anymore. I have tried this with a transcoded and direct play videos and both have the same result. The only software update I’ve done on the server in the past couple of days was for a software package called libnss3. I downgraded it, rebooted, and still having the same issue so I do not think this is the culprit. I do not remember upgrading PMS recently, either, but I’d like to pinpoint where the issue lies.

It does not seem to be a network or speed issue because I’ve done a speed test on the server and got the following:
$ curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python -
Retrieving speedtest.net configuration…
Testing from Aussie Broadband (IP removed)…
Retrieving speedtest.net server list…
Selecting best server based on ping…
Hosted by Swoop Broadband (Melbourne) [0.42 km]: 3.758 ms
Testing download speed…
Download: 675.61 Mbit/s
Testing upload speed…
Upload: 45.15 Mbit/s

These are the same speeds I’ve always gotten. Something is bottlenecking this and would like your help to pinpoint. Routers, modems, servers, devices have all been rebooted. All other streaming services in the house work fine, including on the Shield boxes having this issue in Plex. So it’s either an issue with my Plex server hardware (but speedtest seems fine?) or the PMS software somewhere. I was able to play a video for about a minute before it began to die while using Plex last night but now this morning it won’t even go 5 seconds.

Plex Media Server Logs_2022-07-09_13-25-27.zip (2.4 MB)

All devices involved have been rebooted multiple times. Modems, routers, players, server, etc. I’ve gone back to the current (updated) version of libnss3.

Logs attached. A sincere thank you in advance.

edit:
iperf3 results
Connecting to host IP REMOVED, port 5201
[ 4] local IP REMOVED port 65404 connected to IP REMOVED port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 59.2 MBytes 495 Mbits/sec
[ 4] 1.00-2.00 sec 60.6 MBytes 509 Mbits/sec
[ 4] 2.00-3.00 sec 53.1 MBytes 447 Mbits/sec
[ 4] 3.00-4.00 sec 42.9 MBytes 359 Mbits/sec
[ 4] 4.00-5.01 sec 45.0 MBytes 375 Mbits/sec
[ 4] 5.01-6.00 sec 38.5 MBytes 325 Mbits/sec
[ 4] 6.00-7.01 sec 26.4 MBytes 219 Mbits/sec
[ 4] 7.01-8.01 sec 33.6 MBytes 282 Mbits/sec
[ 4] 8.01-9.00 sec 34.0 MBytes 288 Mbits/sec
[ 4] 9.00-10.00 sec 48.2 MBytes 403 Mbits/sec

[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 442 MBytes 370 Mbits/sec sender
[ 4] 0.00-10.00 sec 441 MBytes 370 Mbits/sec receiver

iperf Done.

2

@bizort

Would you please go look at /dev/dri ?
You should have card0 and renderD128.

PMS is not seeing the QSV capability of your 3770k.

Jul 08, 2022 20:27:14.829 [0x7f80d9ea2b38] DEBUG - [Req#2c1d8/Transcode/10ae9f7e24f5765b-com-plexapp-android] TPU: hardware transcoding: final decoder: , final encoder:

Jul 08, 2022 20:27:14.829 [0x7f80d9ea2b38] DEBUG - [Req#2c1d8/Transcode/10ae9f7e24f5765b-com-plexapp-android/JobRunner] Job running: EAE_ROOT=/tmp/pms-e99e58f9-87b9-433d-aebb-1b766cc2c68a/EasyAudioEncoder FFMPEG_EXTERNAL_LIBS=‘/var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server/Codecs/d53cb63-4323-linux-x86_64/’ X_PLEX_TOKEN=xxxxxxxxxxxxxxxxxxxx “/usr/lib/plexmediaserver/Plex Transcoder” -codec:0 h264 -codec:1 eac3_eae -eae_prefix:1 10ae9f7e24f5765b-com-plexapp-android_ -noaccurate_seek -analyzeduration 20000000 -probesize 20000000 -i “/mnt/unionfs/movies/non4k/2000s/The Wild and Wonderful Whites of West Virginia (2009)/The.Wild.and.Wonderful.Whites.of.West.Virginia.2009.1080p.AMZN.WEB-DL.DDP2.0.x264-NTb.mkv” -map 0:0 -codec:0 copy -filter_complex “[0:1] aresample=async=1:ocl=‘stereo’:rematrix_maxval=0.000000dB:osr=48000[0]” -map “[0]” -metadata:s:1 language=eng -codec:1 libopus -b:1 258k -segment_format matroska -f ssegment -individual_header_trailer 0 -flags +global_header -segment_header_filename header -segment_time 10 -segment_start_number 0 -segment_copyts 1 -segment_time_delta 0.0625 -segment_list “http://127.0.0.1:32400/video/:/transcode/session/10ae9f7e24f5765b-com-plexapp-android/85ecf803-f70d-413d-b183-5c4957893c97/manifest?X-Plex-Http-Pipeline=infinite” -segment_list_type csv -segment_list_size 5 -segment_list_separate_stream_times 1 -segment_list_unfinished 1 -segment_format_options output_ts_offset=10 -max_delay 5000000 -avoid_negative_ts disabled -map_metadata:g -1 -map_metadata:c -1 -map_chapters -1 “media-%05d.ts” -start_at_zero -copyts -vsync cfr -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/10ae9f7e24f5765b-com-plexapp-android/85ecf803-f70d-413d-b183-5c4957893c97/progress

3

Hi @ChuckPa

Thanks so much for the quick turnaround

Yes, I have this in /dev/dri

drwxr-xr-x 3 root root 100 Jul 9 12:52 ./
drwxr-xr-x 20 root root 4260 Jul 9 13:19 …/
drwxr-xr-x 2 root root 80 Jul 9 12:52 by-path/
crw-rw---- 1 root video 226, 0 Jul 9 12:52 card0
crw-rw---- 1 root video 226, 128 Jul 9 12:52 renderD128

4

I’ve disabled “Use hardware acceleration when available” and “Use hardware-accelerated video encoding” in the plex web app transcoder settings for the server to test and still having the issue

edit: have also created a temporary directory for transcoder to use, chown plex:plex and chmod 777 (no idea what permissions this folder needs) and still buffering. I never had a directory set for this before, but it was worth a try

was also using subtitles, which i’d imagine involve transcoding. turned those off, still getting buffering every couple of seconds

5

@bizort

Let’s make sure everything is how it should be:

  1. ls -la /dev/dri
[chuck@lizum ~.2001]$ ls -la /dev/dri
total 0
drwxr-xr-x   3 root root        140 Jul  6 19:24 ./
drwxr-xr-x  22 root root       5460 Jul  6 19:24 ../
drwxr-xr-x   2 root root        120 Jul  6 19:24 by-path/
crw-rw----+  1 root render 226,   0 Jul  6 19:24 card0
crw-rw----+  1 root render 226, 128 Jul  6 19:24 renderD128
[chuck@lizum ~.2002]$
  1. Now confirm user plex is still in the same group which owns /dev/dri (render)
[chuck@lizum ~.2002]$ groups plex
plex : plex video render
[chuck@lizum ~.2003]$

  1. Now turn HW on.

  2. Start the playback

  3. terminal window ( on Linux ), and start top, press s and 5 (hit enter). (5 second refresh)

Which process is taking all the CPU time?

6

Thanks again @ChuckPa

billy@ubuntu:/$ ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 100 Jul 9 12:52 .
drwxr-xr-x 20 root root 4260 Jul 9 13:19 …
drwxr-xr-x 2 root root 80 Jul 9 12:52 by-path
crw-rw---- 1 root video 226, 0 Jul 9 12:52 card0
crw-rw---- 1 root video 226, 128 Jul 9 12:52 renderD128

billy@ubuntu:/$ groups plex
plex : plex video

not sure what you mean here but i’ve confirmed hw acceleration options are ticked on in transcoder options

playing now on tv in the other room

for %cpu nothing seems to be taking a large amount. it’s alternating between PMS, rclone, and python3, going between 1.0 and 3.4%

7

This is telling us , for this playback, the CPU/hardware is not the problem

If it’s stuttering, the next thing it can be is the communication (wifi/network) between the server and the player.

8

Thank you. The server and player boxes I used in my previous reply to show %cpu were the same used for my iperf3 examples, which seems to be normal. Is there another way to test this? Or could this be a HDD issue rather than network? I have no clues so just tossing out ideas.

My issues experienced today involved many attempted playbacks of a file containing The.Sure.Thing.1985.* that should be somewhere in the logs posted. I’ve downloaded another batch of logs and attached. The example file you’ve posted from which you posted the earlier log excerpt (/mnt/unionfs/movies/non4k/2000s/The Wild and Wonderful Whites of West Virginia (2009)/The.Wild.and.Wonderful.Whites.of.West.Virginia.2009.1080p.AMZN.WEB-DL.DDP2.0.x264-NTb.mkv) were from the initial point where I discovered the issue last night and The.Sure.Thing.1985.blahblah is the next day (today) when the problem became worse, if any of this helps.
Plex Media Server Logs_2022-07-09_12-52-05.zip (2.6 MB)

9

Thank you for that.

I can see the player app (the TV?) start the playback then, almost immediately, drop the connection. (connection reset by peer, client initiated close)

Jul 09, 2022 11:56:13.126 [0x7f7a91b7cb38] DEBUG - [Req#1018] We're going to try to auto-select an audio stream for account 1.
Jul 09, 2022 11:56:13.126 [0x7f7a91b7cb38] DEBUG - [Req#1018] Selecting best audio stream for part ID 164273 (autoselect: 0 language: en)
Jul 09, 2022 11:56:13.126 [0x7f7a91b7cb38] DEBUG - [Req#1018] Audio Stream: 467450, Subtitle Stream: -1
Jul 09, 2022 11:56:13.130 [0x7f7a90529b38] DEBUG - Completed: [192.168.1.36:37574] 200 GET /library/metadata/98558?includeChapters=1&includeLoudnessRamps=1&includeMarkers=1&includeRelated=1 (12 live) TLS GZIP 267ms 18416 bytes (pipelined: 1)
Jul 09, 2022 11:56:15.787 [0x7f7a9023fb38] DEBUG - Request: [192.168.1.36:37574 (Subnet)] GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (12 live) #1028 TLS Signed-in Token (bizort) (SHIELD Android TV) (range: bytes=9536101936-) 
Jul 09, 2022 11:56:16.287 [0x7f7a9023fb38] DEBUG - Content-Length of /mnt/unionfs/movies/non4k/1980s/The Sure Thing (1985)/The.Sure.Thing.1985.1080p.BluRay.x264.DTS-MaG.mkv is 1170 (of total: 9536103106).
Jul 09, 2022 11:56:17.044 [0x7f7a90506b38] DEBUG - Failed to stream media, client probably disconnected after 245760 bytes: 32 - Broken pipe
Jul 09, 2022 11:56:17.044 [0x7f7a90506b38] DEBUG - Completed after connection close: [192.168.1.36:37578] 200 GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (12 live) TLS 4076ms 245760 bytes (pipelined: 2)
Jul 09, 2022 11:56:18.731 [0x7f7a90529b38] DEBUG - Completed: [192.168.1.36:37574] 206 GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (11 live) TLS 2944ms 1170 bytes (pipelined: 2) (range: bytes=9536101936-) 
Jul 09, 2022 11:56:18.733 [0x7f7a91b7cb38] DEBUG - Request: [192.168.1.36:37574 (Subnet)] GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (11 live) #102a TLS Signed-in Token (bizort) (SHIELD Android TV) (range: bytes=68461-) 
Jul 09, 2022 11:56:18.736 [0x7f7a91b7cb38] DEBUG - Content-Length of /mnt/unionfs/movies/non4k/1980s/The Sure Thing (1985)/The.Sure.Thing.1985.1080p.BluRay.x264.DTS-MaG.mkv is 9536034645 (of total: 9536103106).
Jul 09, 2022 11:56:26.717 [0x7f7a90506b38] DEBUG - Failed to stream media, client probably disconnected after 1048576 bytes: 104 - Connection reset by peer
Jul 09, 2022 11:56:26.717 [0x7f7a90506b38] DEBUG - Completed after connection close: [192.168.1.36:37574] 206 GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (11 live) TLS 7984ms 1048576 bytes (pipelined: 3) (range: bytes=68461-) 
Jul 09, 2022 11:56:26.731 [0x7f7a9023fb38] DEBUG - Request: [192.168.1.36:37580 (Subnet)] GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (11 live) #101b TLS Signed-in Token (bizort) (SHIELD Android TV) (range: bytes=994157-) 
Jul 09, 2022 11:56:26.734 [0x7f7a9023fb38] DEBUG - Content-Length of /mnt/unionfs/movies/non4k/1980s/The Sure Thing (1985)/The.Sure.Thing.1985.1080p.BluRay.x264.DTS-MaG.mkv is 9535108949 (of total: 9536103106).
Jul 09, 2022 11:56:26.849 [0x7f7a9023fb38] DEBUG - Request: [192.168.1.36:37582 (Subnet)] GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (12 live) #102c TLS Signed-in Token (bizort) (SHIELD Android TV) (range: bytes=9536046128-) 
Jul 09, 2022 11:56:26.850 [0x7f7a9023fb38] DEBUG - Content-Length of /mnt/unionfs/movies/non4k/1980s/The Sure Thing (1985)/The.Sure.Thing.1985.1080p.BluRay.x264.DTS-MaG.mkv is 56978 (of total: 9536103106).
Jul 09, 2022 11:56:31.446 [0x7f7a90506b38] DEBUG - Completed: [192.168.1.36:37582] 206 GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (11 live) TLS 4597ms 56978 bytes (pipelined: 1) (range: bytes=9536046128-) 
Jul 09, 2022 11:56:31.455 [0x7f7a9023fb38] DEBUG - Request: [192.168.1.36:37582 (Subnet)] GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (11 live) #102f TLS Signed-in Token (bizort) (SHIELD Android TV) (range: bytes=486072-) 
Jul 09, 2022 11:56:31.458 [0x7f7a9023fb38] DEBUG - Content-Length of /mnt/unionfs/movies/non4k/1980s/The Sure Thing (1985)/The.Sure.Thing.1985.1080p.BluRay.x264.DTS-MaG.mkv is 9535617034 (of total: 9536103106).
Jul 09, 2022 11:56:35.288 [0x7f7a90529b38] DEBUG - WebSocket: client initiated close
Jul 09, 2022 11:56:35.288 [0x7f7a90529b38] DEBUG - NotificationStream: Removing because of close
Jul 09, 2022 11:56:35.289 [0x7f7a90506b38] DEBUG - Failed to stream media, client probably disconnected after 966656 bytes: 32 - Broken pipe
Jul 09, 2022 11:56:35.289 [0x7f7a90506b38] DEBUG - Completed after connection close: [192.168.1.36:37582] 206 GET /library/parts/170307/1581131903/file.mkv?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=200960 (13 live) TLS 3833ms 966656 bytes (pipelined: 2) (range: bytes=486072-)

Did you get a TV app update?

10

From the looks of it, you’re mounting GDrive. If that’s the case, see here for an explanation of what’s going on, as well as a possible workaround:

11

Hi @ChuckPa

TV app as in the Plex app? They are all current, as of what’s available on google player for me at the moment, and have been current for the last few days, as far as I’m aware, but I do not keep too aware of when a new version of the player is available on most of my boxes. I’ll list the current versions:

192.168.1.36 is the 2019 nvidia shield pro in my home network, and my main player. This is on Plex v9.4.1.33413. I haven’t tried to roll back the version on this yet, but I could do that.

The 2017 nvidia shield will show up as either 192.168.1.24 or .37. I was playing with this during the issue so it may show up as either one. This is the player I discovered the problem on initially (Wild and Wonderful Whites of West Virginia). This one is currently on Plex v9.4.1.33413 as well, but I did roll this version back to the factory version of Plex and it still gave me the same issues. Nvidia core software was updated on this one (v9.1) but not updated on the above 2019 pro box, so I feel I can safely rule out nvidia software being the issue.

Windows app is on Plex v 1.47.1.3086-6c3d964f
Is on IP 192.168.1.68

My phone, samsung s21+, is on Plex v9.4.1.33413 as well, set to dhcp

I have the same issue when attempting to cast video via plex, in case that’s relevant

Would iperf3 test a sustained network connection, such as streaming a large video file for longer than a minute or two? It seems it will establish the connection without issue, it just gives up after 5-10 seconds, as you said.

12

Hi @VBB

Wow, I think this is my solution!

Upon reading this, I thought my issue was different, was it seems all these users were getting 300k/sec and I wasn’t even getting this far, as my connection would die almost immediately upon the start of video. But the point about the endpoints and DNS made sense so I pinged www.googleapis.com, recorded the IP, did a flush of the dns via the command sudo systemd-resolve --flush-caches and pinged googleapis again, saw I got a new IP address, then tried to stream from my main player and voila! This solution would make sense, as the issue seemed to be isolated to my own library (hosted on google suite) but nothing else.

The only kicker is I had not tried to stream anything previously to flushing the IP, or tried to stream anything at all today (my last attempt to stream would’ve been about 12 hours ago) so something else could’ve happened between then and now, unrelated to my switching google endpoints, but my issue does appear to be resolved now. I haven’t finished reading the whole thread but that shell script to automatically cast out bad endpoints may be useful to me later if this comes up again

Thank you so much @VBB and @ChuckPa I’m hopeful I found something here. You’re both wonderful, thank you again

1 Like
13

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