Plex Media Server grinding to a halt while scanning library

Server Version#: 1.14.1.5487 (Current Plex Pass release) on Ubuntu Server 18.10
Player Version#: Chrome Web Client version 3.79.0

As the title states, my media server has been just refusing to serve any media out of the blue when a media library scan suddenly just gets wedged up and continues to run forever. Restarting the plexmediaserver service will bring it back up for a few hours, but the problem comes back every day, reliably. I’ve combed the logs, and nothing stands out to me as a red flag. Perhaps someone smarter than me can point me in the right direction here?

I used to have an nVidia P2000 dedicated GPU attached to this VM, which I have since removed in order to test to see if that was causing the issues. I’ve also tried disabling thumbnail generation entirely, which also didn’t help.

logs.zip (119.1 KB)

While it would have been better to see more logs (the entire ZIP file it gives you),

I can see your database is slowing down.

Dec 13, 2018 20:07:57.065 [0x7f6bbbbff700] WARN - SLOW QUERY: It took 210.000000 ms to retrieve 50 items.

PMS normally can pull 50 items in 1-2 ms.

Scancel the scan.
Manually optimize the database.
Scan again

The slow performance you’re seeing can also be a function of how much memory you gave the VM (is it swapping?) and how many cpus have been allocated. If too few CPUs, it will single thread and become very slow.

Thanks for the first look. This VM is on a very sparsely populated ESXi host. It has 12 xeon 2.2Ghz cores dedicated to it, and 34GB of RAM dedicated to it (yes, I know that’s wildly more than it needs to run Plex, but I had the free RAM and CPU cores to spare, so why not throw more hardware at the problem?). The VM isn’t swapping, at all, though Linux is eating all the available memory to use as for file caching. There’s very little IOwait going on; such a small amount that I’m inclined to ignore it altogether.

$ free -h
              total        used        free      shared  buff/cache   available
Mem:            34G        7.3G        464M         88M         26G         26G
Swap:            0B          0B          0B
top - 23:22:55 up 43 days, 12:10,  2 users,  load average: 0.56, 0.54, 0.53
Tasks: 398 total,   1 running, 288 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.0 us,  0.9 sy,  0.0 ni, 97.0 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 36035980 total,   338892 free,  7674928 used, 28022160 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 27954364 avail Mem
$ nproc
12

I’ve attached the actual downloaded log files, instead of my homebrew zip file: Plex Media Server Logs_2018-12-13_23-19-41.zip (2.8 MB)

About the slow queries, I’ve cleaned the database, and even went so far as to dump and reimport it last night. At this point, I’m just assuming that’s the name of the game when your media collection grows to ~17TB. If there’s some action I can take to fix that, please do let me know.

Definitely still struggling with this. Anyone have any ideas?

From what I’m able to see in the most recent logs, it really looks like the player is doing most of the struggling here… Player / network. What’s puzzling is it’s the web player.

It’s reporting back-to-back Paused.

Dec 13, 2018 23:15:12.243 [0x7eff477ff700] DEBUG - Completed: [192.168.1.191:57534] 200 GET /video/:/transcode/universal/ping?session=zv08i4r9ykesemq26dw601zb (19 live) TLS GZIP 1ms 268 bytes (pipelined: 1)
Dec 13, 2018 23:15:12.243 [0x7eff2a7ff700] DEBUG - Client [cq7nhb3fj8764lteiibf2n1l] reporting timeline state paused, progress of 2696000/2819000ms for guid=, ratingKey=23619 url=, key=/library/metadata/23619, containerKey=, metadataId=23619, source=
Dec 13, 2018 23:15:12.243 [0x7eff2a7ff700] DEBUG - [Now] User is Cdchris12 (ID: 1)
Dec 13, 2018 23:15:12.243 [0x7eff2a7ff700] DEBUG - [Now] Device is Chrome (Chrome).
Dec 13, 2018 23:15:12.243 [0x7eff2a7ff700] DEBUG - [Now] Profile is Web
Dec 13, 2018 23:15:12.243 [0x7eff2a7ff700] DEBUG - [Now] Updated play state for /library/metadata/23619.
Dec 13, 2018 23:15:12.245 [0x7eff2a7ff700] DEBUG - Statistics: (gyd9bmqyf8deal28257ekjsz) Reporting active playback in state 1 of type 4 (scrobble: 0) for account 1
Dec 13, 2018 23:15:12.248 [0x7eff46ffe700] DEBUG - Completed: [192.168.1.191:57533] 200 GET /:/timeline?ratingKey=23619&key=%2Flibrary%2Fmetadata%2F23619&playbackTime=2696540&playQueueItemID=67705&state=paused&hasMDE=1&time=2696000&duration=2819000 (19 live) TLS GZIP 6ms 843 bytes (pipelined: 1)
Dec 13, 2018 23:15:12.680 [0x7eff487ff700] DEBUG - Statistics: Flushing 18 expired bandwidth entries, 0 expired media entries.
Dec 13, 2018 23:15:22.241 [0x7eff46ffe700] DEBUG - Auth: authenticated user 1 as Cdchris12
Dec 13, 2018 23:15:22.241 [0x7eff03bff700] DEBUG - Request: [192.168.1.191:57533 (Allowed Network)] GET /:/timeline?ratingKey=23619&key=%2Flibrary%2Fmetadata%2F23619&playbackTime=2696540&playQueueItemID=67705&state=paused&hasMDE=1&time=2696000&duration=2819000 (18 live) TLS GZIP Signed-in Token (Cdchris12)
Dec 13, 2018 23:15:22.244 [0x7eff03bff700] DEBUG - Client [cq7nhb3fj8764lteiibf2n1l] reporting timeline state paused, progress of 2696000/2819000ms for guid=, ratingKey=23619 url=, key=/library/metadata/23619, containerKey=, metadataId=23619, source=
Dec 13, 2018 23:15:22.244 [0x7eff03bff700] DEBUG - [Now] User is Cdchris12 (ID: 1)

