Plex has been crashing frequently for me for the past few months. Sometimes it is once or twice a day and other times it could be once a week. I always update to the latest release when they come out. Most of the time when plex crashes the plex icon is still in the tray by the clock and no crash log is created. When it crashes all of the transcodes stop and browsing the server from the web interface displays a not responding error and I usually have to end the plex media server.exe process in task manager even after exiting from the tray icon. I have reinstalled the operating system but the problem remains.
Server:
Windows Server 2016 64bit
96GB Memory
Dual E5-2660 Processors
My Plex database file is pretty large at 545MB. (In case its relevant)
The server last crashed sometime after 1:30am this morning. These logs are from that crash.
Server Logs Attached Below:
I’ve been having a very similar issue. I enabled debugging in my logs and nothing is standing out during the times when the server becomes unresponsive. I was hopping on here about to start a thread about my issue.
I do have a pretty heavily used server (10-15 users during busy times). But I also notice that I have enough spare cpu/ram available during the times when it crashes so it’s tough to determine a correlation.
When you say crash, do you mean the Plex Server application shuts down? If that’s the case, we need the crash logs to help diagnose what’s happening. You have to grab the logs before you restart Plex Server. If the application is still running then Plex hasn’t actually crashed, so no crash logs will be produced. Please refer to the link below:
Scanning the log you did provide, there are a ton of errors, ranging from missing files to slow database queries to access denied to transcoder directories. Also, if you are trying to use hardware transcoding, you have errors related to your NVIDIA card where it can’t load the nvcuda.dll file.
Start off by optimizing your database, and make sure to grab the crash logs the next time this happens.
The Plex Server application did shut down this time and I grabbed the logs before starting it back up but there weren’t any crash logs other than what I have attached in this thread. Usually the Plex Server application doesn’t shut down and I have to end the process. I have now unchecked the hardware transcode option as I don’t have hardware that will utilize it.
Plex crashed again. I have attached the log for this crash. Plexpy alerted me that Plex Media Server stopped working at 21:18. I had to manually exit out of Plex on the taskbar and go into Task Manager and end the Process before I could get it to start back up.
I’m going to do some research on this one. My knee jerk reaction is that your system is buckling under the stress of 15-20 simultaneous transcode operations.
Sometimes it crashes when only 7 to 10 people are streaming. They don’t all start their streams at the same time so cpu might go up to 100% for a few seconds at a time then hover around 20% most of the time. Older versions of plex 4+ months ago would run for months without issue with the same stream volume.
I have even had it crash at 4am in the morning when maybe one person was streaming but this is a more rare occurrence.
EDIT: I have the database on a SSD and the transcodes on a PCIE SSD.
You said this has been going on for months. Was there anything that coincides with the time when the crashing started? New hardware or drivers perhaps?
Like I mentioned, I’m going through the same thing. Crashes unexpectedly. Nothing in the crash reports folder.
Seems to only be happening over the last 2 weeks. Happens every few hours. Windows 10. Dedicated machine. Very few streams. Maybe 1-2 at a time.
Logs attached.
Really appreciate the help.
EDIT: For what it’s worth, I set up PlexPy so I’d know when it crashed. It seems to have crashed around 1:57PM Eastern Time. I thought that might be helpful in understanding the logs.
@kegobeer-plex said:
You said this has been going on for months. Was there anything that coincides with the time when the crashing started? New hardware or drivers perhaps?
Nothing changed other than Plex Media Server being updated. The server had remained the same for over a year until I reinstalled Server 2016 to try and fix this issue but the problem remained. I have attached the full log folder below.
@thompry said:
Plex crashed again. I have attached the log for this crash. Plexpy alerted me that Plex Media Server stopped working at 21:18. I had to manually exit out of Plex on the taskbar and go into Task Manager and end the Process before I could get it to start back up.
The transcoder crashed, not PMS.
Dec 08, 2017 21:15:54.666 [13936] DEBUG - Using default transcode duration of 120 minutes
Dec 08, 2017 21:15:54.666 [13936] DEBUG - Started session successfully: fdf5ea4dc0a1633ad0c2826324d060f6
Dec 08, 2017 21:15:54.667 [31588] DEBUG - Jobs: 'C:\Program Files (x86)\Plex\Plex Media Server\PlexTranscoder.exe' exit code for process 30284 is 1
Dec 08, 2017 21:15:54.669 [7740] DEBUG - [TranscodeOutputStream] Input processing thread started at offset 0 for -1 bytes.
Dec 08, 2017 21:15:54.669 [31588] DEBUG - Jobs: 'C:\Program Files (x86)\Plex\Plex Media Server\PlexTranscoder.exe' exit code for process 30284 is 1
Dec 08, 2017 21:15:54.669 [31588] DEBUG - Streaming Resource: Terminating session 182A09E8:fdf5ea4dc0a1633ad0c2826324d060f6 which is using 3953kbps of WAN bandwidth. Used is now 72836kbps
Dec 08, 2017 21:15:54.669 [31588] DEBUG - Streaming Resource: Terminating session 182A09E8:fdf5ea4dc0a1633ad0c2826324d060f6 which is using transcoder slot. Used slots is now 10
Dec 08, 2017 21:15:54.669 [31588] DEBUG - Streaming Resource: Terminated session 182A09E8:fdf5ea4dc0a1633ad0c2826324d060f6 with reason Conversion failed. The transcoder crashed or failed to start up.
Dec 08, 2017 21:15:54.669 [21620] DEBUG - Killing job.
Dec 08, 2017 21:15:54.669 [21620] DEBUG - Job was already killed, not killing again.
Dec 08, 2017 21:15:54.670 [21620] DEBUG - Stopping transcode session fdf5ea4dc0a1633ad0c2826324d060f6
What was being played at that time?
If you are uncertain, please recreate the failure, post that log set plus the XML (hover over item - get info - view XML). This will allow me to know what the transcoder was basing its actions on
ChuckPA, do you mind looking at my logs? I’m having a similar issue. Or is it bad form for me to hijack this thread? If so, I can start a new one. Thanks.
@brndnkjns said:
ChuckPA, do you mind looking at my logs? I’m having a similar issue. Or is it bad form for me to hijack this thread? If so, I can start a new one. Thanks.
It’s generally bad form however, in this case, what you’re experiencing are hangs. The database reports at locked. I see you are running 1.10.1. I recommend you stop PMS, reboot the machine, reinstall the previous version (1.10.0) which is public and verify the same behavior.
Dec 09, 2017 13:52:59.858 [9568] DEBUG - Completed: [127.0.0.1:58586] 206 PUT /video/:/transcode/session/lrdj1p5h8ybuck2h023gnwmi/e8a381cc-d8ea-4a0b-87e0-5ea53f45e130/progress?progress=12.4&size=-22&remaining=65167&vdec_packets=25470&vdec_sw_ok=25460&vdec_hw_status=0 (14 live) 4ms 342 bytes
Dec 09, 2017 13:52:59.983 [5728] ERROR - Soci Exception handled: sqlite3_statement_backend::loadOne: database is locked
Dec 09, 2017 13:52:59.983 [9568] DEBUG - Completed: [192.168.1.43:41007] 500 GET /:/timeline?hasMDE=1&ratingKey=62337&key=%2Flibrary%2Fmetadata%2F62337&state=playing&playQueueItemID=29750&time=882532&duration=8595630 (14 live) TLS GZIP 67449ms 405 bytes (pipelined: 1)
Dec 09, 2017 13:52:59.983 [9568] DEBUG - Auth: authenticated user 1 as brndnkjns
Dec 09, 2017 13:52:59.983 [7692] DEBUG - Request: [192.168.1.43:41007 (Subnet)] GET /:/timeline?hasMDE=1&ratingKey=62337&key=%2Flibrary%2Fmetadata%2F62337&state=playing&playQueueItemID=29750&time=932537&duration=8595630 (14 live) TLS GZIP Signed-in Token (brndnkjns)
Dec 09, 2017 13:52:59.983 [7692] DEBUG - Client [zzjwlkwmqg0y2lunj9va8xgv] reporting timeline state playing, progress of 932537/8595630ms for guid=, ratingKey=62337 url=, key=/library/metadata/62337, containerKey=, metadataId=62337
Dec 09, 2017 13:53:00.421 [10072] DEBUG - Request: [127.0.0.1:58587 (Loopback)] PUT /video/:/transcode/session/lrdj1p5h8ybuck2h023gnwmi/e8a381cc-d8ea-4a0b-87e0-5ea53f45e130/progress?progress=12.4&size=-22&remaining=57949&vdec_packets=25471&vdec_sw_ok=25461&vdec_hw_status=0 (15 live) Signed-in Token (brndnkjns)
Dec 09, 2017 13:53:00.421 [9572] DEBUG - Completed: [127.0.0.1:58587] 206 PUT /video/:/transcode/session/lrdj1p5h8ybuck2h023gnwmi/e8a381cc-d8ea-4a0b-87e0-5ea53f45e130/progress?progress=12.4&size=-22&remaining=57949&vdec_packets=25471&vdec_sw_ok=25461&vdec_hw_status=0 (15 live) 2ms 342 bytes
Dec 09, 2017 13:53:00.983 [5728] DEBUG - Request: [127.0.0.1:58588 (Loopback)] PUT /video/:/transcode/session/lrdj1p5h8ybuck2h023gnwmi/e8a381cc-d8ea-4a0b-87e0-5ea53f45e130/progress?progress=12.4&size=-22&remaining=58977&vdec_packets=25473&vdec_sw_ok=25463&vdec_hw_status=0 (14 live) Signed-in Token (brndnkjns)
Dec 09, 2017 13:53:00.983 [9572] DEBUG - Completed: [127.0.0.1:58588] 206 PUT /video/:/transcode/session/lrdj1p5h8ybuck2h023gnwmi/e8a381cc-d8ea-4a0b-87e0-5ea53f45e130/progress?progress=12.4&size=-22&remaining=58977&vdec_packets=25473&vdec_sw_ok=25463&vdec_hw_status=0 (14 live) 2ms 342 bytes
Dec 09, 2017 13:53:01.077 [10460] WARN - Waited one whole second for a busy database.
Dec 09, 2017 13:53:01.202 [9612] WARN - Waited one whole second for a busy database.
Dec 09, 2017 13:53:01.280 [8172] WARN - Waited one whole second for a busy database.
Dec 09, 2017 13:53:01.546 [6156] DEBUG - Request: [127.0.0.1:58589 (Loopback)] PUT /video
