I saw a push message on my phone that said something about my Plex db being corrupted. However, when I logged on to see what was happening, I cannot find any trace of the message and the server seems to be fine.
I would much rather deal with an issue before it’s a “real” problem - not sure what (if anything) to do from here.
Best try to repair your database immediately.
That db utility for Windows was almost too easy - I don’t know if it actually corrected/fixed anything, but it completed quickly and got me right back online.
ChuckPa has done a LOT of work to make the process easy for non-technical users. Often times database corruption occurs long before Plex stops functioning, Plex can handle minor database damage, but it starts a timer until the database crashes completely. In this case you were able to repair and should be good moving forward.
If you used the .bat file, run from a c:\ prompt. Don’t double click. You’ll see the results in the window.
It also leaves a log file in the folder with the database files.
I used the PowerShell method. I got messages in the PowerShell window about what the tool was doing, but nothing that indicated specific repairs. I have also searched the Plex drive and system drive for ‘dbrepair.log’ but haven’t been able to locate it.
Obviously, all that really matters is that it is working and the tool most likely cleaned up an issue, but it would be nice to know what it found too.
Wasn’t sure which method you used. If the databases had problems, then it would have been mentioned on screen.
The log file, PlexDBRepair.log, is in the same directory as the Plex database files, %LOCALAPPDATA%\Plex Media Server\Plug-in Support\Databases. It has basically the same info that was in the PowerShell window. The entries are date/time stamped so you can look up prior runs.
Example:
2025-01-20 10.46.16 -- ============================================================
2025-01-20 10.46.16 -- Session start: Host is Windows 10 (Build 19045)
2025-01-20 10.46.19 -- Stop - START
2025-01-20 10.46.21 -- Auto - START
2025-01-20 10.46.22 -- Repair - Export databases - PASS
2025-01-20 10.46.24 -- Repair - Import - PASS
2025-01-20 10.46.24 -- Repair - Verify main database - PASS
2025-01-20 10.46.24 -- Repair - Verify blobs database - PASS
2025-01-20 10.46.24 -- Reindexing Main DB
2025-01-20 10.46.24 -- Reindexing Blobs DB
2025-01-20 10.46.25 -- Reindexing complete.
2025-01-20 10.46.25 -- Moving current DBs to DBTMP and making new databases active
2025-01-20 10.46.25 -- Auto - PASS
2025-01-20 10.46.33 -- Prune - START
2025-01-20 10.46.33 -- Prune - PASS (no files found to prune)
2025-01-20 10.46.37 -- Exit - Retain temp files.
2025-01-20 10.46.37 -- Session end. 01/20/2025 10:46:37
2025-01-20 10.46.37 -- ============================================================
OK - thanks for that!
So that dir is empty - I guess when I let it clean up the temp files after the run it also cleaned up the log.
Your example output is almost exactly what I saw in the PS window, so I suppose it didn’t find anything too bad.
I’m not sure about the Windows version (I believe Chuck made it as similar as the shell script as possible), but there should be 2 exit options. One that will retain the temp files and the other that will give the option to delete them. It is possible you did the latter and deleted them without realizing.
I think if there was an issue it could not repair, it would have given you that message in the output. You could also run the ‘check’ option which will verify the integrity of the repaired DB. If that comes back OK, you should def be good to go.
-Shark2k
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