You then stop playback and start again.

The very first thing it does is report Paused again. This time, it’s a near-steady stream of them.

Where is Chrome running? 192.168.1.191 ? Linux, Windows, or Mac ?

192.168.1.191 is the Mac I’m using locally to verify the problems. I’m also seeing these problems not tied to any one client; the wife is using an Apple TV 4k and I’ve got a buddy using Chrome on Windows outside the LAN, all three of us see the same symptoms of the Plex server not wanting to actually serve media. The UI seems to work, but when you click on a title to stream, it just sits and spins ad infinitum.

Bare with me please (Chuck’s stupid question time) :smiley:

  1. What’s the bitrates ? above or below 20 Mbps ?
  2. I do see foreign language subtitles being selected. Are they being burned in? (can’t see in the transcoder command line.)
  3. I do see the video is otherwise ok but the player(s) can’t take EAC-3 and are being DirectStreamed for that reason.

Now for the kicker. Can you help me with this?

The CPU itself has a Passmark score of 6800 so it’s bad but not stellar when trying to burn multiple subtitles concurrently. You might get 2 streams at 20 Mbps but my 8000 passmark i7 can’t do more than 2.

This is bringing me back to the CPU loading. You show 0.56 so it can’t be that unless the network isn’t right and you’re getting packet loss all over the place (MTU packet sizes or similar).

Can you enlighten?

Typical media bitrates are at or below 10Mbps. Some of the 4k content i’ve got sitting around is MUCH higher, but all the stuff at hand here is 1080p or 720p and mostly lower bitrates.

None of the folks on my plex server are using any foreign language subtitles, that I’m aware of. I do know that the Chrome web player doesn’t do ac3 audio, causing at least audio transcoding to occur on the host, but the Apple TV can direct play just about anything you can mux into an MKV container, afaik. If there are subtitles on the Apple TV, though, they do get burned in on the Plex Server, typically.

As I said, I’m not seeing any issues with excessive CPU load, basically ever. My peak CPU usage over the last week for this VM, according to the ESXI host, is less than 2 total cores. There have been some spikes of what look to be obvious single core tasks, but the Plex transcoder is multithreaded, so that should be a non issue.

I’m seeing peak disk latency at 37ms, so no issues there. Network usage is all over the place, but it’s connected via a gigabit backbone to the LAN. I’ve not had packet loss problems with any other software running on this host (Transmission, Samba, Sonarr, and Radarr), so I’m disinclined to think that’s the issue.

As an aside, I also rate limit streams leaving the LAN to 4Mbps. It effectively means I can’t really host 4k or x.265 content until Plex incorporates nVidia hardware based transcoding for such workloads. One day, that’ll happen; I want to believe!

You may have just found fit …

How many VCPUs did you allocate? How much memory?
How loaded is the host itself?

I was unaware of the VM status until just now. Thanks for sharing that.

found fit?

