I had these messages and similar behavior and it was hw problem with one hard disk with media (not the one where the Plex DB was).
You can try to check for DB corruption as suggested by someone else to discard DB problems.
I do a weekly partity checks for the array of disks the media is on and have had nothing but postive checks to date?
So did I.
1 Like
So Iāve managed to do some extensive testing and the issue hasnāt come back sine I stopped the DB Backups. I donāt know whether it was a timing issue with other processes, but itās definitely the culprit of my issues.
Iāve been chasing down a similar situation in a Docker environment without much luck. Iām gonna try disabling database backups too! (Just wondering how an every-3-day process could cause lockups nearly every day ā doesnāt seem to quite fit.)
Mine was something specific to the logs I uploaded in here after a restart, it was then causing this error "threads are waiting on db connections held by threads: 22436653173560, 22436535565112" over 66 times. The long numbers represent a process that should be on the log.
I ran across this thread and figured Iād throw my recent experience in the mix in case it might help anyone else.
I had very similar behavior. I thought it was Plex crashing and I thought it was related to some of the recent issues reported with HW transcoding on Linux (since it typically was down after someone was transcoding while watching).
After a few days and finally having some time to dig into it a little deeper, I remember I recently upgraded my Linux kernel to 6.2. I also noticed after one of these ācrashesā, my server lost network connection completely. Apparently there are some ethernet driver issues related to this newer kernel with hard wired connections.
Long story short I installed an updated version of my ethernet driver and my server has been stable again (knock on wood).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
