Library.db size more than doubled in latest version

Server Version#: 1.41.7.9784

After cleaning up my libraries some weeks ago my library.db size used to be about 176 KB.

I’ve only added about 10 TV episodes the latest days and refreshed metadata for a couple of shows and now the library is about 377 KB and after optimizing the DB from the Web UI the db.wal is about 380 KB.

This has happened after the latest PMS version mentioned above.

I’ve run @ChuckPa’s DB repair utility - I do it regularly - but the db’s size only shrinks a couple of KB.

Has there been changes in the db schema?

Has anybody else noticed this size increase?

Worried if this could cause performance issues.


MODERATOR EDIT (@FordGuy61, 18 Aug 2025): A quick TL;DR reference, as this thread has gotten very long.

Overview

Some versions of PMS 1.41.7.x have a bug that caused the database files to grow abnormally large, adversely affecting Plex Media Server operations.

As of this writing, PMS should be updated to the current release, 1.42.1.10060. Doing so (a) stops the abnormal database growth, and (b) avoids a security issue announced on 08 Aug 2025 ( Plex Media Server - Security Update ). 1.42.1.10060 also contains code to clean the database, returning to its normal size.

How to de-bloat the database:

Option 1: Run a Linux script / Windows bat file.

Option 2: Let Plex Media Server debloat the database.

This will occur when Plex Media Server optimizes the database as a scheduled task.

Details
See this post for the pros / cons of each approach: Library.db size more than doubled in latest version - #470 by FordGuy61

The full thread has many more details. If you’ve any questions, reply to the thread and someone will assist.

Regards,

@FordGuy61

Are you sure you mean KB?

Missed the three last numbers though :grinning_face:

I’ve done quite a big clean-up and removed a lot of stuff which is no longer relevant.

Two screenshots for comparison. Look at the sizes and the dates.

Actual DBs

Backups

Note the size of the 2025-05-15 backup, It was yesterday.

The library.db has grown since I posted earlier and PMS has been untouched.

That’s still megabytes, not kilobytes.

I wonder how the db size of previous to current day would compare, if you disabled all scheduled tasks.

You are right. I missed the last 3 digits in my post.

I have the same scheduled tasks I have had for years without the db increasing in this manner.

Scheduled Tasks

There must be something else. Compare the size of the backup db from yesterday to the size of the actual db from today.

The question is: Is this happening to anybody else?

At least not to me, as the screenshot from my server above demonstrates. The file sizes have been in these regions for months (I’m not adding very frequently).

Okay, thanks.

I’ll keep an eye on it and post back if something happens.

I think I might have an idea what’s going on here.

We’re looking into it.

If you want to roll back to the previous beta and see if that helps prevent the issue further that would be helpful too: https://artifacts.plex.tv/plex-media-server-beta/1.41.7.9749-ce0b45d6e/windows/PlexMediaServer-1.41.7.9749-ce0b45d6e-x86_64.exe

2 Likes

Thanks!

I’m a little wary about downgrading. Anything goes wrong and I’ll get a lot of flak from my wife and daughters :slight_smile:

1 Like

I’ve found the problem and there should be a fix deployed later today.

4 Likes

Thanks a lot!

Just noticed the same thing on my system. Will the fix shrink the database back to it’s original size?

2 Likes

I have the latest Beta installed (Plex Media Server - #673 by chris_decker08 - 1.41.7.9795) and the DB is still growing significantly faster than it ever has. Up until today mine was 250 MB

At 5:05PM US Mountain time it was 246.35 MB. At 8:02 PM US Mountain time it is 278.2 MB with 2 people watching (1 remote, one local). Logging in and its definitely the statistics_bandwidth table still.

Adding some more data from just now. Earlier I deleted all of the statistics for 2025-05. I just now re-rant the following:

sqlite> SELECT
   ...> strftime('%Y-%m', datetime(at, 'unixepoch')) AS month,
   ...> COUNT() AS count,
   ...> COUNT() * 100.0 / (SELECT COUNT(*) FROM statistics_bandwidth) AS percentage
   ...> FROM statistics_bandwidth
   ...> GROUP BY month
   ...> ORDER BY month DESC;
2025-05|2024012|76.2083125305453
2025-04|5675|0.21367569639451
2025-03|1280|0.0481946945171758
2025-02|1158|0.0436011376960074
2025-01|584366|22.0026100439249
2024-12|1067|0.040174796132677
2024-11|1062|0.0399865356072193
2024-10|908|0.0341881114231216
2024-09|762|0.0286909040797562
2024-08|844|0.0317783766972628
2024-07|962|0.0362213250980649
2024-06|860|0.0323808103787275
....(continues with similar numbers)

so what version does this actually affect? I see the latest beta version addresses this. I’m on 1.41.6.9685

I’m not sure about that either. I was definitely not on the beta and started seeing this 2 days ago. I manually went in and deleted all of the statistics_bandwidth data from this month and it shrunk my DB back down. When I restarted I force upgraded to the Beta which per the release notes has a fix, but that’s clearly not the case.

Mine has increased considerable this month with the betas. Even in Jan it went up. Is there a command that I can do cleanup the statistics?

2025-05|157552047|74.7565088064111
2025-04|7410|0.00351595387558187
2025-03|3019|0.00143247837387067
2025-02|2588|0.00122797417408986
2025-01|53113773|25.2018321222841
2024-12|2879|0.00136605009551959
2024-11|2494|0.00118337233005414

Yes, but it will be a while before it happens automatically - the higher resolution bandwidth statstics live in the database for 30 days, this would be the data which is consuming most of the disk space.

1 Like

If you deleted the data in the table you should expect a larger initial size increase as the initial rows are populated.

Only affects the 1.41.7.9784 build.

1 Like