I’ve got 12 CPU cores available to the ESXI host, and 12 VCPUs available to this VM. There is 96 GB of RAM on the host, with 34GB allocated to this single VM. Honestly, this is the only VM on the cluster for all intents and purposes. I’ve got some assorted other stuff, but every other VM’s collective CPU usage is less than a tenth of a single core.

The ESXI host itself is not even breaking a sweat. No egregious usage of any resources, by this VM or any other. To be clear, I haven’t made any major changes to my infrastructure since this problem started occurring about a month or so ago.

“Found fit” … that’s geek speak for “Go to bed… it’s past your bedtime” haha .

I will unfortunately need to ask you to hang in until Monday, or if easier,

  1. cd /var/lib/plexmediaserver
  2. stop PMS
  3. mv Library Library.save
  4. start PMS
  5. Initialize a new , TEST, PMS instance with a friendly name which makes it clear it’s “Testing”.
  6. Now add one small library
  7. When it completes, add a bit more.
  8. repeat until failure point.

I suspect your media is over on a NAS? What’s the mount protocol? NFS ? SMB ?

TIL about Found fit, lol. I’m one of today’s lucky 10k!

I probably don’t want to take down my Plex server over the weekend; I’d have some folks pretty peeved at me, I’d bet. I can probably get back to this on Tuesday though.

All the media is on a local mount, which is a VMware datastore mounted on this ESXi host’s RAID5 24TB storage array.

$ df -h | grep -v snap
Filesystem                               Size  Used Avail Use% Mounted on
udev                                      18G     0   18G   0% /dev
tmpfs                                    3.5G  3.8M  3.5G   1% /run
/dev/mapper/ubuntu--server--00--vg-root   30G   26G  2.6G  92% /
tmpfs                                     18G  420K   18G   1% /dev/shm
tmpfs                                    5.0M     0  5.0M   0% /run/lock
tmpfs                                     18G     0   18G   0% /sys/fs/cgroup
/dev/sda1                                472M  258M  190M  58% /boot
tmpfs                                    3.5G   28K  3.5G   1% /run/user/135
tmpfs                                    3.5G     0  3.5G   0% /run/user/1000
/dev/sdb1                                 19T   17T  1.9T  90% /Storage

All my media files are owned by a user and group, let’s call them userb and groupb. The plex user is a member of groupb, and most files are stored with 644 permissions.

One other thought.

Do you have any MP4 files which you know won’t require transcoding in any way. e.g “DirectPlay” ready?

If so, can you fire up a few of those?

Where I’m having trouble is the per-thread performance of that xeon. Frankly, it’s low.

6800 passmarks / 12 = 566 passmarks. The minimum to run PMS is 700 Passmarks. NAS boxes have 2000 Passmark dual cores and they struggle.

Assuming for a moment that’s inclusive of threads. It’s divide.

6800 / 6 = 1133 passmarks. Still not stellar in any way.
The Passmark report shows “Single Thread Rating: 1123”

The rule we use for video transcoding (in software) is 2000 passmarks / 10 Mbps of video.
Audio is easier but some codecs are hard (7.1 -> stereo for example).

I am torn. I think that CPU, for as well as it might work in some applications, just isn’t up to the task of running PMS but I don’t want to conclude that just yet.

This is why the next best step is to construct a controlled test sometime when it is available.

Make sense (even if I’m not entirely due to the hour ?)

You do make an interesting point. Interesting enough to get me to buy a new set of CPUs for my server. It’s probably worth the $50 in the end, anyway.

Here’s my current passmark: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+L5639+%40+2.13GHz&id=1983&cpuCount=2

Here’s the expected passmark for the new CPUs: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+X5680+%40+3.33GHz&id=1312&cpuCount=2

Still not spectacular, but a lot better than the low power CPUs the server came with. Also, remember that this system has two actual CPU dies, each with 6 physical cores, each with 2 threads.

I’ll definitely try to do some mp4 testing tomorrow and let you know what I find!

13000 Passmarks? That is quick. ZERO argument there. 13,000 passmarks is enough to transcode HEVC HDR in software without GPU assist.

I run an i7-7700 @ 3.6.Ghz and it’s 10,000 passmarks. It screams. A xeon at 13 is a workhorse

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-7700+%40+3.60GHz&id=2905

I will say this: “The board and CPUs don’t owe you anything” If you can swing the upgrade easily enough, do it. You will be profoundly happier in the end.

Sorry for the lag in getting back to this issue. I’ve identified some other issues on this host and have been chasing them down one by one. It seems that the UniFi controller package and its mongod process were reserving so much RAM for caching that they were throwing my server into swap, which wasn’t good. I’ve mostly sorted that, but I’m still seeing these issues.

