I’ve came across this issue it seems that when you have large collection of movies/ tv shows the sqlite database can’t handle the amount of transactions with default cache size.
I was able to fix it by increasing the “PRAGMA default_cache_size” on the plex db.
depending on your setup, if you’re on linux:
install sqlite3: “sudo apt install sqlite3”
stop the plex media server
locate the plex DB directory, depending on installation it should be in “/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases”
once you’ve cd to that directory run the following:
sqlite3 com.plexapp.plugins.library.db
PRAGMA default_cache_size = 600000000; (this number is in bytes) so my value is 600MB
PRAGMA default_cache_size; (this will repeat the value entered as a confirmation
.exit (this will exit the sqlite session)
Start your plex server back up and you should find it more responsive.
Do you believe Plex uses default_cache_size? I don’t think it does, and I don’t believe setting default_cache_size in the .db file is effective.
I’ve observed that Plex Media Server explicitly sets cache_size when opening database files, overriding and ignoring any default_cache_size set in the .db file. I’ve had luck modifying the cache_size value(s) directly in the Plex Media Server binary.
The unit for cache_size actually isn’t bytes, it’s pages. The default size of a SQLite page is 4K. I’ve also had success rebuilding the databases to use a larger 16K page, which indirectly allows still more data to be cached.
you mind showing me a screenshot or a stacktrace of this explicitly being set by Plex? because when I check the schemas it’s set to the value that I applied?
PRAGMA default_cache_size is deprecated by SQLite, so it’s expected that PRAGMA cache_size is configured by each connecting app.
I created a trigger to log the active value of SELECT pragma_cache_size when Plex performs database operations. It’s 2000 for primary database activity, and cache_size=2000 appears in the Plex Media Server binary.
@SpuddyUK You’re the OP so I want to circle back to you. If I’m not mistaken you’re not observing any issue per se and the post was created more or less to determine the cause of these log entries, correct? Please see my post here. For the most part these messages can be ignored unless you are noticing extreme times or observing an issue while using Plex.
Everyone else,
This thread is becoming a dumping site for multiple issues unrelated to the OP, which was a general question [see above]. Yes, these messages exist in your logs. That is not an issue.
Please create separate threads with the exact issue that you’re observing. @dom_a2345 Sonic Analysis running without any music library, thats an issue. @telfordje & @triks_melb have issues related to scanning music libraries, thats a separate issue. @jakehoms you already have your own thread, we can continue there.
I’m not trying to dismiss anyone’s issues, simply trying to keep these issues organized to get the correct team members looking at the issue if needed. Please @me when you create your new threads if you like.
@Atomatth Yes, correct. No issues so to speak (that I can tell), but looking for the cause/resolve of the log entries. I think there are a few murmurs that SQLite is probably not the optimal DB for plex, especially those with large DB’s/Libraries. Are there any plans to allow migration to another DB engine?
I do agree the post has been somewhat side-tracked by additions that don’t seem to match the original post.
Hi, I’m have the same issue for 2 weeks now and tried everything including using different pms versions. Those errors actually do cause a problem which very noticable when exiting a playback then going back to library results in high CPU spike to 70%+. Here I watched logs. Plex Media Server Logs_2021-08-31_13-15-41.zip (2.2 MB)
I think your system may have additional issues beyond SLOW QUERY messages.
You might want to start a new thread and give some additional information about your system and configuration.
I believe that this is a sign your database may need to be repaired or restored from a backup:
Plex Media Server.2.log:Aug 31, 2021 11:28:46.559 [5920] ERROR - SQLITE3:0xd29110a2, 11, database corruption at line 79051 of [bf8c1b2b7a]
...
Plex Media Server.2.log:Aug 31, 2021 11:28:46.562 [5920] ERROR - Soci Exception handled: sqlite3_statement_backend::loadRS: database disk image is malformed
I also wonder if you have aggressive antivirus/network security software running, or perhaps a VPN on the same server? That may be a red herring; address the DB corruption issue first.
@atomatth - It would be nifty if Plex could alert in the Web app about database integrity:
Plex Media Server.4.log:Aug 31, 2021 09:08:52.840 [3848] ERROR - [Database backup/com.plexapp.plugins.library.db] The database failed its integrity check, not backing up.
Thanks I missed that 1 in the log. As for my system I’m running pms on a xeon 5218 64gn ram and win server 12 R2. And no aggressive network security. Of you don’t mind can guide me how to repair data base? Thanks
I’d be curious to see if the large DB not coping well is a hardware limitation or Plex/SQLite issue.
With around 500k of tracks I’m at the stage where I’m going to move away from PlexAmp/Plex for main music library and try Synology’s Audio Station and see if that runs better - which I suspect it might. Can’t handle seeing these messages!
@triks_melb From your last logs, you have some audio files that are causing issues with the scanner. Check your Plex Media Scanner Matcher.log files for the culprits. Also, please create a separate thread for your issue.
I have 16GB in my server and I only gave mine 600 MB it made a huge difference.
