Plex Becomes Unresponsive - DB Locked / Busy logged while unresponsive - pragma integrity_check ok

Want to add again: I downgraded to the September release of Plex and the issues have COMPLETELY gone away.

There’s definitely something amiss with the most recent two releases of Plex on the Linux side. It would be wise for folks to avoid if they use things like chapter markers, intro/credits skipping, and audio leveling.

1 Like

I feel like Linux is getting VERY slow too.

Im also experincing this.

I have the same issue ongoing. I can trigger the error if I attempt to add/edit an edition of a movie.

Does anyone know if the new update fixed this or no?

Currently experiencing this very frequently with the latest update.

Synology DS415+

Seeing a lot of these in the logs


Dec 07, 2023 15:25:58.022 [139966484888376] DEBUG - [Req#8577/HCl#10f] HTTP requesting GET http://127.0.0.1:32400/system/agents/update?mediaType=1&force=1&respectTags=0&guid=local%3A%2F%2F153484&id=153484&agent=com.plexapp.agents.localmedia&async=0
Dec 07, 2023 15:25:58.024 [139966476450616] DEBUG - [Req#8578] Refreshing GUID: 'local://153485'
Dec 07, 2023 15:25:58.024 [139966476450616] DEBUG - [Req#8578/HCl#110] HTTP requesting GET http://127.0.0.1:32400/system/agents/update?mediaType=1&force=1&respectTags=0&guid=local%3A%2F%2F153485&id=153485&agent=com.plexapp.agents.localmedia&async=0
Dec 07, 2023 15:25:58.046 [139966638783288] DEBUG - Failed to stream media, client probably disconnected after 0 bytes: 32 - Broken pipe
Dec 07, 2023 15:25:58.046 [139966638783288] DEBUG - Completed after connection close: [74.106.19.22:52944] 200 GET /video/:/transcode/universal/session/bb1422b0c6383b1f-com-plexapp-android/base/00079.ts (117 live) #8575 TLS 54574ms 0 bytes (pipelined: 1)
Dec 07, 2023 15:25:58.046 [139966638783288] DEBUG - Removed transcode data consumer, active count 1 => 0
Dec 07, 2023 15:25:58.260 [139966638783288] DEBUG - Auth: authenticated user 133932169 as Mom and Dad
Dec 07, 2023 15:25:59.192 [139966560779064] ERROR - [Req#8412] Waited over 10 seconds for a busy database; giving up.
Dec 07, 2023 15:26:01.092 [139966499654456] ERROR - Waited over 10 seconds for a busy database; giving up.
Dec 07, 2023 15:26:01.092 [139966499654456] ERROR - Failed to begin transaction (/data/jenkins/server/3537965286/Statistics/StatisticsManager.cpp:301) (tries=4): Cannot begin transaction. database is locked
Dec 07, 2023 15:26:05.887 [139966640892728] DEBUG - Auth: authenticated user 133932169 as Mom and Dad
Dec 07, 2023 15:26:09.413 [139966560779064] ERROR - [Req#8412] Waited over 10 seconds for a busy database; giving up.
Dec 07, 2023 15:26:11.362 [139966499654456] ERROR - Waited over 10 seconds for a busy database; giving up.
Dec 07, 2023 15:26:11.362 [139966499654456] ERROR - Failed to begin transaction (/data/jenkins/server/3537965286/Statistics/StatisticsManager.cpp:301) (tries=5): Cannot begin transaction. database is locked
Dec 07, 2023 15:26:18.029 [139966602967864] DEBUG - [HttpClient/HCl#10f] HTTP simulating 408 after curl timeout
Dec 07, 2023 15:26:18.029 [139966602967864] DEBUG - [HttpClient/HCl#110] HTTP simulating 408 after curl timeout
Dec 07, 2023 15:26:18.029 [139966484888376] ERROR - [Req#8577] Error parsing content.
Dec 07, 2023 15:26:18.029 [139966476450616] ERROR - [Req#8578] Error parsing content.
Dec 07, 2023 15:26:18.029 [139966484888376] ERROR - [Req#8577] Error parsing XML response for update.
Dec 07, 2023 15:26:18.029 [139966476450616] ERROR - [Req#8578] Error parsing XML response for update.
Dec 07, 2023 15:26:19.629 [139966560779064] ERROR - [Req#8412] Waited over 10 seconds for a busy database; giving up.
Dec 07, 2023 15:26:21.624 [139966499654456] ERROR - Waited over 10 seconds for a busy database; giving up.
Dec 07, 2023 15:26:21.625 [139966499654456] ERROR - Failed to begin transaction (/data/jenkins/server/3537965286/Statistics/StatisticsManager.cpp:301) (tries=6): Cannot begin transaction. database is locked

Chiming in. I also see that frequently on 1.32.8. Plex Server locks up all the time.

Database is located on NVMe.

1 Like

A lot of folks are having better responses after downgrading to 1.29.x.

I downgraded a while back and then figured I’d check and see how things are on the latest beta release … and the issues returned immediately.

It almost seems like calls to the DB are immensely slow for whatever reason.

There’s a thread here that talks about it … folks with PMM are having issues but it seems to happen to those without PMM as well.

Yes I’m having the same issues. It’s definitely a thing that crept up in more recent versions. The silence is deafening with this.

Using Plex on Android TV is currently a mess. Collections take like 5 full seconds or more to even show up underneath movies and music albums under artists seem to take even longer.

This is a severe issue and affects lots of parts of Plex. I’m starting to get various glitches because of these timeouts (the whole artist library section stop responding, server doesn’t show up in “more ways to watch” etc).

1 Like

@d2freak A lot of users are saying they had success by downgrading to a 1.29.x version … but that version is like crazy old.

I downgraded to whatever version was released three versions ago and the issue pretty much went away. I mean, sometimes it will still lock up but no where near as much as it does now (every single day).

Folks,

Have any of you done the ‘deep optimization’ with PMS stopped ?

I wouldn’t start ‘backing down’ to older versions. Let’s fix this here. There won’t be any fixes if it’s only a DB fragmentation issue.

This cleans out a lot of junk and puts the DB back into contiguous order.

Before running this, I suggest:

  1. Empty Trash
  2. Clean Bundles

– on all library sections

(more DB records will be marked for removal)

1 Like

Hello everyone.
Having the same problem for over a month. I came across this discussion.
I did the procedure that ChuckPa presented. With PMS stopped.
Reports found no errors, jobs done.
And it’s always the same, in the evening, if someone looks at content, that files have been added before. Boom “Busy database…etc”, unresponsive, mandatory to reboot the container.
I’m in a Docker on Unraid.
If some of you have found a solution in the meantime (other than downgrading) that would be great and for quite a few people I think.

Byebye

The only thing that fixed it for me was re-creating the whole database. It kept most of everyone’s watch history, just not their up next.
It sucks, but it’s been stable ever since

Hi MrRobot.

Thank you for your quick reply, if I have to redo the DB then I’ll have no choice.
If it works again, that’s the main thing, I had added quite a few by hand.
Thanks again and have a nice day.

I have had a 100% success rate with PMM set to --collections-only: true and then about once a week I disable all library scanning and run the full PMM suite. I believe overlays + library scanning is what caused my deadlocks and ever since I prevented both from kicking on at once it has not happened. However, it is annoying having to do it manually every week so I dug this up to see if any solution has been ran.

I’m due for a “deep optimization” now anyway so I may give that a shot and then let the nightly overlays rip again and see if it deadlocks. Rebuilding the database sounds a bit intimidating but I’m open to it if steps can be shared. I am going to have some extended downtime in the next week or so to migrate my server over to a new chassis so it’ll be a good time to experiment.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.