Server Version#: Version 1.31.3.6868
Player Version#: Windows / Android / Xbox
I upgraded my Plex Server to Version 1.31.3.6868 last week, and ever since then, I have been getting random crashes. Plex Server stops running, and I have to manually restart it to regain connectivity.
Are there any known bugs for Windows 10 & Plex Version 1.31.3.6868?
This is the Plex Web version which is displayed under the:
Settings >
Plex Web >
General tab
To find the Plex Server Version, please navigate to:
Settings > (then ensure you have selected the correct Plex Server in the dropdown list)
Settings > (Settings is a heading found just over half way down on the Settings page Sidebar)
General
Your Plex Server version should look something like this:
I’ve been having the same issue on my QNAP TVS-872XT. It crashes all the time now. Literally several times a day for no reason. I have to restart my server and Plex in the apps for it to start working again. It’s been doing it for at least a week now. Not sure which version it was that caused it but it continues to do so. Never had experienced this issue before…Plex has always been SOLID up until very recently.
Been having random restarts for more than a week now, even when the server is sitting idle, so I know its not crashing for being under stress.
I’ve turned off all of the intro / credit detection on all libraries, as suggested in another thread, but still waking up every day to a dead server.
Would appreciate any help. Attached logs are from right after a restart. I’m not much of a log reader, but I do see that the server was stuck/cycling/looping on scanning one item (Doctor Sleep) for over an hour. Not sure, but that doesn’t seem right.
I have not had the issue reoccur yet this week. Strange that it happened frequently, and as soon as I open a Support Topic…nothing. Hopefully the logs that were posted in here are looked at by Devs to help stabilize the software a bit. I will update with logs of my own once the issue recurs.
I am seeing a stream of: WARN - [Notify] Received unexpected inotify event: 1073750016 (7, Couldn't connect to server) (Failed to connect to 127.0.0.1 port 39673: Connection refused)
You might also try moving the album Doctor Sleep outside of plex scan and empty your trash, and see if that provides any change.
Some observations and to add to feedback from @dbirch
You have an audiobooks agent - does it have logs in the /Logs/PMS Plugin Logs directory ?
(under var/lib/plexmediaserver/Library/Application Support/Plex Media Server)
There was some heavy activity relating to that agent before the failures for 127.0.0,.1 to port 39673
Apr 05, 2023 06:44:40.543 [0x7f755fbf9b38] WARN - [HttpClient/HCl#123ed] HTTP error requesting GET http://127.0.0.1:39673/system/agents/media/get?guid=com%2Eplexapp%2Eagents%2Eaudiobooks%3A%2F%2FB00DEL0Z9I%3Flang%3Den&mediaType=9&url=metadata%3A%2F%2Fposters%2Fcom%2Eplexapp%2Eagents%2Elocalmedia_282cefc3e6c45187b129a8042c400292fae69481 (7, Couldn't connect to server) (Failed to connect to 127.0.0.1 port 39673: Connection refused)
One aspect to look into is to see if we are exhausting the dynamic port numbers pool. Other is to see if that agent process crashed out. When these failures occur - grab all the logs including the plugin logs and also using netstat / lsof get list of all connections and ports being used and what ports being listened to
When you download logs we do not include logs for any user added agents/plugins - so these need to be copied out manually and zipped
Also I notice a couple of daily crashes - Logs do not go back that far - perhaps you could look for them and zip and and send to me privately
There is a lot of log entries showing database sessions being held for long time - Unfortunately the logs do not go back to when these started
The earliest log entry relating to these was
Apr 05, 2023 04:54:15.503 [0x7f75357edb38] DEBUG - [Req#10a6cf] 31 threads are waiting on db connections held by threads: 0x7f7514f26b38,0x7f75182cdb38,0x7f7545ee5b38,0x7f753e2c7b38,0x7f7522c20b38,0x7f7513f7bb38,0x7f752376db38,0x7f7533770b38,0x7f754610db38,0x7f751ff78b38,0x7f7539aeab38,0x7f751ec96b38,0x7f7532ffcb38,0x7f7512e8db38,0x7f753ea17b38,0x7f752f26db38,0x7f7524089b38,0x7f751fa5eb38,0x7f751a641b38,0x7f752441fb38
Which was at the beginning of the oldest log file available - so increasing number of log files may help
As an experiment - you could remove that audiobooks plugin and see how the server performs after that
@sa2000 Thanks for the suggestions. Sorry for the delayed response, but I was on vacation with my family without access to the server.
I just bumped up the logs num to 20 and removed the audiobooks bundle. Will see if that impacts anything.
I’m guessing its been a few days and the /tmp folder gets cleared out, but there’s no .dpm files in there.
@dbirch removing Doctor Sleep out of the audiobooks library per your suggestion. Actually, I just replaced the hard drive that my audiobooks library was on, and haven’t moved the library back. The crashes started before I swapped out the drive, but I’m eliminating the Audiobooks library and scanner from the equation entirely.
if no more crashes, suggest bringing the audiobooks bundle back and after a crash gets the logs together with the audiobooks plugin logs and see if you can find .dmp files in /tmp for times of the crashes
Well, I was hoping that we’d done enough to stop the crashes, but no such luck.
Not sure if it gives any clues as to the underlying issue, but when it crashed today, I did not get a notification from Tautulli that the server had gone down. But after rebooting, I did get the notification that it was back up.
The provided logs were from Plex Media Server 1.31.3.6868
There is no evidence in the logs of an actual crash. The Plex Media Server process was running until it was shutdown at 15:40 and relaunched at 15:41
Apr 10, 2023 15:40:56.153 [0x7f0d81df9b38] DEBUG - Shutting down with signal 15 (Terminated)
Apr 10, 2023 15:40:56.153 [0x7f0d81df9b38] DEBUG - Ordered to stop server.
There is also no indication of any hung request and incoming requests were being processed
There was a scanner process whilst doing loudness analysis on a specific media item - that was at 01:42 am on the 10th.
I am not sure if the dmp file is still there - this is a separate issue and is probably media file specific /tmp/394d0efc-0781-4483-18896a96-b59621bc.dmp
Could you try the latest public release and beta to see if the crashes come back and get me new server logs and details of what the symptom was at the time
Current beta 1.32.1.6954
Current public 1.32.0.6950
My apologies if “crash” isn’t the right term. From an end-user standpoint, when I go to my Plex home page, it can’t reach any of my libraries.
I know all of my NASes are running and accessible to my Ubuntu machine and Plex, since nothing changed on that end. The Ubuntu machine is still running, as I’m able to SSH into it in order to either shut down and restart the PMS.service, which generally solved the connectivity problem, or reboot the machine, which always solved the connectivity problem.
Will update the PMS and send crash reports when they come. That specific .dmp file is no longer in the /tmp folder. If its helpful, I’ve attached the only .dmp file in there. 3f4d19a7-82a4-4705-55ac38a5-79a10254.zip (41.5 KB)