I’ll do another shutdown as soon as that one user is done with his show…
If you like to live dangerously, you can actually restart PMS while people are playing shows. (Probably not Live TV though.)
I’m not encouraging such behavior, but as long as the client’s buffer doesn’t fully drain, it works fine!
1 Like
Alright, a shutdown of PMS removed the WAL file, like Volts said. A restart created the WAL file again, but this time it’s only 1.4MB, which is how I remember it. Still wondering what could have made it grow to 2GB the last time around.
1 Like
I’m not particularly surprised when a -wal file is about the same size as a database itself.
All transactions are written there first, and any change that touches a significant number of database pages may require a large amount of space in the -wal file.
After transactions are committed back to the main .db file, the space within the -wal file can be re-used. It’s faster for SQLite to keep the file around with that empty space available, instead of de-allocating it and needing to re-allocate it again later.
1 Like
That’s good to know. Maybe I haven’t paid enough attention to it while PMS was actually running.
Thank you, guys!
Just to add a comment: DON’T MANUALLY DELETE .db-wal FILES! They’re normal and part of the database.
SQLite will remove them when -
- All data has been integrated into the primary
.dbfile. - The file has been closed cleanly.
The presence of a .db-wal file means that one of those two things hasn’t happened. Deleting a .db-wal file can mean loss of recent data changes.
A final observation:
The WAL file stays tiny until you run a DB optimization from within PMS. Once that’s done, the WAL file increases to a slightly larger size than the database.
VBB…
Feel like doing some BAT file writing? ( a ‘quick and dirty’ if you’re up to it )
Sure thing.
To all following here – Especially Windows users
As requested, I’ve crafted an equivalent of PlexDBRepair.sh for Windows.
It is still in development; It doesn’t have all the fancy detection, etc which PlexDBRepair.sh does.
It doesn’t have a menu system. In lieu of a menu , I’ve provided a basic tool which will do everything you need automatically.
There is only one thing for you to do.
- At the top of the BAT file, you will see where variable
PlexDatais set to the default databases location. IF you are using a different location then EDIT the variable setting to reflect this location
What this tool does:
-
Ensures Plex Media Server is not running
-
Performs the following steps
– Export Main DB and Blobs DB ; aborting if errors
– Rebuild Main DB and Blobs DB into perfect order
– Generates new Indexes for PMS searches so PMS doesn’t have to.
– Moves the original databases to subdirectorydbtmpwith a DateTime stamp to allow for recovery at any future point in time.
If you want to use this, I advise
- Stop PMS
- Make a backup of your databases (worst case scenarios)
- Edit the PlexData location if you installed to a non-default location
- Run the bat script
- Watch as it performs each step (Be patient with it… I will not ‘hang’)
- All progress and results are written to console and “PlexDBRepair.log”
This is what you see:
If interested, please let me know and I’ll post here or send via PM as requested.
Regarding “Support Doc for Database Cache Size” (this topic) –
I can say only this at this time.
- Test case created with 129,221 episodes ; media on a Synology DS418j (ARMv8 1GB)
- Server running on Win10 VM in VMWare Workstation on NUC8-i7-HVK
- Performed a search for
Star Trek. - Before I hit the “T” (“Trek”), I had everything star trek presented in the search results.
Your results will vary based on processor, RAM in the machine, and DB size
9 Likes
1 Like
Chuck, this is the same file you and I tested, right? Will you put it on your GitHub eventually and maintain it, like the other ones?
Thanks again for writing the script for us sorry Windows users 
…and thanks to @Volts for helping out!
Thanks. On my system increasing Database Cache Size (MB) has had zero noticeable (good or bad) effect on my system. I testing 128 up to 1024 (with various other sizes in between). Anyhow, for now I’ve returned my system to the default 40 and will keep an eye on the forum if recommendations from plex come in the future.
As for the 1 - 4 - 3 - check - repair - reindex this has shown significant improvement. Everyone should consider doing this at least a couple of times a year 
This is the same file you tested.
Yes it will go on GitHub and be maintained.
Before I release it on github, it needs:
- Function calls working as expected
- Menus
- More functions (DB import)
- Plex installation directory detection (if I can manage it)
here’s a live run (just now) . I added some 800 Movies.
Volume Serial Number is D0F2-0B8D
Directory of C:\Users\Chuck\AppData\Local\Plex Media Server\Plug-in Support\Databases
12/18/2022 02:25 PM <DIR> .
12/18/2022 02:25 PM <DIR> ..
12/17/2022 06:51 PM 1,036,288 com.plexapp.plugins.library.blobs.db
12/18/2022 02:02 AM 1,036,288 com.plexapp.plugins.library.blobs.db-2022-12-18
12/18/2022 02:25 PM 359,706,624 com.plexapp.plugins.library.db
12/18/2022 02:02 AM 311,504,896 com.plexapp.plugins.library.db-2022-12-18
12/17/2022 06:48 PM <DIR> dbtmp
12/17/2022 06:48 PM 5,294 PlexDBRepair.log
5 File(s) 673,294,846 bytes
1 Dir(s) 28,766,334,976 bytes free
C:\Users\Chuck\AppData\Local\Plex Media Server\Plug-in Support\Databases>g:DBRepair-WinDev.bat
14:26:11.85 -- ====== Session begins. (Sun 12/18/2022) ======
14:26:12.26 -- Exporting Main DB
14:27:30.02 -- Exporting Blobs DB
14:30:32.93 -- Exporting Complete.
14:30:32.94 -- Creating Main DB
14:30:57.94 -- Verifying Main DB
14:31:10.50 -- Main DB verification check is: ok
14:31:10.50 -- Main DB verification successful.
14:31:10.51 -- Creating Blobs DB
14:31:10.64 -- Verifying Blobs DB
14:31:10.72 -- Blobs DB verification check is: ok
14:31:10.72 -- Blobs DB verification successful.
14:31:10.72 -- Import and verification complete.
14:31:10.73 -- Reindexing Main DB
14:31:20.18 -- Reindexing Blobs DB
14:31:20.29 -- Reindexing complete.
14:31:20.29 -- Moving current DBs to DBTMP and making new databases active
1 file(s) moved.
1 file(s) moved.
1 file(s) moved.
1 file(s) moved.
14:31:20.31 -- Database repair/rebuild/reindex completed.
14:31:20.31 -- ====== Session completed. ======
C:\Users\Chuck\AppData\Local\Plex Media Server\Plug-in Support\Databases>dir
Volume in drive C has no label.
Volume Serial Number is D0F2-0B8D
Directory of C:\Users\Chuck\AppData\Local\Plex Media Server\Plug-in Support\Databases
12/18/2022 02:31 PM <DIR> .
12/18/2022 02:31 PM <DIR> ..
12/18/2022 02:31 PM 1,036,288 com.plexapp.plugins.library.blobs.db
12/18/2022 02:02 AM 1,036,288 com.plexapp.plugins.library.blobs.db-2022-12-18
12/18/2022 02:31 PM 350,883,840 com.plexapp.plugins.library.db
12/18/2022 02:02 AM 311,504,896 com.plexapp.plugins.library.db-2022-12-18
12/18/2022 02:31 PM <DIR> dbtmp
12/18/2022 02:31 PM 6,178 PlexDBRepair.log
5 File(s) 664,472,946 bytes
1 Dir(s) 28,115,718,144 bytes free
C:\Users\Chuck\AppData\Local\Plex Media Server\Plug-in Support\Databases>
2 Likes
This process is the default for the Windows version below.
One shot ; just do it
I’m on linux. Windows is evil with built in microsoft spyware everywhere 
1 Like
don’t get me started … lol
1 Like
Just used it on my Windows system a few minutes ago, I have a massive library. Didn’t bugger it up by initial results and seems to be immensely faster on search. I imagine this will help with my slow scan times too and probably some of the other routine processes. Thanks!
Win10 (13600k, 64GB RAM)
15k music
66k audiobooks
105k TV
29.5k movies
I just ran this utility using 1-4-3 and now when I restart my container in UnRAID I get the following error in the logs.
Starting Plex Media Server. . . (you can ignore the libusb_init error)
Error: Unable to set up server: sqlite3_statement_backend::loadOne: attempt to write a readonly database (N4soci10soci_errorE)
Any help would be appreciated to get my server back up and running.
Go into the file system.
Look to make certain the owner (UID/GID) of the file and permissions are correct.
Unraid might be doing something different than I expect ( I have no way of testing Unraid )
