No bandwidth statistics stored

Plex Media Server
41

I fixed the issue - run this command on your database… but backup first, just in case!!

BEGIN IMMEDIATE;

– 1) Create the correct table (note: id INTEGER PRIMARY KEY)
CREATE TABLE statistics_bandwidth_new (
id INTEGER PRIMARY KEY,
account_id INTEGER,
device_id INTEGER,
timespan INTEGER,
at INTEGER,
lan INTEGER,
bytes INTEGER
);

– 2) Copy your existing rows. We omit id so SQLite assigns proper, increasing ids.
INSERT INTO statistics_bandwidth_new (
account_id, device_id, timespan, at, lan, bytes
)
SELECT
account_id,
device_id,
timespan,
at,
COALESCE(lan, 0),
bytes
FROM statistics_bandwidth;

– 3) Swap tables
DROP TABLE statistics_bandwidth;
ALTER TABLE statistics_bandwidth_new RENAME TO statistics_bandwidth;

– 4) Recreate the expected indexes
CREATE INDEX IF NOT EXISTS index_statistics_bandwidth_on_at
ON statistics_bandwidth(“at”);

CREATE INDEX IF NOT EXISTS index_statistics_bandwidth_on_account_id_and_timespan_and_at
ON statistics_bandwidth(account_id, timespan, “at”);

COMMIT;

VACUUM;

3 Likes
42

Multiple reasons have been suggested as to what might have caused the bandwidth statistics no longer being stored, by multiple users:

  • ran delete-query to remove excessive data from table statistics_bandwidth
  • ran PlexDBRepair
  • ran Deflate
  • shutdown & restart PMS (not a re-install)
  • installed a newer version of PMS (just an upgrade with existing data)

The only thing that is consistent in this for multiple users is that a newer version of PMS was installed. Either by explicitly install a new version or by restarting a docker container (which always installs the newest version).

I’m not sure if any of the affected users run or ran the beta version of PMS. I know I did run the beta, but I switched to the stable branch in an attempt to fix this issue and have not reverted back since.

At the time the problem started for the known users, changes were being made to Plex to fix excessive records being inserted in the table statistics_bandwidth in an attempt to fix that issue.

I believe that in the process to fix that issue, 1 or more released PMS versions contained a bug that would break the bandwidth statistics permanently if the user installed that version. That bug has been fixed in a later version, but leaves the users that have run the buggy version with a permanently broken bandwidth history. A lot of users don’t upgrade that often, so this probably only affects a small set of users.

Given this is all related to statistics_bandwidth, there must be a way to check:

  • if the table structure is incorrect.
    I think this one is a stretch, I don’t see a reason this would have changed.
  • records are missing
    I suspect PMS depends on records in this table with “account_id=null” for keeping track of historic usage and these records have either been deleted by a user or PMS itself in an attempt to fix the database-too-big-issue.

Both are simple to check, but I don’t know what should be in there by default.
I’m tempted to install a seconds PMS and check that database in an attempt to fix it myself, but I don’t have the time at the moment.

If anybody has a PMS running where the history works normally, I’m really curious at what is in the database for:

  • The table structure of statistics_bandwidth.
  • What records exist when the query below is run:
    SELECT * FROM statistics_bandwidth WHERE account_id IS NULL

I’m also curious what the nature was of the bug that caused the huge databases.
I suspect PMS stores bandwidth usage per hour when it happens. Then periodically (when they are 7 days, 30 days, 90 days, etc old) those records are combined and put in a record that spans a longer period. There probably was a bug that didn’t delete records after combining them.

All this will probably point us to what the problem is and find a path to fixing it.

I totally agree with @pl71303 that a complete re-install of PMS is simply not an acceptable solution.

1 Like
43

@kevvybear Nice job! Awesome that someone finally figured it out!

1 Like
44

Question ???

From discussion in this thread,

Was this not preformed ?

chuck@ds418j:/volume2/chuck/Deflate/databases.2025.05.17$ cat Deflate 
#!/bin/bash

PSQL="/var/packages/PlexMediaServer/target/Plex SQLite"

echo ==== Current listing
ls -lah

