Server Version#: DSM 7.1.1-42962 Update 4
Player Version#: 1.29.2.6364-7000
Logs.zip (4.2 MB)
Plex keeps shutting off overnight for the last few days. This happened previously and it destroyed my database. Chuck helped me previously and we thought it was down to the Synology SSD’s corrupting the DB, but I don’t use SSD;s since that incident.
I can see some errors happening around midnight in the logs, but it’s not clear to me what it means. Can anyone give me a pointer?
The logs do not show any crashes or restarts of Plex Media Server.
They show Plex running from July 1, 22:34 (top of Plex Media Server.5.log) to July 3, 12:00 (bottom of Plex Media Server.log), when it was manually stopped.
The next time Plex shuts down, restart it, wait 5 minutes for it to fully start, then pull a new set of log files.
Maybe I did pull it too fast. I’ve re-uploaded the logs now.
Logs.zip (3.8 MB)
When did the problem occur? I’m not seeing anything that looks like a problem in the log files.
The only time Plex stops running is Jul 3 at 12:00. Signal 15 is an orderly shutdown. This is near the bottom of Plex Media Server.1.log. Plex Media Server.2.log to .5.log (going back in time) show Plex continuously running.
Jul 03, 2023 12:00:02.494 [0x7fe22def0b38] DEBUG - Shutting down with signal 15 (Terminated)
Jul 03, 2023 12:00:02.494 [0x7fe22def0b38] DEBUG - Ordered to stop server.
Jul 03, 2023 12:00:02.494 [0x7fe231ab70d0] DEBUG - Stopping server...
...
Jul 03, 2023 12:00:03.309 [0x7fe231ab70d0] DEBUG - Database: Shutting down.
Plex starts at 12:04 (top of Plex Media Server.log):
Jul 03, 2023 12:04:42.329 [0x7f3e3325a0d0] DEBUG - BPQ: [Idle] -> [Starting]
The most recent log entry (bottom of Plex Media Server.log) shows normal streaming.
Jul 03, 2023 13:33:08.639 [0x7f3e270c9b38] DEBUG - [Req#4060] Play progress on 21838 'F1 Mexico Quali' - got played 1054739 ms by account 1!
Jul 03, 2023 13:33:08.640 [0x7f3e270c9b38] DEBUG - [Req#4060] [Now] User is bparone (ID: 1)
Jul 03, 2023 13:33:08.640 [0x7f3e270c9b38] DEBUG - [Req#4060] [Now] Device is iOS (iPad).
Jul 03, 2023 13:33:08.640 [0x7f3e270c9b38] DEBUG - [Req#4060] [Now] Profile is iOS
Jul 03, 2023 13:33:08.640 [0x7f3e270c9b38] DEBUG - [Req#4060] [Now] Updated play state for /library/metadata/21838.
Jul 03, 2023 13:33:08.640 [0x7f3e270c9b38] DEBUG - [Req#4060] Statistics: (C8A6E196-BBA0-4ACB-BED6-C71D01C3B517) Reporting active playback in state 0 of type 1 (scrobble: 0) for account 1
Jul 03, 2023 13:33:08.649 [0x7f3e2f24eb38] DEBUG - Completed: [192.168.30.127:63598] 200 GET /:/timeline?bufferedTime=182&col=32&context=browse%3Ahub.video.recent&duration=8877459&key=%2Flibrary%2Fmetadata%2F21838&location=lan&playQueueItemID=19361&playbackTime=522690&ratingKey=21838&row=32&state=playing&time=1054739 (10 live) TLS GZIP 1145ms 495 bytes (pipelined: 109)
Jun 30th and July 1st & 2nd it wasn’t running in the morning.
I’m going to take a wild guess here for a second as I also had recurring issue of PMS crashing on my Synology on what appeared to be a recurring schedule.
Do you have any DVR recordings scheduled? You’re running an older version of PMS, around the timeframe of that version, there were some changes made to the DVR system that introduced this crash.
The solution that fixed it for me was deleting and re-creating the DVR recordings.
Also, I would suggest updating your PMS install to the latest version 1.32.4.7195
I don’t use DVR. In fact, I didn’t even know Plex offers this. I remained on the PMS version as my understanding was it was a very stable version.
Good to know. Given the version of PMS you are running is seven months behind, upgrading should be the first troubleshooting step.
I have 1.32.4.7195 running on two separate Synologys with no issues.
I’m not doubting that you’re having trouble. However, it is not in the log files.
It is very easy to see when PMS starts/restarts. The Plex Media Server.log files all get rolled, and DEBUG - BPQ: [Idle] -> [Starting] appears at the top of the file.
Plex Media Server ran continuously from Jul 1, 23:58 until it was manually stopped on July 3, 12:00.
First & last entries in log files, going back in time.
Plex Media Server.log Jul 03, 2023 13:33:08.649 Jul 03, 2023 12:04:42.362 Plex Manually Started
Plex Media Server.1.log Jul 03, 2023 12:00:03.309 Jul 03, 2023 01:11:52.144 Plex Manually Stopped
Plex Media Server.2.log Jul 03, 2023 01:11:52.074 Jul 02, 2023 18:52:16.414
Plex Media Server.3.log Jul 02, 2023 18:52:16.339 Jul 02, 2023 16:20:38.554
Plex Media Server.4.log Jul 02, 2023 16:20:38.324 Jul 02, 2023 02:01:11.077
Plex Media Server.5.log Jul 02, 2023 02:01:11.056 Jul 01, 2023 23:58:54.083
@bparone DO NOT install 1.32.4.7195 or 1.32.5.7210 (current beta).
You have a DS920+ with a Celeron J4125 CPU.
Hardware accelerated transcoding is broken for J4xxx CPUs in the current public and beta release.
1.29.2.6364 is a very stable release.
Do not upgrade past 1.32.1.6999 or you will lose hardware accelerated transcoding (download link below).
Suggest you read the release notes to see if there are any features / fixes you need.
I wasn’t planning to. I only upgrade when there is a known good version and it’s been stable for quite some time.
Ok, then upgrade to 1.32.1.6999.
A fix is in inbound within an upcoming release for the hardware transcoding fix for the Celeron CPU linux deployments.
As you previously pointed out in the logs, it does not look like there are any crashes, but there are shutdown requests.
I understand not updating to the latest version until Hardware Transcoding is fixed, but anytime there is an issue that is tricky to identify and you are on an older version of the software, updating is an easy first step when troubleshooting.
If 1.32.1.6999 is stable with Hardware Transcoding, It would be worth trying.
Answers below.
Suggestion:
This will make it easier to spot the shutdown due to the problem.
Whilst I can’t help with the cause, I’ve got snapshots setup on my Synology DS720+ for the /volume1/PlexMediaServer folder. Its been used once for recovery and had no issues.
Naturally its not as clean as the controlled stop + DB Consistency tasks, but perhaps its a safety-net worth trying? You’ll need to be using btrfs…
Good luck!
I will try this and report back. Thanks for the suggestion.
Seems like a reasonable config to ensure better restore reliability. What’s the cost of the snapshots (in terms of storage primarily, but also CPU/RAM when running the job itself)?
Good to know. I have been having weird issues and wonder if this is part of the cause.
So my /PlexMediaServer folder is about 156G, with recent snapshots averaging about 2G. However, tdarr is busy doing its thing so the normal snapshot size I expect would be much smaller.
In terms of snapshot duration / CPU spike - its seems to be sub-second when doing via the UI. I suspect its some magic thanks to btrfs that makes it super quick.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
