As the title suggests every time the scheduled tasks on the PMS start, the server becomes unresponsive.
sudo systemctl status plexmediaserver
shows the server as running, but it’s not accessible on any client and is showing the server as offline. Only a manual reboot solves it.
Furthermore, there’s nothing to be found in the logs, as the server just crashes and doesn’t print anything about it. This didn’t happen on previous versions.
I’m also running Ubuntu 20.04 on 1.26.1.5798. If you don’t already have debugging enabled, I think you should be able to enable it by just adding the option to your Preferences.xml file and restarting the service (if you are unable to do so via the webUI). From there you can watch the logs via terminal with
tail -f /var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server/Logs/Plex Media Server.log
What does the top command show when this is happening? Does Plex have a core of your CPU pinned?
I was having a similar problem last night - only I was migrating data between servers and rearranging mount points, so I was having to re-scan files. My similar problem was happening when I opps’d and re-enabled sonic analysis when media is added (before I finished mucking with my music) so it started doing sonic analysis on all my albums at once, that brought the server to it’s knees - this also happened after I’d finished everything with my libraries and went to optimize the database, while the optimization was happening I couldn’t do anything (understandable since I just rearranged 88TB worth of data).
I just left the server to do it’s thing and after everything finished, it’s now smooth as silk.
I can’t say that this is the same problem you’re having, but it’s at least some things to look for.
Thank you for chiming in. As for the logs I just started the scheduled tasks and debugging is enabled. Will check any moment what the top comment says.
As for the music analysis, I don’t think this is the culprit, as the analysis has already finished for my music library, afaik at least.
It has definitely to do with any task that is running during scheduled maintenance, not sure which one though.
If it’s, let’s say, 19:04 and I set the scheduled tasks to 19:00, do they start then? If they do maybe my problem is already solved, as the server is still accessible. Not sure if the scheduled tasks already started or not though.
There’s a difference (obviously ) between non-responsive and crashing.
If the processes are still running (all of them) then it’s not crashing.
There are situations where, especially if scheduled tasks has a lot to do, the server won’t be responsive.
The most common one is database optimization.
The next most common one is extended (detailed) media analysis.
If you have a large library it can take several minutes to optimize the DB.
Media analysis , depending on what’s being analyzed, will put a very noticeable load on the system.
Per your other question about setting scheduled tasks to run at 19:00 hrs,
It will start at that time. That’s why the default is set for 2am → 5am (a 3 hour window to complete any work needed)
I see where you have been restarting PMS when it’s non-responsive.
Doing this will cause it to ignore anything not completed.
To test if PMS is “still there”,
curl http://127.0.0.1:32400/identity
It will respond with XML. if the http server is operating.
Are you indeed running scheduled tasks at 19:00 hrs ?
Yeah I forgot to edit the last “crashing” part, it’s unresponsive, not crashing, true.
At the moment I’ve set the scheduled tasks to 18pm and they should be running for 42 minutes now, as it’s 18:42 over here, without becoming unresponsive, so I’m not quite sure how I can reproduce the issue. Or did the issue just vanish?
Maybe it really just was an extensive task that already finished (or was aborted?), not sure
That is a very good hint btw! Will do this if the server happens again to become unresponsive. For the moment all seems to be fine
So, the issue just arose again during the scheduled tasks. How long do you think do I need to let this work? It’s already been up for 90 minutes, while the server is still not accessible
If I do
sudo systemctl status plexmediaserver
The following is printed:
Mai 19 23:53:36 LinuxxDanceMachine Plex Media Server[1604623]: ICMT : SHVL 814
Mai 19 23:53:36 LinuxxDanceMachine Plex Media Server[1604623]: ISFT : Lavf58.65.101
Mai 19 23:53:36 LinuxxDanceMachine Plex Media Server[1604623]: Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, mono, s16, 256 kb/s
Mai 19 23:53:36 LinuxxDanceMachine Plex Media Server[1604623]: Metadata:
Mai 19 23:53:36 LinuxxDanceMachine Plex Media Server[1604623]: encoder : Lavc58.117.101 pcm_s16le
Mai 19 23:53:36 LinuxxDanceMachine Plex Media Server[1604623]: size= 1kB time=00:00:00.00 bitrate=N/A speed= 0x
Mai 19 23:53:36 LinuxxDanceMachine Plex Media Server[1604621]: INFO: Created TensorFlow Lite XNNPACK delegate for CPU.
Mai 19 23:53:37 LinuxxDanceMachine Plex Media Server[1604623]: [279B blob data]
Mai 19 23:53:37 LinuxxDanceMachine Plex Media Server[1604623]: video:0kB audio:23368kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000919%
Mai 19 23:53:37 LinuxxDanceMachine Plex Media Server[1604672]: INFO: Created TensorFlow Lite XNNPACK delegate for CPU.
Is there anything peculiar in it?
To note is that the server still shows as active (running), but is just not accessible currently
Digging into the logs that were just printed after 2 hours of inactivity, this is going on for the past 90 minutes in the logs
May 20, 2022 01:48:51.611 [0x7f6c669d9b38] DEBUG - [EventSourceClient/pubsub/139.162.170.32:443] EventSource: Got event [data] ‘’
May 20, 2022 01:48:51.611 [0x7f6c669d9b38] DEBUG - [EventSourceClient/pubsub/139.162.170.32:443] Relay: already have an active relay connection for this server
Does it have to do with the relay? (Can turn this off easily) Or does it have to do with subtitles being downloaded or something?
Whatever this is it is taking forever But I’ll do as I was told and wait This really is already going on for 90 minutes in the logs and I have no idea what it means
The log messages about TensorFlow refer to Sonic Analysis. It’s hard to know if that’s the problem from just log snippets, but it’s easy enough to disable for a test.
Settings → Server → Library → Analyze audio tracks for sonic features
But you should wait and see what @ChuckPa thinks about interrupting it or continuing to wait. I think he was referring to various database-related tasks that need to be allowed to complete. It seems like it’s been a long time though.
Yeah, I also figured 2 1/2h is quite a bit too long, but I’m not sure at all. Don’t you think it might have something to do with the relay? I’m just guessing though. I stopped PMS now trying to dig deeper into this, definitely not sure what’s going on.
Oh, I don’t know how familiar you are with Linux, but might it be related to a too small Swap partition? (Again just guessing ^^)
I could be wrong but that’s not my first guess. I think it’s a coincidental log entry. Relay is lightweight and unlikely to cause problems.
I like disabling Sonic Analysis as a test because TensorFlow is a big honker and gobbles resources. Sonic Analysis makes a great system stability tester - it consumes plenty of CPU and memory.
It might be a good stability tester, but sadly it seems my system is not too stable then huh? Damn!
Well, well, I will wait another cycle until it happens again during the scheduled tasks and then report again. So you don’t think it might have to do with insufficient space in the swap file? Guessing²
Thank you anyways for chiming in, much appreciated!
Maybe? Still not my first guess. Linux is usually pretty verbose about “ain’t got no memory” and “killing some processes” when that’s the issue. Do you see any complaints in dmesg about memory?
It would be worth running the Check for Corruption (only) step here:
As I’m already at it, do you think not having the entire repair task could help? Additionally to the check for corruption task? (I usually let it run anways every once in a while )