just to let others know.
I solved the issue by emptying the statistics tables in the sqlite db.
one had 4 million rows.
on windows you can edit it with sqlitebrowser
then just DELETE FROM TABLENAME
to empty it
just to let others know.
I solved the issue by emptying the statistics tables in the sqlite db.
one had 4 million rows.
on windows you can edit it with sqlitebrowser
then just DELETE FROM TABLENAME
to empty it
Thanks for sharing! Did you empty all the stats tables (statistics_bandwidth, statistics_media, statistics_resources)? Or what specific table did you target? My bandwidth table has 30K rows but the others are very small 5K and 0 respectively. I’m still experiencing lots of these errors in my logs…
I am also on the latest PMS on my Synology. I have just removed my entire database as suggested on the repair page. However, when adding the first library (photos) I am constantly getting the messages: Took too long…, Held transaction for too long…, locked database (only a few times) Also getting this: SLOW QUERY: It took 3600.000000 ms to retrieve 1 items.
Whats the status from the devs for this issue, it seems a lot of people have issues with it.
Just here to report, having the exact same issue.
Did manual DB optimalistion, rebooted the server, and PMS doing nothing at the moment (no clients, no other tasks) i get tons of the “held… for too long” in log file.
Server is a 9900K, Ubuntu 18 LTS running from a 970Pro nVME SSD.
#Windows Plex Media Server version 1.18.2.2058-e67a4e892
Yep I’ve got this issue too, server should be idle, but cpu maxed out.
Only logging is in “Plex Media Server Log” with the “WARN - Held transaction for too long (…\Statistics\StatisticsManager.cpp:248): 0.156001 seconds” messages every few minutes. Statistics_bandwidth db table only 1200 records, media=300 resources = empty, but deleted records anyway.
I closed PlexMediaServer from tooltray (took about a minute), re-ran and it’s off again using 100% cpu, so Plex has become unusable as nothing can connect to it. Rebooting PC.
Doing what i said above fixes the issue. You will only lose your stats.
see post above “deleted records anyway… re-ran…100% cpu”). So it didn’t fix.
I have now rebooted PC and for now it isn’t doing it, but something may trigger it off again. I recently disabled the DLNA server as I became suspicious of that. I have seen PMS ghost tasks hogging cpu a lot recently whereas never before.
I see 1.18.3.2111 has just popped up, but no fixes relevant to this.
If you downgrade to 1.14 issue goes away (you can check CPU stats). It is because issue added in 1.15.
Confirmed. Every version since 1.14 has this issue.
I can confirm I have this issue too. My library starts scanning my Music folder and that’s when it happens (grinds to a halt until its unusable).
Can I configure what time it does this? 7pm doesn’t feel like a very good time to do it…
I know you can schedule a specific time for thumbnails and loudness, but it seems to just do it whatever time it wants for library scans?
How big was your tables and your database? My statistics_bandwidth only had 8K rows but my statistics_media had 13551338 entries. My database is 1.2gb in size.
How does that compare to other peoples sizes?
Forgive me, while I found these instructions helpful, they were a bit vague. Here’s a step-by-step for how I went through this process on my FreeNAS server:
Navigate to the appropriate directory –
cd /usr/local/plexdata/Plex\ Media\ Server/Plug-in\ Support/Databases/
Stop the Plex Media Service –
service plexmediaserver stop
Make a backup of the Plex database file –
cp com.plexapp.plugins.library.db com.plexapp.plugins.library.db.bak
List the database tables –
sqlite3 com.plexapp.plugins.library.db .tables
Nuke the data within the appropriate tables –
sqlite3 com.plexapp.plugins.library.db "DELETE FROM statistics_bandwidth"
sqlite3 com.plexapp.plugins.library.db "DELETE FROM statistics_media"
sqlite3 com.plexapp.plugins.library.db "DELETE FROM statistics_resources"
Start the Plex Media Service once again –
service plexmediaserver start
And just for good measure, you should probably go into Settings > Troubleshooting > and click “OPTIMIZE DATABASE.”
@snailbrain 's tip about the statistics_* tables in the database has really helped. This has made my Plex Media Server responsive again. I’ve been taking a close look at the Plex database and what I’ve observed seems unusual. I am not a db expert, but my statistics_media table had more than 4.2 million entries. As I browse the database, the next largest tables I can find have just under 40 thousand entries - I’ve got a reasonably large, but not huge media library.
24 hours after cleaning these tables, I notice that statistics_media is back up to 66 thousand entries! That’s after a day of very light activity. Can this possibly be right? Plex Team, this definitely looks like buggy behavior in my eyes. Allowing a relatively useless db table like this to grow to millions of entries, thus bogging down CPU and db performance just seems…illogical and avoidable. I would encourage you to implement some kind of db pruning or archiving routine in future releases.
My statistics_media table had 6+ million entries in it as well. I deleted everything in that table and within 5 days the “Held transaction for too long” and “Sqlite3: Sleeping for 200ms to retry busy DB.” were back. I checked the statistics_media table again and it was at 700k+ entries… Not sure what to do here too…
Before cleaning, my database was about 327 MB. After cleaning statistics_media (4.2 million entries) and optimizing, the db shrank to about 97 MB. The largest table I encountered in the database aside from that had just under 40,000 entries. In less than 24 hours statistics_media grew to over 66,000. Something seems very wrong.
Changing user and group permissions did it for me.
I think months ago when I restore my db I forgot to change the permissions.
change the path of your lib and run:
chown plex:plex “/srv/disk1/plexdata/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db”
you can check existing permissions with:
ls -l “/srv/disk1/plexdata/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db”
output:
-rw-r–r-- 1 plex plex 319483904 Feb 1 10:40 ‘/srv/disk1/plexdata/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db’
PRO TIP(!!):
ignore the console output!
Im using PMS since 5 years on my PI as free user, didn’t have the console and everything was fine. Now im testing the PASS features and the fist I’ve seen was this error (= A BIG PROBLEM
) and I was researching.
Conclusion: Makes no problem out of harmless things and enjoy your life
@the_plex_devs
it would be very sophisticated if you build a restore function beside the download db function to avoid those conflicts.
how does a casual user handle restoring? copy them back. how often your as dev run into trouble because you forget to set correct permissions?
think about it.
I sent along time on this battle too and found a solution that works for me. I have a Ubiquiti controller on my network that has layer 2 discovery enabled on it. Plex would see the SSDP request that went out every 30ish seconds and try to parse it. Every attempted ended up with this error:
ERROR - SSDP: Error parsing device schema for http://:8080/upnp
I disabled the layer 2 discoverability option and the error went away along with these errors:
Mar 20, 2020 22:37:37.311 [0x7f85867fc700] WARN - Waited one whole second for a busy database.
Mar 20, 2020 22:37:38.061 [0x7f85cb7fe700] WARN - Held transaction for too long (…/Statistics/StatisticsManager.cpp:252): 0.430000 seconds
Doesn’t make sense, but I’ve been error free for several weeks now.
Thanks for this, my server library.db was at 5.6G. Cleaning statistics_media took over 30 minutes to bring it down to 62M. I also needed to optimize database from troubleshooting to have the db file reflect the change.
$ ls -lh com.plexapp.plugins.library.db*
-rw-r--r-- 1 plex plex 62M Apr 3 18:23 com.plexapp.plugins.library.db
-rw-r--r-- 1 plex plex 5.6G Mar 24 02:43 com.plexapp.plugins.library.db-2020-03-24
-rw-r--r-- 1 plex plex 5.6G Mar 27 02:31 com.plexapp.plugins.library.db-2020-03-27
-rw-r--r-- 1 plex plex 5.6G Mar 30 02:39 com.plexapp.plugins.library.db-2020-03-30
-rw-r--r-- 1 plex plex 5.6G Apr 2 02:28 com.plexapp.plugins.library.db-2020-04-02
I’m glad you found it helpful. I’ve actually put all of these commands into a bash script which runs as a cron job twice a week. I haven’t had any playback delays or failure to recognize new content since I started doing that. It’s finally back to the behavior of the old Plex that I know and love.