statistics_bandwidth is the problem area of the database in these beta builds–it’s been collecting too much data and that’s causing it to grow rapidly. By deleting just the entries in statistics_bandwidth where the account_id column is set to NULL instead of a proper account_id, we can trim the excess data. Then VACUUM will remove all the empty space left there from the DELETE earlier, and reduce the database size back to normal.
1 Like
If you’re using TrueNAS Scale I updated my original post to include using /bin/bash and how to down the service as well, assuming you’re using the linuxserver.io image.
Thank you, this seems relatively safe to complete. I will perform this on my server this evening.
1 Like
You should change this to
s6-svc -wd /var/run/service/svc-plex
So that it actually waits for the PMS instance to shutdown before it proceeds.
1 Like
If you don’t know what you’re doing, just wait for the next release as it will clean up the bloated size during its upgrade process. Honestly just make sure PMS is shut down before you edit the database with that command.
Good point, updated my post
In my case I can’t wait, at 41GB I’d get stalls and crashes. Plex was unusable. Probably going to avoid Beta versions for my primary Plex instance moving forward
2 Likes
I do know, I am relatively tech savvy, just wanted to know exactly what the commands do before performing them 
So 1.41.7.9799 (the public build released today) does not contain this bug right?
I’m concerned because the changelog only says it reverted the fix which was trying to stop the database from growing in the first place. Or maybe I missed something.
1 Like
This update reverts the bad patch that caused the issue. so it will not continue to happen.
It will not clean up and undo any bloated entries that were added from the bad update. That you must do manually or wait for the future update, which will automatically do it.
You’re right, this app only just finds media files in your Library folders that ‘for some reason’ Plex couldn’t find?
I’m running the Plex SQLite routine now
Regarding Bundle Cleaning… (not technically bundles, but they are remenents of Plex tasks that for some reason weren’t cleaned up – unless they are necessary?)
I noticed a couple of weeks ago that my backup of my Plex SSD was much smaller than the drive that exclusively hosts the Plex data folders.
I looked at the backup settings to see why there is a huge discrepancy and saw that the only file I have excluded from backing up are *.tmp files.
So I used the following command to remove all .tmp files
del /s /q “E:*.tmp”
There were 9,029 tmp files deleted from the \Media folder, totalling nearly 1TB (952 GB).
So this goes back to my Bundle Cleaning question, what files does cleaning look for? What other files should i look for to manually remove from the Plex folders?
I’m also wondering about that, because my database also seems to grow under 1.41.6 (not that much as reported here, but still noticeable).
@drzoidberg33 could you comment?
This appears to be a bug in recent PMS versions.
I have filed an issue for this.
1 Like
Could you supply some server logs too.
This is definitely not happening for everyone, so having your logs to see what’s going on would be required.
I just migrated my PMS install to a different server last night and rsync’d over my entire metadata folder to a new machine and saw none of this.
I looked at the dates of the bif files that shared the same folder as the tmp files and the were created in Feb and March of this year. I don’t have any logs from that time.
Here is a folder with some logs, the list of deleted files and another txt file with the dates of two of the 900 deleted files.
[Microsoft OneDrive](https://Shared Plex Support Folder)
Also, on a positive note, I now know that .tmp files are cleaned by Bundle Cleaning. 
Are you sure? I cannot confirm this.
Very sure. I’ve Optimized, Cleaned and Deleted Trash at last 4-10x a week every week since as long as I can remember.
Correction on my previous post.
I now know that .tmp files are NOT deleted by Bundle Cleaning.
1 Like
Thanks.
The issue looks to be that the files are getting locked by another process. Do you have any anti-virus software on the system? It may be a good idea to exclude certain paths from its active scanning.
May 21, 2025 01:09:32.673 [18428] ERROR - [Grabber/52af8ba9aaa8931905ec080fa9f5d4ee1fb957bf/BaseIndexFrameFileManager] Couldn't delete the file "C:\Users\john\AppData\Local\Plex Media Server\Media\localhost\7\d1a6af6bbe4b8867f4a4c99251f1edd8a7accee.bundle\Contents\Indexes\index-sd.bif.tmp": The process cannot access the file because it is being used by another process
The only antivirus I have running is Microsoft Defender, no third party tools - I try and keep my Plex server as stock as possible.
I’m hesitant in excluding folders since about 5-6 years ago my Plex server was locked with ransomware and it cost me $3,000 and a lot of time and frustration getting it reversed.
I’ll have to think about that.
