I did those exact same steps as part of the previous repair process, however, I didn’t save the temp files.
Will that encourage bad results?
NOPE. There is no harm deleting the TMP files after you’re done .
( They only exist in case you need emergency recovery during the repair process )
How is it behaving?
- Smaller files?
- Faster searches ?
Similar file size of o recall from the output, if anything I might have saved 3MB total on one of the DB files.
As far as searches, definitely faster.
Also in terms of UI responsiveness on players, substantially better. Sometimes images wouldn’t load, now they’re working great.
Playback responsiveness seems to have improved in one of the servers (locally) rather then waiting 1 or 2 seconds for it start playing the file as well, though that might be an artificial experience.
Fwiw, I thought you wanted to do comparisons with the original file. I figured as much regarding them being backup files 
What you should find is that the DB operations
-
Searches
-
Loading a library section for display (posters images are also dependent on disk/network speed)
-
Player UI … Pre-Play screen should now be there as you click the item to play
Hi there,
big fan of you Database optimization script @ChuckPa .
One question though:
I’m trying to automate database optimization on my Synology NAS via setting it as a planned Task.
Using “…/DBRepair.sh 1 4 3 9” i am able to successfully run all the optimizations, however I am not able to exit the script, because it asks for keeping the temp files which has to be confirmed twice by sending “Y”. Is there any way to circumvent this?
Of course I’ve scripted to stop and start PMS again afterwards.
I don’t think i need the temp files, because I’m doing full backups of the Plex AppData once a week anyways.
I could however live with one set of temp files that’s being kept, because my library isn’t that big to begin with. Does the script only keep the last tempfile-set or does it keep piling them up?
Do you even think it’s smart to do these steps unattended or should i better SSH in every now and then and do it by hand to watch for problems. Or otherwise: Are some of the steps maybe safe to run unattended, just to keep the library maintained neatly?
Thanks in advance for any input you can give.
Read the “Readme”, and am I correct that PlexDBRepair cannot be run on a PMS installed on a Raspberry Pi 4?
What’s the OS installed ? Ubuntu / Debian Linux ?
-or-
PMS in a Docker container ?
The runtime environment is critical. “What does it look like?”
@ChuckPa not sure if you have observed this yourself but said I’d mention it.
After I upgraded to the latest beta 1.30.2.6563 and completing a force refresh of my libraries including optimise database my db size reduced by approx 5%. Anything that reduces the db size is a good thing so I guess some of the work in the 1.30.2 release has had database improvements.
1 Like
Debian Linux
Linux pi4 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023
aarch64
EDIT: Looking at your script, I see now that it will work on my system.
Thanks for this program!
Here the successful log:
2023-01-11 07.50.01 - ========================================================
2023-01-11 07.50.01 - Session start: Host is Debian GNU/Linux 11 (bullseye)
2023-01-11 07.50.24 - Check - Check com.plexapp.plugins.library.db - PASS
2023-01-11 07.50.31 - Check - Check com.plexapp.plugins.library.blobs.db - PASS
2023-01-11 07.50.31 - Check - PASS
2023-01-11 07.51.39 - Repair - Export databases - PASS
2023-01-11 07.52.04 - Repair - Import - PASS
2023-01-11 07.52.07 - Repair - Verify main database - PASS (Size: 96MB/78MB).
2023-01-11 07.52.08 - Repair - Verify blobs database - PASS (Size: 112MB/120MB).
2023-01-11 07.52.08 - Repair - Move files - PASS
2023-01-11 07.52.08 - Repair - PASS
2023-01-11 07.52.12 - Reindex - MakeBackup com.plexapp.plugins.library.db - PASS
2023-01-11 07.52.13 - Reindex - MakeBackup com.plexapp.plugins.library.blobs.db - PASS
2023-01-11 07.52.13 - Reindex - MakeBackup - PASS
2023-01-11 07.52.19 - Reindex - Reindex: com.plexapp.plugins.library.db - PASS
2023-01-11 07.52.20 - Reindex - Reindex: com.plexapp.plugins.library.blobs.db - PASS
2023-01-11 07.52.20 - Reindex - PASS
2023-01-11 07.55.07 - Exit - Delete temp files.
2023-01-11 07.55.08 - Session end.
2023-01-11 07.55.08 - =========================================================
I also want to chime in to thank @ChuckPa for the script - the db optimization definitely improved the responsiveness of the UI. Perhaps this step could be performed during Plex updates (since the main process is shut down during updates and thus disconnected from the sqlite db) but I will run it manually for now!
Same here 
1 Like
My work is “3rd Party” to PMS. It won’t be integrated with PMS
If you want to script it to run then that’s fine; it’s what I do
as root:
systemctl stop plexmediaserver
/vol/scripts/DBRepair.sh 1 4 3 9
systemctl start plexmediaserver
I set the cache to 128 and ran the ChuckPA script 1, 4, 3, 9 and PMS rips through. Even though we are on an Intel P3700 NVME it was already fast but now it’s FASTER!
Setting the cache to anything other than default hasn’t been needed so far.
I’m surprised you need to.
The problem isn’t actual ‘cache’ size. The problem the tool corrects is the internal database structure and fragmentation.
My tool completely defragments the internal structure of the DB.
Yea, I wasn’t sure if the cache size did much when I set it but the script def seems to have sped things up.
The best indicator we’ve found so far is when performing searches.
Searches seem to load before I even type anything! That’s how fast it is! HAHA.
One thing I did need to do to the script first is force it to use the docker option because I’m using podman and the detection wasn’t working properly.
Are you trying to run it from OUTSIDE the container ???
(trying to run OUTSIDE is impossible to detect given everyone’s config is different)
If inside, I need to know which image you’re using.
I currently support Plex official, Linuxserver, BINHEX and HOTIO.
Inside, official Plex image.
That’s the primary one I support.
What did you do differently to it?
It needs
- /usr/lib/plexmediaserver/executables
- /config/Library/Application Support/Plex Media Server/Plug-in Support/Databases
Here is the detection code.
# Docker
elif [ "$(grep docker /proc/1/cgroup | wc -l)" -gt 0 ] || [ "$(grep 0::/ /proc/1/cgroup)" = "0::/" ]; then
# HOTIO Plex container structure is non-standard (contains symlink which breaks detection)
if [ -d "/app/usr/lib/plexmediaserver" ] && [ -d "/config/Plug-in Support" ]; then
PLEX_SQLITE="/app/usr/lib/plexmediaserver/Plex SQLite"
AppSuppDir="/config"
PID_FILE="$AppSuppDir/plexmediaserver.pid"
DBDIR="$AppSuppDir/Plug-in Support/Databases"
LOGFILE="$DBDIR/DBRepair.log"
LOG_TOOL="logger"
HostType="HOTIO"
return 0
# Docker (All main docker variants except binhex and hotio)
elif [ -d "/config/Library/Application Support" ]; then
PLEX_SQLITE="/usr/lib/plexmediaserver/Plex SQLite"
AppSuppDir="/config/Library/Application Support"
PID_FILE="$AppSuppDir/Plex Media Server/plexmediaserver.pid"
DBDIR="$AppSuppDir/Plex Media Server/Plug-in Support/Databases"
LOGFILE="$DBDIR/DBRepair.log"
LOG_TOOL="logger"
HostType="Docker"
return 0
# BINHEX Plex container
elif [ -d "/config/Plex Media Server" ]; then
PLEX_SQLITE="/usr/lib/plexmediaserver/Plex SQLite"
AppSuppDir="/config"
PID_FILE="$AppSuppDir/Plex Media Server/plexmediaserver.pid"
DBDIR="$AppSuppDir/Plex Media Server/Plug-in Support/Databases"
LOGFILE="$DBDIR/DBRepair.log"
LOG_TOOL="logger"
HostType="BINHEX"
return 0
fi
