I fixed my database size with the delete query successfully some time ago. It has stayed a normal size ever since.
I have a new problem that started immediately after I applied the fix.
In my dashboard there is a graph “Bandwidth”. The realtime-graph works normally. But if I select “Last ….” it only shows data up to the moment I fixed the database.
It seems the bandwidth history isn’t added anymore.
Is there any fix for this?
Which one was that? If you picked one of the earlier ones, you might have permanently disabled the bandwidth statistics from getting remembered.
Which one was that?
It’s been some time ago, not sure anymore.
And surely there is some kind of fix.
Surely. If we knew what you did.
Had to search a while in this very long thread.
Did the query from @drzoidberg33, it was quite fast actually, probably because it’s a fast server and an SSD.
delete from statistics_bandwidth where account_id is NULL;
After running this my bandwidth_usage history is no longer appended with usage per day/hour.
play history is not affected.
Did you also perform a database repair? It’s highly recommended to do that.
I did not at the time.
I’ve run it now with “automatic” and “vacuum”.
It did report “PMS main database is damaged.” before the run, and “PMS main database is OK.” afterwards.
I’ve played some short content afterwards (until end of file). Now waiting to see if the bandwidth history is populated. It is not yet visible after a few minutes, I’m not sure how long this normally takes.
Waited more than 1 hour to see if any bandwidth history would appear.
The 12 hour graph still only shows one time point at “01:00” with no actual data in it. (same as before).
The bottom of the graph shows this text “Totals: Remote—NaN undefined | Local—0 B”. I’m not entirely sure if this is the same as before.
I’ve just noticed that I am experiencing this as well….
It would appear that Plex has stopped recording since I last ran the PlexDBRepair batch file on my database files on the 29th June 2025.
Real time bandwidth monitoring works just fine, however no stored history after that point.
It would appear that Plex has stopped recording since I last ran the PlexDBRepair batch file on my database files on the 29th June 2025.
Did you do anything else with your database on that day?
Did you delete records from the database like I did above?
Did you upgade Plex server to a newer version?
DBRepair does not modify the contents of the DB file.
Therefore, if you still have a backup from before the 29th June, you can swap out the current and swap in the backup and retest
I doubt DBRepair is the cause. I only ran DBRepair 6 weeks after I ran the query, and the problem already existed at that point.
I don’t have a backup anymore, because the database was huge before I ran the query. So I want to find a fix with my existing database.
That being the case, if you really want the stats then the solution is to reload PMS from scratch.
Remember, if viewstate sync is enabled, all your watch history will be restored.
reload PMS from scratch.
How do you do that? Just stop & start PMS? Because that has happened loads of time since and hasn’t resolved the issue so far.
My PMS is running in a docker container.
Looking at your Plex.tv account, it looks like you’re using Docker ?
If that’s true then you would delete the docker container and where the metadata is stored on the hard drive (everything under where /config is mapped)
Once you delete everything, you’ll create a new server instance.
I said in the previous post is was using Docker.
How is it that this is visible from my account?
I dont want to delete all data (excluding media) and reconfigure my server. That is just silly and I can’t believe you are seriously suggesting that.
It got broken by deleting records from 1 table on the advise of somebody on this forum that was labelled Plex employee.
this should be fixable by inserting some missing records. I just need to know which those are.
Or even better if there is a more simple solution.
I work for Plex and can see basics of the server. That’s how I can tell the server is in a Docker container. I’m sorry for missing that info above.
My initial reply was based on the presumption you have a damaged DB (missing tables in the DB associated with bandwidth statistics.
The specific table you’re referring to is statistics_bandwidth.
The fuss about the statistics_bandwidth table was because it would bloat wildely and increase an otherwise 280 MB database to something crazy like 40+ GB.
Before proceeding any further, I need to see your server’s DEBUG logs to confirm it is not complaining about anything involving that statistics_bandwidth table.
No, no and no.
@ChuckPa - Don’t have any DB backups prior to 29th June… What other options are available here?
What about the viewstate for all the other users, and will this method mean a complete rebuild of the libraries from scratch as well?
EDIT:
@ChuckPa - Just read your last post… If I had a missing table, wouldn’t that imply that I would absolutely no historic statistics data at all?
In theory, on the basis that I still have all historic statistics data prior to the 29th June, that must imply that the table is still there but the app is no longer updating it.
In a previous post you can see what query I ran to reduce the size of my database. In my case it was over 80gb. In the same folder were several backups of similar size. I guess I had over 400gb of database storage.
I only ran that query and a vacuum.
The history before it ran that query is still there.
There is a possibility that it was not caused by the query, because in the same day I checked it if was running the latest version. It is a bit strange to me that axemanuk666 perform started on virtually the same day, and he didn’t run the query. So it might be in a single released version.
I’m confident the table exists in my database. So please post what fix you have in mind. I will do some checks before executing those queries. I’m no stranger to SQL and databases.
