Library.db size more than doubled in latest version

After installing 1.41.9795 my database continues to grow, with very little user activity. In the last 36 hours it grew from about 2GB to over 18GB.

EDIT: the database tripled in size (from 6GB to 18GB) since it was backed up 12 hours ago, with no user activity during that time.

1 Like

@drzoidberg33

  • I see that 1.41.7.9799 just came out and mentions reverting the fix for bandwidth reporting.
  • I restored a 3-day-old DB on 1.41.7.9795 and it went from 473MB to 4.6GB over 9 hours.
  • I installed the new version (1.41.7.9799) and performed an optimization and it blew out the com.plexapp.plugins.library.db-wal file to 4.7GB from around 1.2GB.

Plex’s been really messing it up with these betas. Never had an issue with betas before but it seems like recent updates have been a bit buggy in regards to the betas. My drive went full with the DB growing like 40 times and it just brought down my whole server.

:saluting_face:

2 Likes

Looks like they just reverted the fix as it made the problem worse.

Don’t upgrade to the new beta man. It has the same issue. It will re-optimize your .wal file and it will grow significantly again.

I had run GitHub - ChuckPa/PlexDBRepair: Database repair utility for Plex Media Server databases in the try to bring stuff to normal. It didn’t affect the .db files but the .wal was 1GB.

I upgraded to 1.41.7.9799 from 1.41.7.9795 in the hopes that stuff will return to normal. Once it upgraded the .wal file is 15GB now.

So 1.41.7.9799 does not fix this issue.

AND I AM NOT KIDDING.

image

4 Likes

I have a very large video libraries on Plex (4 of them) and it’s been crashing every 2-5 hours - Plex Media Server is still showing in Task Manager, but Plex is unresponsive and not usable.
Restarting PMS resolves the problem for a while.
I even used DBRepair and it didn’t report any issues (but it did take 2x longer than normal).

Could this be the problem?

I updated to Version 1.41.7.9799 this evening.

I see that that update might not have fixed the error, but I was curious if my crashes are related or if I need to start a new post for my issue.

1 Like

Check your Plex DB sizes to make sure. If they are huge, its this issue.

com.plexapp.plugins.library.db = 14.5 GB

This is my DBRepair Logs from the 9th and yesterday: 11 vs 61 minutes - so I think my db is exceptionally large.

2025-05-09 14.32.22 – ============================================================
2025-05-09 14.32.22 – Session start: Host is Windows 10 (Build 26100)
2025-05-09 14.32.22 – Stop - START
2025-05-09 14.32.22 – Auto - START
2025-05-09 14.39.48 – Repair - Export databases - PASS
2025-05-09 14.41.59 – Repair - Import - PASS
2025-05-09 14.42.28 – Repair - Verify main database - PASS
2025-05-09 14.42.33 – Repair - Verify blobs database - PASS
2025-05-09 14.42.33 – Reindexing Main DB
2025-05-09 14.42.55 – Reindexing Blobs DB
2025-05-09 14.43.03 – Reindexing complete.
2025-05-09 14.43.03 – Moving current DBs to DBTMP and making new databases active
2025-05-09 14.43.03 – Auto - PASS
2025-05-09 14.43.03 – Start - START
2025-05-09 14.43.03 – Start - PASS
2025-05-09 14.43.04 – Exit - Deleted temp files.
2025-05-09 14.43.04 – Session end. 05/09/2025 14:43:04
2025-05-09 14.43.04 – ============================================================

