Searches not working (but scanner works fine; content DOES exist in library)

Server Version#: 1.41.3.9314

I’ve just discovered that searches of my server are not working at all.

All content still exists, and it’s manually accessible - via selecting from Recommended, Recently Added, the alphabetical list in Library, referencing within Collections, etc. etc. etc.

But, searches don’t result in any matches for titles from my server at all. Yes, I have my server selected in “Sources to Search”, and all libraries (Movies, TV Shows, etc.) are set to “Include in Home Screen and global search” (Settings → Manage: Libraries → select the library → Edit Library → Advanced)

Searches of other Plex servers which are accessible to me, work fine - so the issue appears to be limited to my server. I believe this is a fairly new development, but don’t know of any changes which would have caused it.

I’ve gone down the rabbit hole of several investigations, including the details indicated on forum posts such as https://www.reddit.com/r/PleX/comments/12b5szt/search_not_finding_any_local_media/

…but nothing seems to help. Toggling visibility, re-scanning library files, restarting the server, restarting the host, etc. - none seems to have any effect.

Again, the server is working just fine - the titles appear in the various lists, playback works flawlessly, etc. It’s just the search for titles (which I can see “right there”), doesn’t match anything.

I then went ahead and pursued the “corrupted database” route, and followed the instructions on https://support.plex.tv/articles/repair-a-corrupted-database/. The Plex SQLite execution of a PRAGMA integrity_check; did result in several issues being reported: Perhaps a few dozen “On tree page {foo}, Rowid {bar} out of order”; “row {foo} missing from index index_media_parts_on_deleted_at” indications. I then did a VACUUM; then a REINDEX; and reduced the size of the com.plexapp.plugins.library.db file by a few MB. But, a subsequent recovery effort failed: I can generate a recovery file, and then move the original file aside, but when trying to read back the recovered version, I get thousands of “Runtime error near line {foo}: UNIQUE constraint failed: activities.id (19)” indications - but even if not, trying to startup the Plex Server again, crashes hard.

So … maybe my database is corrupt? But again: Restoring a prior db version (before the SQLite manipulations) works just fine, and allows for visually selecting a title for flawless playback. It’s only searches which are non-functional.

Any insights? Yes, I guess I could just wipe things out entirely, and start over - but I’d rather not lose my collections, ratings, custom artwork selections, etc. - which it’s my understanding would happen, if I start fresh (uh, correct?).

Continue with this: GitHub - ChuckPa/PlexDBRepair: Database repair utility for Plex Media Server databases

OK, found and tried to use ChuckPa’s “PlexDBRepair” (= GitHub - ChuckPa/PlexDBRepair: Database repair utility for Plex Media Server databases). It took some work to figure out details for macOS, but I finally got it to run.

However, perhaps things are worse than I thought…

First off, it appears that the script is not able to determine the PID of the running PMS (./DBRepair.sh: line 1538: pidof: command not found ). No worries; I’m quitting the server manually, before I begin. I can try to reach out to ChuckPa and debug this aspect, later…

But, other commands similarly result in odd failures (e.g. ./DBRepair.sh: line 969: [: -lt: unary operator expected, stat: illegal option -- c, ./DBRepair.sh: line 332: [: -eq: unary operator expected, etc. etc.) Does the script perhaps not work with macOS 15.2?

Trying other efforts repeats several of the above (so, I’m not sure I can trust the functionality of the tool at all), but an “auto” execution provides several other errors, such as:

  • Databases are damaged. Vacuum operation not available. Please repair or replace first.
  • ERROR: Cannot set permissions on new databases. Error 1
    Please exit tool, keeping temp files, seek assistance.
    Use files: ./dbtmp/*-BACKUP-2025-01-13_23.04.34

I’m executing as root, so why wouldn’t it be able to set the permissions on the new databases?

(sigh). OK, running “check” seems to give a clean bill of health (Check complete. PMS main database is OK. and Check complete. PMS blobs database is OK.). Then, “vacuum” encounters several of those stat syntax issues, but winds up with Vacuuming blobs database successful (Size: MB/MB).. "

But finally, a “repair” command results in several similar script execution problems (line 1538 = pidof, line 969 = bad operator, line 332 = unary operator expected). But in addition, it gives that same set of “ERROR” details as above. No clue why it “cannot set permissions”, but should this really be resulting in catastrophic errors?

I give up.

Do I just wipe out the entire ./Databases area, and re-create all server details from scratch? If I remember correctly, this would entail RE-selecting all libraries, RE-configuring everything, etc. - correct? Do I at least get to keep my users, preferences, etc. - or am I really going the full nuke-and-pave route?

Before you do that, try to restore one of your database backups and then repair that one instead.
https://support.plex.tv/articles/202485658-restore-a-database-backed-up-via-scheduled-tasks/

That way you may not end up with a total loss of data.

Awesome; thanks, OttoKerner!

(I was actually replying with my discovery and use of PlexDBRepair, while you were posting that suggestion for me)

I did first move everything aside, as I wanted to see how things worked when building a new database. It went … fine, and setting up “new” libraries seemed to have resulted in all content being scanned as needed. But then I realized that in doing so, I lose all my carefully-curated Collections, lots of custom artwork selections, etc. So, that wasn’t an ideal approach.

So, I then quit PMS again, found the backup db files, and found what appeared to be an appropriate one from a few week back (it looks like such backups are pursued every 3 days, but I wanted to ensure I went beyond the corruption). Renaming & restarting seems to have brought back everything I need - and most importantly: Searches now once again work!

Still curious what lead to the issues, and how to avoid - but I’m so thankful to have what was ultimately a very-easy, very-quick solution. Thanks again, OttoKerner!

1 Like

Don’t forget to repair this version of the DB.
It is very possible that the damage is already lurking inside the restored version, although it’s not yet as severe. A successful repair ensures the health of your DB going forward.

1 Like

Most common issues are shutting down the computer or killing the plex process before it has a chance to nicely stop.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.