If we are purging 50,000 an hour it would take 10 hours - you can wait till tomorrow and see if things change
Or you could enable ssh and use Linux to look around and see if PMS is still purging items
I just got an OOM error email from my NAS, so I believe Plex crashed. I’m logging in now. Should I upload logs?
@sa2000 Yeah, Plex crashed due to OOM. Here are the logs. The movie is still in the library, and I’m nervous about trying to view the info or scanning the library again. Do you know what I should try next?
Can I get the database as well to see how many extras remain
Downloading now
@sa2000 Here you go! Hopefully I was lucky and it got through some of them!
@SuperDragonite - appears that the purge was running whilst the server was crippled because a request came in at 09:31:52 to get the metadata for the movie and that was request was still in progress 2 hours later when the server crashed with OOM. This request is what led to the OOM failure.
In parallel to this the library was being scanned and the extras were being purged - but very little memory free
And it appears the purging has not been committed to the database and the new database copy shows them still there.
So for this approach to work, the metadata for the movie must not get loaded for any Plex client (eg Plex Web or if you have 3rd party products scanning the library) and the purging needs to run to its completion
It is looking like we have to resort to the brute force method worked out by @Volts and @shayanzadeh and @jakehoms and used by others here and in other forum thread
Which is to manipulate the database - to remove the extras for this movie and then after that update a number of tables removing orphaned items as a result of purging and then optimizing the database
The offending item in your case is metadata_item_id 15484
1 Like
@sa2000 Ah, this makes sense since I noticed it requested a metadata update after I tried to open the media info in a Plex app. I wonder if I should have force closed Plex and then scanned the library.
Based on what you’re saying, I think I can do another scan right now and I shouldn’t have the metadata-fetch request issue again. I don’t foresee anyone trying to watch this movie right now. I just started the scan; hopefully that works.
If it doesn’t, I see you’re recommending I interact with the database directly. I have a tiny bit of mySQL experience, but I am definitely no expert. Do you have an interface you recommend performing these steps in?
Edit/Update: Yeah, memory usage is at a normal rate right now, and I haven’t seen a metadata request on that movie yet. I’m hoping this time it works!
@sa2000 Quick update, sorry if I’m being annoying!
Currently I’m at ~600 deleted items according to the console logs. I think you said I have about 500,000? Based on my math, this will probably take about a week at the current rate. So, I should probably go ahead and use the manual method you’re recommending.
Am I safe to follow the command instructions in that post and just replace the ID with the one you’ve given me? Just want to make sure I’m not going to break my db!
The steps outlined in the linked forum thread:
Deleting the items in metadata_relations table
In your case it would be this change
DELETE FROM metadata_relations WHERE metadata_item_id = '15484';
and after committing that change - then purging all orphaned items - which can be done using an sql.txt file provided here
The binary used is covered here
Repair a Corrupted Database | Plex Support
(I am actually part time and my next day on Plex is Wednesday - so you will need help from others)
Thanks for your help so far! Last question: Do I just want to download a SQL editor for the delete step? And then do I run that command inside a SQL editor or through SSH terminal?
No - you must use the Plex Media Server own sqlite3 binary as there are some collations that stop it working using other editors
See the Repair Corrupt Database support article I linked
Ok thank you, I’m currently figuring out the commands I use to run these in SQLite from the guide you sent. I should have this done soon.
I did it! Woo! Delete query took a few seconds. Currently running the sql.txt file right now, which is taking longer (as expected)!
Completed. Database is now 220 MB. I will follow up in a week!
1 Like
Hi - good to hear that you managed to run the sqlite3 db updtaes
I would be interested in knowing how long it took for the two db update steps
- The deletion of the related items from table metadata_relations
- Running the sql.txt transactions to remove all orphaned items
1 Like
I noticed that wrapping the cleanup in a transaction made a big difference in speed. I also figured it was safer, so I added the BEGIN/COMMIT to the sql.txt.
That’s probably obvious, I just wanted to mention it in case you add a similar cleanup or migration to Plex itself.
- Took about a second. At first I wasn’t sure if it worked because it was so fast.
- Took 10-20 minutes I’d say. Definitely under a half hour. I was doing other things and came back to it.
1 Like
Update: Three days after the last crash, and it didn’t crash! I will follow up again in a few days with the logs and database!
2 Likes