I noticed one critical thing that happens when I observe this behavior; the transcoder seems to fail to spawn a child process, marked in the logs by returning -1 as a PID instead of an actual PID. Plex then just sits and spins waiting for the transcoder to actually return some data that it can then send to the client.

PS: The new CPUs haven’t seemed to make an appreciable difference in anything, really. This whole VM host was already pretty beefy as it was.

Here’s a few examples of what I mean:

Jan 12, 2019 19:10:06.265 [0x7f46abfff700] DEBUG - Starting a transcode session ba3cebe2-1f41-4dfa-94cf-810a2a5ee556 at offset -1.0 (state=3)
Jan 12, 2019 19:10:06.265 [0x7f46abfff700] DEBUG - Streaming Resource: Added session 0x7f46584d2660:ba3cebe2-1f41-4dfa-94cf-810a2a5ee556
Jan 12, 2019 19:10:06.284 [0x7f46abfff700] DEBUG - Job running: EAE_ROOT='/tmp/pms-f0b56ae4-3450-498e-8560-bbb1948525d7/EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='/var/lib/plexmedias
erver/Library/Application\ Support/Plex\ Media\ Server/Codecs/531e313-1328-linux-ubuntu-x86_64/' XDG_CACHE_HOME='/var/lib/plexmediaserver/Library/Application Support/Plex Media Se
rver/Cache' XDG_DATA_HOME='/usr/lib/plexmediaserver/Resources' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/usr/lib/plexmediaserver/Plex Transcoder' '-noaccurate_seek' '-ignore_unknown'
'-scan_all_pmts' '-1' '-rw_timeout' '30000000' '-fflags' '+discardcorruptts+fillwallclockdts' '-probesize' '10000000' '-i' 'http://192.168.1.30:5004/auto/v110' '-map' '0:V?' '-cod
ec:V' 'copy' '-map' '0:a?' '-codec:a' 'copy' '-copypriorss:a' '0' '-map' '0:s?' '-codec:s' 'copy' '-segment_format' 'mpegts' '-f' 'ssegment' '-individual_header_trailer' '0' '-seg
ment_time' '1' '-segment_start_number' '0' '-segment_time_delta' '0.25' '-segment_list' 'http://127.0.0.1:32400/video/:/transcode/session/ba3cebe2-1f41-4dfa-94cf-810a2a5ee556/c8fe
7f58-cadf-4a3f-b5d3-e44bb0bb123a/seglist' '-segment_list_type' 'csv' '-segment_list_size' '2147483647' '-segment_list_separate_stream_times' '1' '-max_delay' '5000000' '-map_metad
ata' '-1' '-map_chapters' '-1' 'media-%05d.ts' '-y' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-xioerror' '-progressurl' 'http://127.0.0.1:32400/video/:/transcode/se
ssion/ba3cebe2-1f41-4dfa-94cf-810a2a5ee556/c8fe7f58-cadf-4a3f-b5d3-e44bb0bb123a/progress'
Jan 12, 2019 19:10:06.290 [0x7f46abfff700] DEBUG - Jobs: Starting child process with pid -1
Jan 12, 2019 19:09:41.298 [0x7f46a2ffe700] DEBUG - [Universal] Using local file path instead of URL: /Storage/TV/Cops/Season 31/cops.s31e13.720p.hdtv.x264-w4f.mkv
Jan 12, 2019 19:09:41.299 [0x7f46a2ffe700] DEBUG - Job running: EAE_ROOT='/tmp/pms-f0b56ae4-3450-498e-8560-bbb1948525d7/EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='/var/lib/plexmedias
erver/Library/Application\ Support/Plex\ Media\ Server/Codecs/531e313-1328-linux-ubuntu-x86_64/' XDG_CACHE_HOME='/var/lib/plexmediaserver/Library/Application Support/Plex Media Se
rver/Cache' XDG_DATA_HOME='/usr/lib/plexmediaserver/Resources' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/usr/lib/plexmediaserver/Plex Transcoder' '-codec:0' 'h264' '-codec:1' 'ac3' '-
ss' '0' '-noaccurate_seek' '-probesize' '10000000' '-i' '/Storage/TV/Cops/Season 31/cops.s31e13.720p.hdtv.x264-w4f.mkv' '-filter_complex' '[0:1] aresample=async=1:ocl='\''stereo'\
'':osr=48000:rematrix_maxval=10.000000dB[0]' '-map' '0:0' '-codec:0' 'copy' '-map' '[0]' '-metadata:s:1' 'language=eng' '-codec:1' 'aac' '-b:1' '256k' '-f' 'dash' '-min_seg_durati
on' '5000000' '-skip_to_segment' '1' '-time_delta' '0.0625' '-manifest_name' 'http://127.0.0.1:32400/video/:/transcode/session/b08f2y5skglb02uvbtcc1ge7/ac012119-0a3e-47c0-887f-77a
58de33d6f/manifest' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-map_chapters' '-1' 'dash' '-map' '0:2' '-metadata:s:0' 'language=eng' '-codec:0' 'ass' '-f' 'segment' '-
segment_format' 'ass' '-segment_time' '1' '-segment_header_filename' 'sub-header' '-segment_start_number' '0' '-segment_list' 'http://127.0.0.1:32400/video/:/transcode/session/b08
f2y5skglb02uvbtcc1ge7/ac012119-0a3e-47c0-887f-77a58de33d6f/seglist?stream=subtitles' '-segment_list_type' 'csv' '-segment_list_size' '2147483647' '-segment_list_separate_stream_ti
mes' '1' '-segment_format_options' 'ignore_readorder=1' 'sub-chunk-%05d' '-start_at_zero' '-copyts' '-vsync' 'cfr' '-y' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-p
rogressurl' 'http://127.0.0.1:32400/video/:/transcode/session/b08f2y5skglb02uvbtcc1ge7/ac012119-0a3e-47c0-887f-77a58de33d6f/progress'
Jan 12, 2019 19:09:41.306 [0x7f46a2ffe700] DEBUG - Jobs: Starting child process with pid -1

