Plex Server Version 1.13.5.5291 Sqlite3 busy

Plex Media Server Desktops & Laptops
1

Version 1.13.5.5291

I am in the process of creating a new server, during the scanning of my library, I see Sqlite3: Sleeping for 200ms to retry busy DB. way too often (at least 10 every minute) the plex sqlite3 database is backed by an NVMe mirror, so I don’t expect it is a drive issue.

Do anybody else see this?
Do anybody has any suggestions to what I can do to mitigate this issue.

2

DEBUG log files please (not verbose) ?

3

Here is a debug log.

plex_debug.log (1.1 MB)

4

I would greatly have preferred the ZIP file set. What may seem unimportant to you might be very important to me.

From this fragment, I see:

  1. A lot of photos being added to the database.
  2. what appears to be the database becoming overloaded and fragmented.
  3. I am unable to deduce if a problem is normal for that much volume because I do not know the hardware information.

clearly the pace at which media is being added must slow down and the database manually optimzied.
When adding large quantities, it is best to add in blocks (chunks) and optimize between each for optimal performance.

Aug 18, 2018 08:41:14.844 [0x7f6983bf5700] DEBUG - Request: [127.0.0.1:48662 (Loopback)] GET /services/tmdb?uri=%2Ffind%2F73507%3Fexternal_source%3Dtvdb_id (26 live) GZIP Signed-in Token (armsby)
Aug 18, 2018 08:41:14.910 [0x7f69843f6700] WARN - SLOW QUERY: It took 2710.000000 ms to retrieve 5 items.
Aug 18, 2018 08:41:14.933 [0x7f69cc3fe700] DEBUG - Completed: [127.0.0.1:48652] 200 GET /library/metadata/45837/tree (25 live) GZIP 109ms 6553 bytes
Aug 18, 2018 08:41:14.945 [0x7f698b3fb700] DEBUG - Request: [127.0.0.1:48664 (Loopback)] GET /services/tmdb?uri=%2Ffind%2F268592%3Fexternal_source%3Dtvdb_id (25 live) GZIP Signed-in Token (armsby)
5

I have done that, I do get an error when running optimize

`Aug 18, 2018 17:06:17.502 [0x7f6988bff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Aug 18, 2018 17:06:17.511 [0x7f6988bff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Aug 18, 2018 17:06:17.517 [0x7f6988bff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Aug 18, 2018 17:06:17.522 [0x7f6988bff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Aug 18, 2018 17:06:17.526 [0x7f6988bff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Aug 18, 2018 17:06:17.529 [0x7f6988bff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
Aug 18, 2018 17:06:17.533 [0x7f6988bff700] INFO - SQLITE3:0x10, 17, statement aborts at 57: [select * from metadata_items limit 1] database schema has changed
`
6

that’s a non-error INFO statement.

PMS knows the schema has changed (Optimization removes the table index entries which are recreated immediately after optimization completes). You are seeing PMS’ notification (INFO for our benefit) the DB is properly maintaining itself.

7

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