PM’d.
Another issue - I thought I’d try restoring a DB backup -
No idea where those dates are coming from in DB Repair - it’s not Blobs backups, they have identical dates and very similar times.
ALL:
There will be another release before we go to Public.
I fixed a few bugs today which I want to confirm are good.
I also want to address the issues brought up today.
I might have a solution to DBRepair opening and immediately closing.
(not administrator problem) by changing what windows calls the ‘manifest’.
I’ll check that out.
Also will be addressing the UI requests.
Another issue was raised today which needs investigating.
I see the problem and want to track it out. It’s simple but detail rich.
ON good news,
I’d like to end the day by telling you that there was a big improvement in performance by fixing the bug presented by @Kgtree .
Large databases are now as much as 2-3x faster than previous.
( No more sneaking out to the 'fridge for a cold one while it runs 
)
Heavy shakedown testing is going very very well.
These “nits” and the ever-looming Wiki remain.
Moving forward, the application should display a dynamically generated excuse every time it is run. 
Why should DBRepair generate a dynamic excuse because you can’t control your media collection habit ?
haha. I mean generating excuses for grabbing a cold one from the fridge.
@ChuckPa I’m not sure if I found an issue here. Could you please have a look:
(Summary AI generated)
Title: Butler DB backup silently stopped (Plex integrity check fails on FTS4 index fts4_metadata_titles_icu), but DBRepair check reports “OK”
Environment
- Plex Media Server 1.43.5.11029 (Windows 10, build 19045, x64), very large library
- Main DB ~6.3 GB, blobs DB ~9.5 GB
- Backup target: separate SSD with 400 GB free, path exists and is writable
- “Backup database every 3 days” enabled, Butler window 01:00–08:00
Problem
Scheduled database backups stopped working without any visible error. The last backup in the target folder is com.plexapp.plugins.library.db-2026-08-23. The next one should have followed within three days, but none was ever created. I updated to 1.43.4.10903 on Aug 24 and to 1.43.5.11029 on Oct 7, and no backup has been created since 23 Aug. I can’t prove the update caused it.
Analysis
The normal log did not cover the nightly Butler window (debug logging rolls over a 10 MB file every 15–30 minutes). So I triggered the task manually (POST /butler/BackupDatabase) and read the log:
[Database backup/com.plexapp.plugins.library.db] Activity: registered new activity ... "Database"
... (minutes later)
ERROR - [Database backup/com.plexapp.plugins.library.db] The database failed its integrity check, not backing up.
DEBUG - ... Push: Sending notification tv.plex.notification.admin.database.corrupted to 1 users.
WARN - Butler: wasn't able to back up your database
This is not a DB-lock or disk problem. I had stopped the other writers (no “busy database” messages during the run), and the free space is plentiful.
I then ran Plex’s own SQLite with Plex stopped:
"C:\Program Files\Plex\Plex Media Server\Plex SQLite.exe" com.plexapp.plugins.library.db "PRAGMA integrity_check;"
Result (about 3–5 minutes):
unable to validate the inverted index for FTS4 table main.fts4_metadata_titles_icu: SQL logic error
The discrepancy
I ran DBRepair (current native Windows version, option 3 check) right before and after. It reports:
Checking the PMS databases...
Main DB is OK.
Blobs DB is OK.
So the Butler integrity check (and a manual PRAGMA integrity_check with Plex SQLite) fails because of the FTS4 title index. DBRepair’s check passes. Because of that, Plex treats the DB as corrupt and refuses to back it up, while DBRepair tells the user everything is fine.
After using the reindex feature of DBRepair the same error message is shown.
Thanks to @Kgtree , I corrected that today. I wasn’t handling Unicode and special characters exactly as plex does.
I have that fixed in 00.99.13 which I have here now.
It is 2am here and about to sleep. When I wake tomorrow, I will post 00.99.13 for everyone to test.
If this doesn’t fix it for you, Please send me the text logs and copy/paste of the console text? The screenshots you provided are very small and will not zoom in my browser.
When did you upgrade to PMS 1.43.4 ? Was it about the time the backups stopped ?
Thanks Chuck, please forget about the screenshot as the text is already in the message above 
The update to 1.43.4 happened around the time the backups stopped, yes.
I’m looking forward to test the new version.
But now have a good night
ALL:
Being this close to release means I can no longer instantly respond to change requests.
I must ask, from this point forward, you use my established GitHub “Issues” for feature changes / new feature requests.
This will allow me to properly prioritize features, changes, and bug requests moving forward.
As always, if an URGENT BUG, please report it here AND on GitHub.
Thanks,
Chuck
ver 00.99.13 Testing
Release Notes:
-
General
- Cleaned up the output to compact height and centering.
-
PMS version
- DBRepair would sometimes pick the older version ID when using --databases option. Fixed. No issues under normal operation.
-
Invalid ICU fail
- Would stop transferring data when bad ICU sequences found.
Fixed. Now mirrors what PMS does.
- Would stop transferring data when bad ICU sequences found.
-
Dropped rows
-
When transferring data to the new DB, if a row failed, DBRepair would
silently drop the remainder of the block. This is corrected.Now only the offending row which could not be copied is skipped.
Report at end of Repair shows if/when rows are skipped due to errors
and which tables they occurred in.
-
-
Windows
- Clicking the DBRepair icon now requires administrator
It prompts (Windows UAC) for privilege escalation.
- Clicking the DBRepair icon now requires administrator
For your consideration:
Please don’t hesitate to force a ‘repair’ to confirm everything works correctly for you
Did DBRepair auto. Saw it stop PMS, Did db checks, all ok, Restarted PMS
Fedora 44 x86_64
Ran it on auto QuTS Hero latest non-beta everything…
Reported both DBs as okay, but then proceeded to rebuild both DBs, which checked okay after the rebuild.
Is this intentional behaviour?
Yes. that’s how it should be.
Did PMS run ok or fail?
Fine both before and after.
All looking good for me testing 00.99.13 on macOS Sequoia 15.8.1 with ARM64, thanks @ChuckPa
Stopping PMS. (60 second max delay)
Stopped PMS.
Checking the PMS databases...
Database itself is fine however 1 tables/triggers/indexes are missing. Repair required.
Main DB is damaged.
Blobs DB is OK.
--- Processing Main DB ---
Rebuilding Main DB
Transferring schema.
Building FTS tables.
Generating triggers.
Transferring data records.
Generating indexes.
Warning: New index found (index_title_sort_naturalsort) in Main DB. Please inform '@ChuckPa'.
Warning: New index found (index_taggings_on_created_at) in Main DB. Please inform '@ChuckPa'.
1 index missing from source, recreated from stored schema.
Populating FTS tables.
Checking Main DB after rebuild.
Main DB rebuild and verification complete.
--- Processing Blobs DB ---
Rebuilding Blobs DB
Transferring schema.
Building FTS tables.
Generating triggers.
Transferring data records.
Generating indexes.
Populating FTS tables.
Checking Blobs DB after rebuild.
Blobs DB rebuild and verification complete.
Making DB(s) active
Swap complete. Live databases updated.
Automatic repair successful.
Starting PMS.
Started PMS.
@ChuckPa Plex version 1.43.5.11029 on linux
do you still have a copy of the databases before running DBRepair ?
If so, could you zip them up for me and PM me a link to where I can download them from ?
Something isn’t right (obviously) and I’d like to see what happened.
Also , may I have the full DBRepair log file ?
@ChuckPa only if it backs up the db somewhere do I have a copy. I should of backed up beforehand and that’s my bad. As far as the full log, where would that be at? I’m running inside the hotio container
You can PM me the DBrepair.log file.
Backups & intermediate files are kept for every database-modifying step during the session (how History & Revert work)., Once the session ends, the history and temp files are removed to avoid collecting junk