Both of the above jobs failed, for seemingly no reason. I restarted plexmediaserver, and now it seems to be working as intended again:

Jan 12, 2019 19:12:36.762 [0x7f4a09fff700] DEBUG - Found session GUID of ff9cilepx2mkq4x5ttf4molh in session start.
Jan 12, 2019 19:12:36.762 [0x7f4a09fff700] DEBUG - Cleaning directory for session ff9cilepx2mkq4x5ttf4molh ()
Jan 12, 2019 19:12:36.762 [0x7f4a09fff700] DEBUG - Starting a transcode session ff9cilepx2mkq4x5ttf4molh at offset -1.0 (state=3)
Jan 12, 2019 19:12:36.765 [0x7f4a09fff700] DEBUG - [Universal] Using local file path instead of URL: /Storage/TV/Cops/Season 31/cops.s31e13.720p.hdtv.x264-w4f.mkv
Jan 12, 2019 19:12:36.766 [0x7f4a09fff700] DEBUG - Job running: EAE_ROOT='/tmp/pms-f15cdb53-890d-4673-a44d-9bbe0b946301/EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='/var/lib/plexmedias
erver/Library/Application\ Support/Plex\ Media\ Server/Codecs/531e313-1328-linux-ubuntu-x86_64/' XDG_CACHE_HOME='/var/lib/plexmediaserver/Library/Application Support/Plex Media Se
rver/Cache' XDG_DATA_HOME='/usr/lib/plexmediaserver/Resources' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/usr/lib/plexmediaserver/Plex Transcoder' '-codec:0' 'h264' '-codec:1' 'ac3' '-
ss' '0' '-noaccurate_seek' '-probesize' '10000000' '-i' '/Storage/TV/Cops/Season 31/cops.s31e13.720p.hdtv.x264-w4f.mkv' '-filter_complex' '[0:1] aresample=async=1:ocl='\''stereo'\
'':osr=48000:rematrix_maxval=10.000000dB[0]' '-map' '0:0' '-codec:0' 'copy' '-map' '[0]' '-metadata:s:1' 'language=eng' '-codec:1' 'aac' '-b:1' '256k' '-f' 'dash' '-min_seg_durati
on' '5000000' '-skip_to_segment' '1' '-time_delta' '0.0625' '-manifest_name' 'http://127.0.0.1:32400/video/:/transcode/session/ff9cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882
455591dd1/manifest' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-map_chapters' '-1' 'dash' '-map' '0:2' '-metadata:s:0' 'language=eng' '-codec:0' 'ass' '-f' 'segment' '-
segment_format' 'ass' '-segment_time' '1' '-segment_header_filename' 'sub-header' '-segment_start_number' '0' '-segment_list' 'http://127.0.0.1:32400/video/:/transcode/session/ff9
cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882455591dd1/seglist?stream=subtitles' '-segment_list_type' 'csv' '-segment_list_size' '2147483647' '-segment_list_separate_stream_ti
mes' '1' '-segment_format_options' 'ignore_readorder=1' 'sub-chunk-%05d' '-start_at_zero' '-copyts' '-vsync' 'cfr' '-y' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-p
rogressurl' 'http://127.0.0.1:32400/video/:/transcode/session/ff9cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882455591dd1/progress'
Jan 12, 2019 19:12:36.771 [0x7f4a09fff700] DEBUG - Jobs: Starting child process with pid 3313
Jan 12, 2019 19:12:38.272 [0x7f4a06fff700] DEBUG - Request: [127.0.0.1:56212 (Loopback)] PUT /video/:/transcode/session/ff9cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882455591dd1/progress?status=startup (11 live) Signed-in Token (Cdchris12)
Jan 12, 2019 19:12:38.273 [0x7f4a22bfe700] DEBUG - Completed: [127.0.0.1:56212] 204 PUT /video/:/transcode/session/ff9cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882455591dd1/progress?status=startup (11 live) 0ms 203 bytes (pipelined: 1) (range: bytes=0-)
Jan 12, 2019 19:12:38.274 [0x7f4a06fff700] DEBUG - Request: [127.0.0.1:56212 (Loopback)] PUT /video/:/transcode/session/ff9cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882455591dd1/progress?status=opening (11 live) Signed-in Token (Cdchris12)
Jan 12, 2019 19:12:38.274 [0x7f4a22bfe700] DEBUG - Completed: [127.0.0.1:56212] 204 PUT /video/:/transcode/session/ff9cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882455591dd1/progress?status=opening (11 live) 0ms 203 bytes (pipelined: 2) (range: bytes=0-)
Jan 12, 2019 19:12:38.347 [0x7f4a06fff700] DEBUG - Request: [127.0.0.1:56212 (Loopback)] PUT /video/:/transcode/session/ff9cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882455591dd1/progress?status=opened (11 live) Signed-in Token (Cdchris12)
Jan 12, 2019 19:12:38.348 [0x7f4a233ff700] DEBUG - Completed: [127.0.0.1:56212] 204 PUT /video/:/transcode/session/ff9cilepx2mkq4x5ttf4molh/7dbc916c-ae62-45a3-b1fa-882455591dd1/progress?status=opened (11 live) 0ms 203 bytes (pipelined: 3) (range: bytes=0-)

