I have minor update v1.0.8 in a test branch (require-root) and would appreciate kicking the tires to make sure I didn’t break anything.
The purpose of this little change is to ensure the tool isn’t invoked as a non-privileged UID (Primarily on QNAP and Synology NAS systems) where it’s possible for a user to create a DB which cannot be accessed by PMS once put back into operational position.
(Shared folder permissions allowed them to run the tool but lack of Linux permissions prevented the correct UID/GID & mode from being assigned when done)
It’s better to be safe upfront than deal with the mess later.
Please inspect my error messaging (lines 940-ish) and let me know if they make sense.
Also, please let me know if you can bypass the root-requirement (you shouldn’t be able to)
Version 1.08 works fine on my DS918+/DSM 7.1.1 Update 5, PMS 1.32.2.7100.
It would not run under my normal username. I had to be root (sudo bash).
# ./DBRepair stop auto start quit executed correctly and left the temporary files. # ./DBRepair stop auto start exit executed correctly and removed the temporary files.
Thanks for the tool. It worked fine and I definitely see a big speed increase. My music library with almost 200k songs was getting a bit slow to search in. Now it’s instant!
A question though. This is more for my curiosity. The main DB did go down a bit in size, as expected. However, the blobs DB actually increased slightly in size. Why’s that?
I shouldn’t be concerned that something went wrong right? This was on Windows and the logs said everything was fine.
I believe I’m in need of using the PlexDBRepair on my Windows Server 2016 Plex installation. It’s running quite sluggishly and no other optimization seems to be working to help speed things up enough.
This is a long thread to read through so I’m hoping someone can give me the steps as to how to go about running PlexDBPlex safely on Windows and making sure I have a backup and restore option in place.
The %ERRORLEVEL% did catch the issue and stopped the batch.
I’ll make the change to the BAT file and see how it goes.
Yes, I thought Plex was 64-bit too. Not sure why the Plex SQLite got installed into the “Program Files (x86)” folder if 64-bit. It’s been so long since I installed Plex I don’t recall if there was an option to specify the SQLite folder, nor do I think I would have changed it. No biggie, if the simple BAT file change does the trick.
I’ll need to try running the dbrepair later; active streams are picking up for the day.
So, now I probably should figure out what version I’m running. Not quite sure how to do that, but it looks like I might have installed the 32-bit version based on the directory structure.
Anyone know how to determine what bit version I am running?
Never mind, found out it is the 32-bit:
Has PlexDBRepair been run against the 32-bit version?
Okay, I decided to go ahead and run the PlexDBRepair against the 32-bit version and it appears to have been successful. Was pretty quick too at about 10 minutes on a fairly large set of media.
I just had to make the BAT file change %PROGRAMFILES(x86)%.