19:59:19.86 – ====== Session begins. (Sat 05/17/2025) ======
19:59:20.08 – Exporting Main DB
20:04:51.85 – Exporting Blobs DB
20:12:37.66 – Exporting Complete.
20:12:37.67 – Creating Main DB
20:38:34.53 – Verifying Main DB
20:45:51.20 – Main DB verification check is: ok
20:45:51.22 – Main DB verification successful.
20:45:51.28 – Creating Blobs DB
20:48:26.18 – Verifying Blobs DB
20:48:46.46 – Blobs DB verification check is: ok
20:48:46.46 – Blobs DB verification successful.
20:48:46.48 – Import and verification complete.
20:48:46.55 – Reindexing Main DB
20:58:06.45 – Reindexing Blobs DB
20:58:26.54 – Reindexing complete.
20:58:26.54 – Moving current DBs to DBTMP and making new databases active
20:58:26.58 – Database repair/rebuild/reindex completed.
20:58:26.60 – ====== Session completed. ======

I just went back to the buld from the 14th ver 1.41.7.9784 - I hope this resolves my issue. :crossed_fingers:

Upgraded yesterday from 1.41.7.9749 to 1.41.7.9795 and noticed after a few hours that my server storage usage was increasing quite a bit and there was some unusually high CPU usage patterns, seemingly from Plex.

Since the only change yesterday was updating PMS, I found and read this discussion, and found that the DB file had gone from 800mb approx to 2.6GB. I decided just to shut down Plex Media Server for the night to stop any additional db growth.

I see 1.41.7.9799 is now available but doesn’t seem to have fixed the issue? So I’ve uninstalled 1.41.7.9795, restored the 2 older database files that were automatically backed up on 18th May (using 1.41.7.9749 PMS version), and reinstalled 1.41.7.9749 from the updates folder.

Everything seems to be working ok on 1.41.7.9749 and I’m not yet seeing crazy DB behaviour…

The same problem of the table statistics_bandwidth growing anormally fast is also part of the stable release (1.41.7.9799).

This is extremely frustrating, as now my DB is 10x the size. Plex tanked tonight and I managed to get things going again, but optimizing the DB results in Plex hanging and dropping clients.

Honestly the only fix for me was to restore an old (smaller backup) and roll back to 1.41.6.9685. Trying to manually delete 500m+ rows from the statistics_bandwidth database was just too time consuming. When the databse was 67GB doing anything with it was nigh on impossible. I’m back to 1.2GB now.

Although I am also using the Beta versions, I don’t seem to be affected, luckily (database constantly <350MB). What information does this table (statistics_bandwidth) hold?

I think the latest beta fixes the issue with table size massively increasing, but it doesn’t delete the rows that are already written and causing the issue with an unresponsive database if it has filled your drive.

I’ve no idea what the table is used for, apart from a guess based on the name.

Because of

If you don’t want to/cannot wait that long, you’ll have to delete the excessive lines from the DB table manually.
(Only do this if you have experience with SQL!)

Q: I’m thinking about going back to a normal sized db from the 9th, but I’ve added and a few hundred video and updated many tv series since then.

What happens to all the existing/new thumbnails misc files in my Plex folder? Does Plex clean up orphan files or do they get left there?

What length of time did you experience this exponential growth? Was it within the last 4 backups (as a comparative in the Databases directory)?

I’m not going to reply to everyone here individually here, but we’ve reverted some changes that were causing this - please update to the latest build: Plex Media Server - #675 by chris_decker08

Apologies about this one, unfortunately this issue wasn’t something that was immediately noticeable during testing as it was gradual and not immediately noticeable unless you’re monitoring the database size closely.

Just a reminder again that this is a beta version, we obviously don’t want to release beta versions with bugs like this but unfortunately it does happen from time to time.

As the data in the statistics_bandwidth table isn’t critical for anything (it’s used on for the historical data in the dashboard) you can delete all the data in this table if you want as described earlier. Another option is to look at your last good database backup and see what the last row id in this table was and only delete the rows greater than this id - this way should retain the older stuff.

2 Likes

I noticed the same thing.

I just reverted back to 1.41.7.9749 because of other issues and i really don’t want to upgrade to another one unless those other issues are confirmed to be fixed.

The 1.41.7.9749 build is fine, it’s not affected by this issue.