As you can see, the transcoder process is simply failing to start. Is that process logged anywhere? Is it possible for me to prefer the NVENC transcoder instead of the QuickSync transcoder to see if that is more stable?

Rather than just an excerpt of the log showing me the transcoder being invoked, may I see the full log?

  1. Stop scanning.
  2. Restart PMS
  3. Start the scan
  4. As soon as it ‘grinds to a halt’ ,
  5. Settings - Server - Troubleshooting - Download Logs
  6. Attach the ZIP

Plex Media Server Logs_2019-01-12_21-50-01.zip (2.8 MB)

Literally just happened. It’s become QUITE frequent lately; I can’t get through more than 2 or 3 hours without plex refusing to serve media. All I have to do to bring it back for a bit is restart it and limp it along.

Thanks for the logs.

  1. Matching and retrieving metadata is a largely single-threaded task. If you notice, PMS will not start scanning the next library until the current one is done. Further, It will only match a few at a time. It has an internal queue. It averages out to about a depth of 3. (scan/match, retrieve data, format & store stages). Throughout all you have shown, PMS is still loading this library as playback attempts are ongoing.

  2. Yes you have a lot of bulk CPU power across all those cores but no single core is > 1500 passmarks (8261 passmarks / 6 cores). A 2012 core i7-3xxx series has more horsepower - 8332 passmarks / 4 cores)
    https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+X5675+%40+3.07GHz&id=1309

  3. Being in a VM, there is no way to evaluate and compare the resource demands of other guest OS’s on the PMS guest OS. It might be actually getting only a fraction of what the Xeons are capable of.

Other things

  1. Can you give me a count of how many Video items and how many Music items you’re adding (or have to add in total) to the library while this is happening so I can try to figure out how we got here?
    If the problem is PMS becoming very non-responsive while matching music, this well known and very easily mitigated.

  2. Are you having PMS generate chapter images / thumbnails for your video files? (this is in the “Advanced” tab under each Library section. Those files are BIF files and incredibly CPU intensive to generate. They will bog down the server really quickly. This too can be mitigated.