Automatic deflate based on some condition sounds reasonable,
About how much time does it add to fixing your badly bloated test DB?
I wouldn’t want someone on a slow CPU to think DBRepair has hung.
1 Like
As with Pruning, I don’t think it should be auto. I think it would be best to calculate what the deflating would be and then then let the user decide whether or not to apply to the database (similar to Prune)
The fundamental problem with Auto Deflate versus Manual Deflate
-
Most users don’t know when to do a Deflate. They only know PMS has gotten horrifically slow. Further, they don’t know how to check the DB size and what is a reasonable size for their installation.
-
Those who use DBRepair notice the Check is taking a long time to complete and performance is not improving.
-
Where do I draw the line (This IS in Plex’s territory at this point)
– Do I auto repair?
– Do I inform the user to "Hey, you need to deflate " ? -
When SQLite3 is running, it has no output. There’s no way to know if it’s hung. It will never hang. SQLite is simply reading through the DB record by record.
-
Any attempt to performance test the process is very difficult.
– FordGuy did it on his Syno and it took some 20+ minutes for this DB
– On my i9 (SSD) machine, it took 30 seconds
– Some of the monster DBs (300GB+) have taken a couple hours.
This is the benchmark on my i9-12900 machine (NVMe SSD) with this deflate function.
[chuck@lizum databases.2025.05.17.2028]$ ./Deflate2.sh
==== Current listing
total 32G
drwxr-xr-x 2 chuck chuck 4.0K Oct 19 15:40 .
drwxr-xr-x 3 chuck chuck 66 May 30 10:24 ..
-rw-r--r-- 1 chuck chuck 171M May 17 16:03 com.plexapp.plugins.library.blobs.db
-rw-r--r-- 1 chuck chuck 31G May 17 16:10 com.plexapp.plugins.library.db
-rw-r--r-- 1 chuck chuck 7.5K Jul 27 03:43 DBDeflate.log
-rwxr-xr-x 1 chuck chuck 43K Jul 27 00:14 DBDeflate.sh
-rw-r--r-- 1 root root 1.7K Jul 26 22:46 DBDeflate.tab1
-rw-r--r-- 1 root root 1.7K Jul 26 22:46 DBDeflate.tab2
-rw-r--r-- 1 chuck chuck 15K Oct 4 13:40 DBRepair.log
-rwxr-xr-x 1 chuck chuck 80K Oct 4 13:28 DBRepair.sh
-rwxr-xr-x 1 chuck chuck 2.2K Oct 19 15:38 Deflate2.sh
-rwxr-xr-x 1 chuck chuck 43K Jul 27 03:14 Deflate.sh
== 2025-10-19 15.41.02 == Repairing DB
== 2025-10-19 15.41.33 == Deflating DB into new temp DB file
== 2025-10-19 15.41.33 Completed
[chuck@lizum databases.2025.05.17.2029]$ ls -lah
total 32G
drwxr-xr-x 2 chuck chuck 4.0K Oct 19 15:41 ./
drwxr-xr-x 3 chuck chuck 66 May 30 10:24 ../
-rw-r--r-- 1 chuck chuck 171M May 17 16:03 com.plexapp.plugins.library.blobs.db
-rw-r--r-- 1 chuck chuck 31G Oct 19 15:41 com.plexapp.plugins.library.db
-rw-r--r-- 1 chuck chuck 7.5K Jul 27 03:43 DBDeflate.log
-rwxr-xr-x 1 chuck chuck 43K Jul 27 00:14 DBDeflate.sh*
-rw-r--r-- 1 root root 1.7K Jul 26 22:46 DBDeflate.tab1
-rw-r--r-- 1 root root 1.7K Jul 26 22:46 DBDeflate.tab2
-rw-r--r-- 1 chuck chuck 15K Oct 4 13:40 DBRepair.log
-rwxr-xr-x 1 chuck chuck 80K Oct 4 13:28 DBRepair.sh*
-rwxr-xr-x 1 chuck chuck 2.2K Oct 19 15:38 Deflate2.sh*
-rwxr-xr-x 1 chuck chuck 43K Jul 27 03:14 Deflate.sh*
-rw-r--r-- 1 chuck chuck 207M Oct 19 15:41 new.com.plexapp.plugins.library.db
[chuck@lizum databases.2025.05.17.2030]$
- Starting DB is 31 GB
- Final DB is 207 MB (as it should be)
I will provide a download link to anyone who wants to run this test script and test DB on their machine as a form of benchmarking.
1 Like
Didn’t Plex resolve the issue that caused the bloating (fixed the issue but didn’t deflate existing databases)? If so, then once the database is repaired with Deflate, there should’t be a reason to run deflate again (via auto). Images keep needing Pruning, yet that’s not in automatic, so there’s an inconsistency here.
Middle ground – 2 auto selections, 1 that includes Deflate and one that does not.
That’s an an excellent question.
Should “Auto” perform everything in one step which includes Prune and Purge?
If it’s going to be “auto” then it really should do Everything automatically ???
If I had a config file then folks to tweak it to their liking but config files are such a PITA
Regarding Plex resolving their DB issue.
- They have code in place
- From what I’ve seen, most cases are slowly resolving but some are still hideously large databses
- I think the fundamental issue there is the DB will only be reduced by Plex when Scheduled Tasks run at night (if there’s enough time). Time is the issue.
I’m not sure if it’s been suggested before, but have you considered porting this to Python to increase its portability across platforms? I’d be willing to help with that effort if it’s something you’d like to pursue.
2 Likes
Still, why not an Auto1 and Auto2?
Auto 1 & Auto 2 ? No . That makes no sense.
I’m leaning towards including deflate in auto.
- Auto is the one step choice to repair and optimize the database.
- Having a deflated database is needed for PMS to operate efficiently.
- Running deflate on a non-bloated database is fast (see below).
- AFAIK, running deflate on a non-bloated database does no harm (it has not harmed the db on my Plex servers).
I’m fine with including prune in auto. It is a good thing and I run it anyway every time I run DBRepair.
Deflating a non-bloated database.
Running deflate on a non-bloated database is fast, even on older/slower systems.
On my Syno DS918+ “deflating” a non-bloated 286 MB database takes under one minute.
Running auto on the same database takes four minutes.
Here’s the output of sudo ./DBRepair stop deflate auto exit:
DBRepair deflate and auto on non-bloated, non-corrupt db
[2025-10-19 15.59.17] PMS already stopped.
[2025-10-19 15.59.17] Check and Deflate started.
[2025-10-19 15.59.17]
[2025-10-19 15.59.17] Checking the PMS databases
[2025-10-19 15.59.26] Check complete. PMS main database is OK.
[2025-10-19 15.59.27] Check complete. PMS blobs database is OK.
[2025-10-19 15.59.27]
[2025-10-19 15.59.27] Backup current databases with '-BACKUP-2025-10-19_15.59.27' timestamp.
[2025-10-19 15.59.27] Starting Deflate. (There will be no output until complete.)
[2025-10-19 15.59.29] PMS main database successfully repaired.
[2025-10-19 15.59.29] Reducing main database size.
[2025-10-19 15.59.32] PMS main database size reduced.
[2025-10-19 15.59.32] Verifying PMS main database.
[2025-10-19 15.59.41] Verification complete. PMS main database is OK.
[2025-10-19 15.59.41] PMS main database reduced from 285 MB to 285 MB
[2025-10-19 15.59.41] PMS main database deflate completed.
[2025-10-19 15.59.41] Saving current main database with '-BLOATED-2025-10-19_15.59.27'
[2025-10-19 15.59.41] Making deflated database active
[2025-10-19 15.59.41] Deflate complete. Please check your library settings and contents for completeness.
[2025-10-19 15.59.41] Deflate successful.
[2025-10-19 15.59.41] Recommend running Auto next to complete optimization of new database.
[2025-10-19 15.59.42] Automatic Check,Repair,Index started.
[2025-10-19 15.59.42]
[2025-10-19 15.59.42] Checking the PMS databases
[2025-10-19 15.59.51] Check complete. PMS main database is OK.
[2025-10-19 15.59.51] Check complete. PMS blobs database is OK.
[2025-10-19 15.59.51]
[2025-10-19 15.59.51] Exporting current databases using timestamp: 2025-10-19_15.59.41
[2025-10-19 15.59.51] Exporting Main DB
[2025-10-19 16.00.05] Exporting Blobs DB
[2025-10-19 16.01.17] Successfully exported the main and blobs databases.
[2025-10-19 16.01.17] Start importing into new databases.
[2025-10-19 16.01.17] Importing Main DB.
[2025-10-19 16.02.06] Importing Blobs DB.
[2025-10-19 16.02.18] Successfully imported databases.
[2025-10-19 16.02.18] Verifying databases integrity after importing.
[2025-10-19 16.02.27] Verification complete. PMS main database is OK.
[2025-10-19 16.02.28] Verification complete. PMS blobs database is OK.
[2025-10-19 16.02.28] Saving current databases with '-BACKUP-2025-10-19_15.59.41'
[2025-10-19 16.02.28] Making repaired databases active
[2025-10-19 16.02.28] Repair complete. Please check your library settings and contents for completeness.
[2025-10-19 16.02.28] Recommend: Scan Files and Refresh all metadata for each library section.
[2025-10-19 16.02.28]
[2025-10-19 16.02.28] Backing up of databases
[2025-10-19 16.02.28] Backup current databases with '-BACKUP-2025-10-19_16.02.28' timestamp.
[2025-10-19 16.02.28] Reindexing main database
[2025-10-19 16.02.48] Reindexing main database successful.
[2025-10-19 16.02.48] Reindexing blobs database
[2025-10-19 16.02.50] Reindexing blobs database successful.
[2025-10-19 16.02.50] Reindex complete.
[2025-10-19 16.02.50] Automatic Check, Repair/optimize, & Index successful.
1 Like
That would be for users of scripts/cron that don’t want to Deflate an already deflated database. For me, I use DBRepair via ssh, so I would just do the individual repairs and not use Auto if Deflate is included in Auto.
True, but once deflated, does the database get ‘flated’ again? I thought it was a one-time needed fix. (FWIW, my database never needed deflating)
No, the db will not be bloated (unless running the afflicted versions of PMS 1.41.7).
Other three points still apply. One step to repair db, fast, does no harm.
Yes, porting to python has been suggested several times.
Porting to python requires Python be available on the target host.
Plex is removing all remnants of Python from PMS.
I cannot guarantee it will be available.
So then after a fix, no need to fix again, my reason why it should not be in Auto.
(I always update PMS when a new version is available, and I was never affected by this)
Even with the newer PMS versions, the bloat problem persists.
This is why, many months after the issue started, I’m addressing it in DBRepair.
I should not need to. PMS should be.
I’m not fond of doing this because I am actively modifying the database.
Until now, DBRepair has made no modifications to anything inside the PMS database,
I’ve only
- fixed the SQLite structure (malformed DB),
- exported the data records in sorted order to optimize performance
- cleaned up temp files PMS forgot to
Deflate is a ‘big deal’ for this script to tackle because, for the first time, it is modifying data in a database table.
Defining the proper scope of If / when, under what conditions, and under whose control is important to me.
There is a ‘beta’ tar.gz linked above with the manual deflate implementation.
Whether I tie it into “Auto” is the final question. That’s what initiated today’s discussion
That’s kinda my point; Python is (almost?) universally available on the platforms which support PMS. And implementing it in Python would more-or-less guarantee cross-platform support. The only things which would need to differ between platforms would be to find the Python executable and to account for the differing Plex data directories.
Windows users in particular would benefit from this as new features could be enabled for them immediately.
Anyway, just an idea. The tool is great just as it is. However, I just think using a cross-platform language would help to make it more ubiquitous and useful.
I see your point. Was just adding my opinion.
I’m happy to have the deflate capability in the tool, whether or not it is in auto.
Either way it will be a lot better than trying to lead people through creating a shell script, manually issuing SQL commands, etc.
I appreciate the idea and recognize there would be only one DBRepair.py in circulation for everyone.
I guess Python is something to research
1 Like
After considering what you said,
I don’t think deflate needs to be a part of Auto, no does prune.
Perhaps a function like Analyze would
- report that a DB looks bloated and suggest deflate
- report that extra images exist and suggest prune.
Leaving auto the way it is would be the safest and most consistent.
2 Likes
IMO, this should not be in Auto, and there should be a test on a copy of the database to see if it even needs deflating before any mod to the database.
1 Like
