That does count and it will scan and lock files. You can search the forum for similar issues.
Thanks, I’ll do that and see what the consensus is.
Regarding Defender, I gave following Plex apps the ability to access files through controlled folder access.
Plex Commerical Skipper
Plex Media Scanner
Plex Media Server
Plex Transcoder
PlexScriptHost
Is there another Plex app I should give folder access to?
database optimization is running for 3 hours. I can’t access settings.
24G com.plexapp.plugins.library.db-wal
25G com.plexapp.plugins.library.db
week ago
612M com.plexapp.plugins.library.db-2025-05-13
Is it safe to kill PMS during optimizing DB?
Absolutely not! Wait for it to finish the operation.
Otherwise you will have to go back to a database backup.
1 Like
I had the same thing happen even when my db had only grown to a few GB. I cancelled optimization out of frustration after it was had been running overnight. I figured that might trash the db and it did.
Restored from a backup easily enough, but this was before we knew which server release was causing the problem, so it very quickly grew again, to 40GB. Another backup restore and a server release downgrade put me right again.
2 Likes
When the future release drops that will purge the statistics_badwidth table of the spurious rows I do wonder if it will work for everyone. It pushed my storage to be completely filled up and even manually trying to delete the rows was taking hours and filling the disk more with the write-ahead-logs file filling up.
It was way easier to restore a previously backed up database.
For those who choose to wait for the next version and just want to live with a larger database file for now, you should also turn off automatic weekly database optimization in the scheduled tasks. Otherwise it will lock up your plex during optimization. After a certain DB size PMS freezes during optimization, that’s why I have this off by default and just run optimization manually when no one is streaming.
I have a pretty fast threaripper server, for reference of how long the freeze is: My db size is 4GB and blobs is 15GB and it freezes PMS for around 10-20 mins.
Mods/Devs: You should probably note on the next version that the DB maintainance/migration that is part of the update will take awhile to bring Plex back online. Because if it’s vacuuming a 50GB DB it’s going to take a long time. People are going to assume (like last time) that the update borked something because Plex is taking too long to start and they’ll force terminate PMS. It caused so many issues last time there was a big DB migration. I know this isn’t the same thing, but I wanted to bring it up.
1 Like
And is it really fixed though? The changelog says this unless I’m missing something:
- Bandwidth reporting changed
- A fix was applied because said change caused db growth
- The fix was reverted because it made it worse
- Public release
Now I’m not an expert but this seems to me like the original issue was never fixed before it was pushed to public? I hope I’m missing something.
1 Like
From the other comments here, they say that the growth stopped after they installed the update that contains the words “reverted.” I was confused too when I read it.
Yes I know but there are also people saying it didn’t 
Either way I’m not taking the chance with this update. I’m not sure what Plex is doing anymore.
You are using a beta release, so expect there may be an issue from time to time.
I moved back to the latest beta after running a backup so I could easily rollback if the issue persisted and it seems fine for me, no massive database tables.
1 Like
Been running over 10 hours here :). You are probably going to have to do some kind of announcement for users, this is going to completely break people’s plex installs for a while.
2 Likes
Please be aware that some fixups only run during the Optimize run during the scheduled maintenance, running a manual Optimize will not run all the fixups.
Disabling this option is really not recommended.
That’s good to know. But that’s too bad because I’m not enabling it. 
I might find a time when no one’s watching and change the maintenance time and enable this option once in a while just to clean out the cobwebs. Great info 
After running for 7+ hours on a (originally) 500MB → 69GB database, I shutdown plex again, copied the 69GB DB, file, opened it in “Plex SQLite” (important to use the plex binaries I think), and then ran this on that copy:
.open com.plexapp.plugins.library.db.copy
PRAGMA journal_mode=OFF;
PRAGMA synchronous=OFF;
DELETE FROM statistics_bandwidth WHERE account_id is NULL;
VACUUM;
PRAGMA synchronous=FULL;
PRAGMA journal_mode=WAL;
.quit
Then copied the new 500MB DB file back into place. Disabling then re-enabling synchronous and journaling made it take ~30 minutes instead of 7+hours of not completing.
Seemed to work well for me and database looks OK after swapping it back in (still have the original as a backup). May help others if they’re having issues with the amount of time the cleanup takes.
My understanding is it should be fine as long as each operation completes and isn’t interrupted, and it leaves all DB settings back as they were originally at completion.
6 Likes
Has this really been solved with the latest build? I still see my diskspace shrinking while plexmediaserver is throttling the CPU & IO and the server not being accessible. Or is that being expected while it performs the DB cleaning?
I’m guessing you’re experiencing a different problem. You’re hitting many other points that are not related to this. What’s the size of your database currently?
My com.plexapp.plugins.library.db is now sitting around ~60GB with another two of similar sizes (40GB and 60GB) from former days and a .db-wal of around 36GB. Not really sure which one can be deleted. Shut down the server for now to ease on the hardware.
The wal file is used for rollback. Once you run the commands above, and exit SQLite, it should shrink or disappear.
It would help if you confirm what version of Plex you are running now, and if you run the commands above or not.
