Nothing else is needed. I’m back up and running with normally sized DBs. I just wanted to get the directory cleaned. No rush, I was just wondering if it could happen sooner than later. I will wait for the final fix, thanks for all your support!
From what size to what size, and how long did it take you?
My DB had ballooned to +32GB. After the repair tool, it’s around 150MB. The repair tool took a few minutes.
Hi I just updated my Truenas Community plex app to App Version: v1.41.7.9799-5bce000f7. Version: v1.1.23
Any idea on how to fix the size of the config folder? My config dataset is at 35GB right now
My DB was sitting 42GB after running DBrepair it is now down to 579MB
I started the process at 21:26 and it finished at 4:31 the next day
1 Like
My db had over 1b lines to remove, so the delete from statement took ages. I turned it around and created a temporary table containing only the wanted data, deleted the original table and renamed the temp table:
– Create a new table without the unwanted rows
CREATE TABLE statistics_bandwidth_new AS
SELECT * FROM statistics_bandwidth
WHERE account_id IS NOT NULL;
– Drop the old bloated table
DROP TABLE statistics_bandwidth;
– Rename the new compacted table
ALTER TABLE statistics_bandwidth_new RENAME TO statistics_bandwidth;
– Recreate the indexes (Thanks to @rockstream)
CREATE INDEX ‘index_statistics_bandwidth_on_at’ ON ‘statistics_bandwidth’ (‘at’);
CREATE INDEX ‘index_statistics_bandwidth_on_account_id_and_timespan_and_at’ ON ‘statistics_bandwidth’ (‘account_id’, ‘timespan’, ‘at’);
– Vacuum the db to reclaim space
vacuum;
This finished in less than 20 minutes on my setup, wheras the delete from statement just hang for 12h+ before I cancelled it
4 Likes
thanks for this tip, my DB is 79 GB and was at 12HRs waiting for it to purge the null data.
@raba1der I did the exact same thing due to exact same reason (my db was 110G+, I couldn’t even get a count of the rows before the container just hanging). I copied to temp table the non null id rows, dropped the old table, and renamed temp. However, I believe dropping the table may also erase the indexes so just in case I recreated the index at the end. If you run .schema statisticts_bandwidth before dropping the table you see that there are two indexes, so run this just before you run VACUUM:
CREATE INDEX ‘index_statistics_bandwidth_on_at’ ON ‘statistics_bandwidth’ (‘at’);
CREATE INDEX ‘index_statistics_bandwidth_on_account_id_and_timespan_and_at’ ON ‘statistics_bandwidth’ (‘account_id’, ‘timespan’, ‘at’);
1 Like
Hello, is there an option to fix this mess when server is running on Windows 10?
My com.plexapp.plugins.library.db has ballooned to 155GB…
Last time I checked it really wasn’t any close to that.
Will Plex DB Repair work? (Version v1.00.00 for Windows)
Is the PLEX team working on a fix to decrease size? I see the db file increasing every hour and have to emergency exit till there’s a fix.
Thanks
They mentioned earlier in the thread that the next beta version will have a fix to decrease size if you can wait for it. Otherwise you can try your hand at the SQL commands some folks have shared if you’re familiar with it or restore from a backup.
I don’t think PlexDBRepair works in this particular situation on it’s own… but can help with restoring from backups.
Thanks for the reply.
Unfortunately I’m not tech savvy enough.
Plex DB Repair seemed easy enough, but not SQL, not for me anyway.
The concern I have is letting the server running and waking up tomorrow morning and see it at like 200GB or even more…
Hope Plex team releases a fix in a timely manner.
The newest beta that is out now, stops it from growing. It does not shrink it back down, that will be in a future release. But at least it won’t continue to grow.
Also apparently, they just released a new version of the repair tool that will shrink it back.
I haven’t tried it though.
Linux and Mac only.
As others have mentioned, to stop the growth, update to 1.41.7.9799 or fall back to 1.41.6 or earlier.
I did release 1.10.06 of my (not Plex’s) repair tool.
It will reduce the size.
I did not write it to be fast however it did reduce a large DB in about 20 minutes on a little DS918 NAS.
Just to make things clear here!
The tool you reference is not an official Plex Tool, but made by one of our Team members and even though he is a trusted person, it is still 3rd party
When said, I use the tool myself!
1 Like
See my post above for some Windows instructions to clean your DB up. Worked for me running in docker but if you just have a native install of PMS, make sure you exit or stop the service if it is running as such first.
From a C:\ prompt. Four commands. You can copy and paste the individual commands if Plex is installed in the default locations. Stop Plex Media Server before running the commands.
c:\>"C:\Program Files\Plex\Plex Media Server\Plex SQLite.exe" "%LOCALAPPDATA%\Plex Media Server\Plug-in Support\Databases\com.plexapp.plugins.library.db"
sqlite> delete from statistics_bandwidth where account_id is NULL;
sqlite> VACUUM;
sqlite> .quit
IMPORTANT: Note the semi-colons after the SQLite commands. They are important. The command will not run without it. The same with the period before quit.
The delete command may take minutes or hours, depending on the amount of data to remove, CPU speed, and hard drive/ssd speed.
Here is an example running on my Windows 10 PC, reducing a ~1 GB database to ~280 MB. This took about four minutes (i7-4790K & db on a SSD). It will obviously take much longer with a database of tens or hundreds of GB.
c:\>dir "%LOCALAPPDATA%\Plex Media Server\Plug-in Support\Databases"
05/23/2025 18:14 220,037,120 com.plexapp.plugins.library.blobs.db
05/23/2025 18:14 1,083,310,080 com.plexapp.plugins.library.db
c:\>"C:\Program Files\Plex\Plex Media Server\Plex SQLite.exe" "%LOCALAPPDATA%\Plex Media Server\Plug-in Support\Databases\com.plexapp.plugins.library.db"
SQLite version 3.39.4 2022-09-29 15:55:41
Enter ".help" for usage hints.
sqlite> delete from statistics_bandwidth where account_id is NULL;
sqlite> VACUUM;
sqlite> .quit
c:\>dir "%LOCALAPPDATA%\Plex Media Server\Plug-in Support\Databases"
05/23/2025 18:14 220,037,120 com.plexapp.plugins.library.blobs.db
05/23/2025 18:18 280,846,336 com.plexapp.plugins.library.db
c:\>
1 Like
Folks,
I want to apologize for any confusion about DBRepair (3rd party tool I wrote).
There is a thread where you can ask questions if/when needed.
DBRepair development
To avoid future confusion with Plex, I have renamed the tool per Plex guidelines. It’s now DBRepair .
URL is GitHub - ChuckPa/DBRepair: Database repair utility for Plex Media Server databases
The stats where unfortunately lost in the rename.
3 Likes
Just wanted to thank you @raba1der and @rockstream for this!
My database had gotten to be 40GB… so when I tried running the previously suggested DELETE FROM statistics_bandwidth WHERE account_id IS NULL, it was still going after 4 hours. With yours, I was able to get everything resolved within an hour.
For any Windows users using this method, it looks like some of the characters in the commands under ‘Recreate the indexes’ were breaking when I pasted them into CMD.
I rewrote them below (and wrapped everything in script tags):
-- Create a new table without the unwanted rows (Took about ~20 minutes for a 40GB DB).
CREATE TABLE statistics_bandwidth_new AS SELECT * FROM statistics_bandwidth WHERE account_id IS NOT NULL;
-- Drop the old bloated table (Took about ~40 minutes for a 40GB DB).
DROP TABLE statistics_bandwidth;
-- Rename the new compacted table.
ALTER TABLE statistics_bandwidth_new RENAME TO statistics_bandwidth;
-- Recreate the indexes (Thanks to @rockstream).
CREATE INDEX index_statistics_bandwidth_on_at ON statistics_bandwidth ('at');
CREATE INDEX 'index_statistics_bandwidth_on_account_id_and_timespan_and_at' ON 'statistics_bandwidth' ('account_id', 'timespan', 'at');
-- Vacuum the db to reclaim space. (This step is where you'll actually notice the DB size reduction.)
vacuum;
Again, appreciate the work you put in on this!
5 Likes
Hi @ChuckPa is there a chance you update the Windows version of your tool to the version that shrinks db to reasonable size? Thanks.
Being stuck with a 155GB crash-inducing library.db right now sucks, with no recent backups unfortunately.
