Just installed 9795.
Is there any way to clean up the db and decrease its size?
It’s now up to 500 MB compared with the approx. 170 MB it usually is.
@Richman777 care to share the commands to delete the data in the statistics_bandwidth table?
If I am reading the info right in DB Browser for SQLite there are 7.925.533 rows where account_id is NULL.
@drzoidberg33, any side affects by deleting the data in this table? I’m not using it for anything.
It’s normal for the current month to grow significantly and then essentially be condensed every 30 days? So I’d expect it to grow over 30 days and then on a rolling basis its condensed? I didn’t delete all the data. I only deleted May data and January data.
The “problem” as I see it, I was not on the Beta update so I shouldn’t have received 1.41.7.9784. I only turned it on to received the 1.41.7.9795 update. My DB went from 248Mb to 11 GB
@Yaracuy you can just group by a date/time (or 30 days previous) and delete.
DELETE FROM statistics_bandwidth
WHERE strftime('%Y-%m', datetime(at, 'unixepoch')) = '2025-05';
It seems like deleting these statistics will caused usage stats to incorrectly reported for users.
Edit: Despite not selecting the beta channel I absolutely have a crash report for 1.41.7.9784 so that definitely is the culprit. I’m just wondering if the currently growing May (ok last 30 days) will actually shrink. The DB doubled from watching 2 hours and as shown above, that last 2 hours was responsible for 76% of rows in the table.
Thanks!
The usage stats of my users are not so important to me - or to them.
I run the following in a copy of the db
DELETE FROM statistics_bandwidth WHERE account_id is NULL
Result: query executed successfully. Took 22118ms, 7925536 rows affected
That’s quite a chunk of rows. What account is NULL?
But the question still is: Will removing these rows break something somewhere else, other than the usage stats, which btw don’t mean a lot to me?
I’m on 1.41.7.9785 and the database still has grown 40x went from 130mb to 4.6gb
I was able to cut down the database considerably from 12.8GB to 374MB. The statistics bandwidth data seems to only remove May and Jan (where it was large amount of data), and kept the size of other months intact. This is comparing by count size.
Ran the following commands:
sqlite> DELETE FROM statistics_bandwidth WHERE account_id IS NULL;
sqlite> VACUUM;
So the stats data, compared to the previous post, is:
2025-05|4005|4.21317287158502
2025-04|7410|7.7951587961161
2025-03|3019|3.17592232192638
2025-02|2588|2.72251969829264
2025-01|3256|3.42524116601269
2024-12|2879|3.0286453676138
2024-11|2494|2.62363374325419
My Mac Mini M4 ran out of space when it grew from 1.21 GB to 64GB (and the backup was 24GB), I’m now on 1.41.7.9795 and can see the database is growing at 280MB an hour. I’m guessing this is significantly less than the previous version but still massively higher than it was previously.
Will there be a fix to further reduce the stats ? Or am I going to have to create a daily job to delete the previous day’s stats ?
Strange as my instillation is not exhibiting these variances running 1.41.7.9795-b8182f5e6, the Latest Beta.
Because
I understand that it shouldn’t be happening but it still is. I’ll delete the days with increased stats and restart Plex and see what happens
I ran the script from earlier
2025-05|463121480|42.17478877919799
2025-04|317455557|28.909522968482584
2025-03|848|0.00007722427576617672
2025-02|676|0.00006156086134190503
2025-01|317454255|28.909404400078046
2024-12|873|0.00007950093483947202
I’m hoping to chalk it up to it being the weekend but it’s clearly still not fixed given the growth rate occurring on the latest beta. I went back to the public tag and it’s grown 2MB in 2 days compared to 300MB in 2 hours before. I was testing having the same 2 streams running as the previous beta increase.
Looking at the rowcounts per day
2025-05-18|45
2025-05-17|819972
2025-05-16|19484986
2025-05-15|40493763
2025-05-14|84751016
2025-05-13|117709
2025-05-12|60
2025-05-11|317453354
2025-05-10|47
2025-05-09|73
2025-05-08|88
It looks like today may have been ok but the disk filled up so probably stopped data being written, I think 12th and 13th being low was the same full disk scenario.
Anyway, I’m rolling back to the public release after deleting data for the spoecific high days.
It’s not fixed …
Just tried the latest beta on Linux, this is NOT fixed. Reverted to public build.
@drzoidberg33
My com.plexapp.plugins.library.db went from 473MB to 37.5GB between 5/15 and 5/18 and now when I run the optimization, it locks the server up.
I’m running version 1.41.7.9795
The database is just too large I think now. I’m currently deleting half a billion rows and it’s been running for over 40 mins on my M4 Mac Mini
Maybe it would be easier to drop the table and then copy it back from an earlier smaller backup
@huntsj17 I just swapped to my backup from 5-15 while keeping a backup of the 37.5GB. While I had to re-add all my new media and rerun some scans it appears to be working so far and not getting to much bigger.
Edit: May have spoken too soon my plugins.library.db went from 473MB to 2.7GB in the last 7 hours
My backup would be 65GB and I don’t have the space. I may just take a copy onto my NAS and restore the previous backup. Then downgrade plex back to public.
In the end I’ve restored an old backup from 5 days ago that was the usual size. Anything I did to the statistics_badwidth table ended up filling the wal file and I didn’t want to corrupt the file by turning off the write ahead logs (I’m not too familiar with sqlite).
I also installed the public version and everything seems ok again now.
