I’ve noticed a “Detection” folder within my Plex Transcode directory that is absolutely eating up storage. I assume it’s the temporary files used for intro detection but it appears they’re never cleared away once detection is finished.
I originally had my transcode location set to RAM but noticed high usage from this folder so moved it to disk to see how big it would grow.
I moved it to disk Monday evening, it’s now Wednesday morning and the folder is 76GB, it’ll probably continue to grow as i add more media and it detects intros.
I thought at first maybe it was permissions stopping it from being able to remove the files but the permissions are the same for the “Sessions” folder which still grows & clears as i transcode when people watch content, so plex doesn’t appear to have any problem with clearing the data down for the general “Transcode” location, it just doesn’t seem to be doing it for the “Detection” folder.
I tried searching to see if anyone else had this problem but couldn’t find anything so I thought i’d post and ask. It seems like it’d be an obvious enough problem to notice, especially with those who transcode to RAM so I was surprised not to hear anyone else with the same issue.
If nobody else seems to have the problem and it’s likely to be something wrong with my setup I can attach logs. I just didn’t immediately because I’d accidentally left verbose logging on, only just unchecked it so now I need to wait for new content to come in with intros to detect.
(I assume debug logging can still be left on and won’t leave my token in the logs?)
Unraid Version#: Version: 6.8.3
Docker Image: Hotio/Plex
Server Version#: 1.19.4.2935
Player Version#: N/A
I imported a few new shows and also kicked off analysis on a few existing shows to ensure it ran through the intro detection process. Creating about 9GB of files in the last 3 hours.
Checking the database backups, looks like no backups available from Plex. Turns out i had my backup path set for an old container image layout, so the path doesn’t exist and I assume the files couldn’t be backed up because of it.
I should have at least a week of daily manual backups though if they’re needed?
On this note of database, I did have some database corruption a week or two ago, i followed the guide to repair it and all seemed to work fine at the time. Thought i’d mention it as I’m assuming something might be up with the database if you’re looking that way, rather mention it and not be relevant then not mention it and possibly waste time.
You can purge the old the temp files /mnt/user/media/downloads/plexcache/Transcode/Detection/xxx
and launch Plex Media Server and do some intro detection and then get debug logs to see if we have any issues and also check if any new temp files in that path get left behind
Okay so unfortunately it seems like when i run the final command of sqlite3 com.plexapp.plugins.library.blobs.db < blobs.dump.sql
The file it outputs is 0 bytes. The blobs.dump.sql file it’s created from shows 1.7GB though so unsure why it’s doing that? It’s causing Plex to not start so i have to revert back to the .original file
Removed the blobs database and Plex started up.
The detection temp files are now being cleared immediately and the detecting intros task actually seems to take some time now whereas recently it’s been zipping through them, fool me for assuming it was just a fast process.
Should i expect any data to be missing which needs to be recreated due to deleting the com.plexapp.plugins.library.blobs.db?
Tried to search to see what that database actually does but couldn’t find anything.
Let me know if you also wanted the blobs.dump.sql that didn’t seem to work. Thought i’d double check before uploading a 1.7GB file.
I did have a quick search for “error” in it though and found these 3 lines that were spread out:
CREATE TABLE IF NOT EXISTS 'media_grabs' ('id' INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 'uuid' varchar(255), 'status' integer, 'error' integer, 'metadata_item_id' integer, 'media_subscription_id' integer, 'extra_data' varchar(255), 'created_at' datetime, 'updated_at' datetime);
/****** CORRUPTION ERROR *******/
ROLLBACK; -- due to errors
