Having had a look at the sqlite3 docs a bit regarding how the integrity check of the FTS4 tables is being done in DBrepair.sh, I found this:
(See section 7.3)
That section outlines the means by which an integrity check is performed on a virtual table (e.g. the ‘fts4’ tables in the PMS DBs). The failure modes are described. The second one is:
- Using the FTS4 content option and failing to manually keep the content in sync with the FTS4 inverted indices.
I’m guessing that’s the failure mode being triggered. I assume that the database is reindexed occasionally as part of normal PMS background maintenance activities, but there are times when the metadata_items (from which fts4_metadata_titles is created) and fts4_metadata_titles become out of sync.
Any failure of the table integrity check returns a SQLITE_CORRUPT error, regardless of the failure mode (even if the database isn’t really corrupt).
This is mostly supposition, based on the docs (and how the fts4 virtual tables are created).
It’s interesting reading. I’d recommend reading the intro to section 7, plus the sections for the ‘integrity-check’ and ‘rebuild’ commands, for anyone interested.
For what it’s worth, here’s how the fts4_metadata_titles table is created in the PMS DB schema:
CREATE VIRTUAL TABLE fts4_metadata_titles USING fts4(content=‘metadata_items’, title, title_sort, original_title)
So, it’s populated from the title, title_sort, and original_title columns of the metadata_items table.
