you didn’t hurt it
GO TO BED! 
Just to ask if it doesn’t find any errors on the 1 do I need the 4 since it’s repair?
YES. run 4 & 3.
Step 1 is only to check how badly, if at all, it is damaged.
When optimizing like this, I don’t expect any errors
ok thanks
Here is the log… GN
2022-12-13 23.28.25 - ============================================================
2022-12-13 23.28.25 - Session start: Host is BINHEX
2022-12-13 23.28.46 - Check - Check com.plexapp.plugins.library.db - PASS
2022-12-13 23.28.54 - Check - Check com.plexapp.plugins.library.blobs.db - PASS
2022-12-13 23.28.54 - Check - PASS
2022-12-13 23.38.18 - Repair - Export databases - PASS
2022-12-13 23.40.47 - Repair - Import - PASS
2022-12-13 23.41.01 - Repair - Verify main database - PASS (Size: 1389MB/1280MB).
2022-12-13 23.41.08 - Repair - Verify blobs database - PASS (Size: 4198MB/4250MB).
2022-12-13 23.41.08 - Repair - Move files - PASS
2022-12-13 23.41.08 - Repair - PASS
2022-12-13 23.41.13 - Reindex - MakeBackup com.plexapp.plugins.library.db - PASS
2022-12-13 23.41.17 - Reindex - MakeBackup com.plexapp.plugins.library.blobs.db - PASS
2022-12-13 23.41.17 - Reindex - MakeBackup - PASS
2022-12-13 23.41.48 - Reindex - Reindex: com.plexapp.plugins.library.db - PASS
2022-12-13 23.41.55 - Reindex - Reindex: com.plexapp.plugins.library.blobs.db - PASS
2022-12-13 23.41.55 - Reindex - PASS
That’s a really nice report… Looking very good.
So I ran the file in this tread out of my appdata folder and im getting the unknown host error. This is for my Hotio image in unraid.
Ooooooooooo’kay… 
Where is your “Preferences.xml” file ?
What’s the path. That’s what I’m looking for
Also please show the contents of grep /proc/1/cgroup | grep -i docker
So when i enter that command, the curser moves to the next line and nothing happens lol
Preferences.xml is in /mnt/cache/appdata/plex which is where the dbrepair.sh file is.
This isn’t telling me anything. Move what? where ? What’s supposed to happen? 
you mean cat /proc/1/cgroup ?
Do that INSIDE the container please 
From inside the container, that’s where I need to know where Preferences.xml is.
It’s all namespace (container context) relative/
Consider this:
[chuck@lizum docker.2006]$ docker container list
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
78983312f52f binhex/arch-plex "/usr/bin/dumb-init …" 17 hours ago Up 17 hours binhex
e994fcd63a2f plexinc/pms-docker:plexpass "/init" 4 days ago Up 19 hours (healthy) plex
[chuck@lizum docker.2007]$ docker exec -it plex bash
root@dockerplex:/# cat /proc/1/cgroup | grep -i docker
13:perf_event:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
12:net_cls,net_prio:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
11:cpu,cpuacct:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
9:memory:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
8:hugetlb:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
7:cpuset:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
6:rdma:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
5:devices:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
4:pids:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
3:freezer:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
2:blkio:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
1:name=systemd:/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
0::/docker/e994fcd63a2fc73e04e86b58c9ca85d77fcc19b572f2952f8332cba542be1846
root@dockerplex:/# find /config -name Preferences.xml -print
/config/Library/Application Support/Plex Media Server/Preferences.xml
root@dockerplex:/#
here my log, note I was using the @ https://raw.githubusercontent.com/ChuckPa/PlexDBRepair/chuckpa/improve-restore-logic/DBRepair.sh because I didn’t read this thread until later
2022-12-14 21.10.28 - ============================================================
2022-12-14 21.10.28 - Session start: Host is Debian GNU/Linux 11 (bullseye)
2022-12-14 21.12.18 - Check - Check com.plexapp.plugins.library.db - PASS
2022-12-14 21.15.50 - Check - Check com.plexapp.plugins.library.blobs.db - PASS
2022-12-14 21.15.50 - Check - PASS
2022-12-14 21.32.44 - Repair - Export databases - PASS
2022-12-14 21.40.27 - Repair - Import - PASS
2022-12-14 21.42.45 - Repair - Verify main database - PASS (Size: 2084MB/1860MB).
2022-12-14 21.42.53 - Repair - Verify blobs database - PASS (Size: 4683MB/4829MB).
2022-12-14 21.42.53 - Repair - Move files - PASS
2022-12-14 21.42.53 - Repair - PASS
2022-12-14 21.43.20 - Reindex - MakeBackup com.plexapp.plugins.library.db - PASS
2022-12-14 21.43.25 - Reindex - MakeBackup com.plexapp.plugins.library.blobs.db - PASS
2022-12-14 21.43.25 - Reindex - MakeBackup - PASS
2022-12-14 21.46.29 - Reindex - Reindex: com.plexapp.plugins.library.db - PASS
2022-12-14 21.46.51 - Reindex - Reindex: com.plexapp.plugins.library.blobs.db - PASS
2022-12-14 21.46.51 - Reindex - PASS
==================================================================================
Not understandng.
I think you’re looking at my former development branch.
You’ll now find v0.6.0 is released.
Just saw this.
I see this as two ways to go and wasn’t sure which is the best way.
1,2,3 were intended for when you want to do the basics,
4 is the next level of severity where you rebuild the db
5 is the next after rebuild where you resort to using one of your backups.
6 sits by itself
7 is the quintessential “OH NO – not that”
8, 9 are self explanatory
I’m willing to change the order, I wasn’t sure which is best for everyone.
I’m also considering changing “Repair” to “Rebuild” because “Rebuild” more accurately describes what it does. It “repairs” by “rebuilding” with all bad records having been omitted by SQLite during the export process.
1 Like
@ChuckPa pure curiosity on my side why does the blobs db increase (albeit by a small % amount) with this procedure ?
Yes, that’s been my observation as well.
While I don’t know why , we have noticed performance is significantly improved.
The only ‘wild guess’ I can venture is ‘page boundary alignments’ (white/null space is injected to make subsequent data begin on alignment boundaries).
One of the biggest improvements here is the complete folding of the WAL and SHM files back into the DB’s where they belong thus ending whatever problems were festering.
1 Like
Yeah at the time I was looking at the git, master had not been updated recently, so I was using that newer branch.
Then I saw the split thread after.
lol@ChuckPa a question when you have a moment.
Within GitHub - ChuckPa/PlexDBRepair: Database repair utility for Plex Media Server databases and the Scripting Support section you mention Another use of this feature is to automate Plex Database maintenance and you reference the example DBRepair.sh 1 4 3 9 which is the Check, Repair, Reindex and Exit.
What is your thinking on how often it should be included in normal maintenance ? Weekly, monthly, yearly ? Was considering every few months myself based on the amount of new content I add to my server. I want to incorporate this into my own plex maintenance scripts.
I run this monthly because I add about 50 new episodes a month.
Granted, 50 episodes is trivial, monthly also covers those times when I rip the entire box-set of a series and add 100+ episodes for one show.
There was a suggestion to change the menu order.
I’ve been thinking about that.
How about “A” - Automatic ? (“a” or “A” will be accepted)
Also, I’ll start changing “Repair” to “Repair/Rebuild” because this is more of a Rebuild than fixing data in the actual records (which PMS does)