echo ==== Vacuuming into new DB
time "$PSQL" com.plexapp.plugins.library.db << EOT
  CREATE TABLE temp_bandwidth as select * from statistics_bandwidth where account_id not null;
  DROP TABLE statistics_bandwidth;
  ALTER TABLE temp_bandwidth RENAME to statistics_bandwidth;
  CREATE INDEX 'index_statistics_bandwidth_on_at' ON statistics_bandwidth ('at');
  CREATE INDEX 'index_statistics_bandwidth_on_account_id_and_timespan_and_at' ON 'statistics_bandwidth' ('account_id', 'timespan', 'at');
  VACUUM main into './new.com.plexapp.plugins.library.db';
EOT

echo ==== Deflated DB listing
ls -lah new.com.plexapp.plugins.library.db
chuck@ds418j:/volume2/chuck/Deflate/databases.2025.05.17$
How it works,

The last step is what deflated the DB.
When done, rename the DBs and all is complete.

45

I ran this instead, as I was not able to run the stats using the tool due to lack of HDD space which fixed the issue with bloated stats: Library.db size more than doubled in latest version - #144 by toxicbubble .

Ran this back in May though, had view stats for a few months after. Seems like that mid-July update is the culprit here.

46

This solved the problem for me.

The actual problem for me was that the table statistics_bandwidth was missing it’s primary key. If you want to check this, run .schema statistics_bandwidth in SQLite on the database. If there is no “PRIMARY KEY’ AFTER ID, it is not there.

The DBRepair too did not pick this up unfortunately. It appearantly does not check the table structures itself.

What caused this?

The query I used to fix the huge table made a copy of the original table like so:

CREATE TABLE statistics_bandwidth_new AS
SELECT * FROM statistics_bandwidth
WHERE account_id IS NOT NULL;

This does not create the primary key on the new table.

I had to use this query, because the simple delete query was waaaaay to slow because the table was way to big.

So, check your table structure if you don’t have history, the solution for me was in @kevvybear ‘s post.

3 Likes
47

@kevvybear - Yer a genius!

A solution that doesn’t require me to trash my entire system and rebuild it from scratch!

However on first run, it choked stating “no such column”, so I had to remove the quotes around the “at”

image
image1297×357 47.4 KB

Run just fine afterwards, and now I am building new history :+1:

image
image544×868 39 KB

1 Like
48

Excellent :blush: I was pleased to find a solution!

49

However on first run, it choked stating “no such column”, so I had to remove the quotes around the “at”

I had the same issue. This was probably caused by the forums replacing plain quotes with fancy ones to make it look better.

2 Likes
50

I tried the updated table indexing steps, but unfortunately still no stats being written. Not sure if I did it wrong or what, but will try the steps again at some point. Also had the issue with the quotes, good old forums.

1 Like
51

I would like to thank @kevvybear for the solution, as now my history is saved again!

One issue - the real time graph is always displaying 0 bandwidth for some reason. But this is less important than history.

Anyway, if someone had the issue with real-time bandwidth graphs not working and fixed it, I would appreciate sharing the solution :slight_smile:

1 Like
52

There is a bug in realtime graphs in 1.41.7 and some early 1.41.8 builds.. Update PMS and see if it is fixed. Let me know :blush:

53

Sadly, even after updating to newest version, still there is no real time bandwidth. Maybe I will have to redo my plex install.

54

@komorka123

1.41.7 - 1.41.8 introduced the bandwidth issue.

1.42.2 will fix that IF the DB is also fixed.

Questions:

  1. How big is your com.plexapp.plugins.library.db file?

  2. Are you on a Linux platform and, if so, how comfortable are you with the command line?

55

Hi, thanks for replying.
Plex is installed on bare windows (no docker, etc). My com.plexapp.plugins.library.db it is 192 MB.
I can use CLI if I am given exact commands to copy & run inside it. I have 0 knowledge about SQL in plex.

56

I had hoped you were using Linux. ( I can help with Linux )

I will get some help for doing this on Windows and then give you those instructions.

While looking at your account, I saw you had 12 abandoned server instances.
I’ve removed them for you.