That’s asking a lot for @ChuckPa to do (maintain multiple scripts) because QNAP crippled the Python installation.
There’s no way to write a universal script.
Nobody is asking ChuckPa to maintain two sets of scripts. Some of use are just mentioning our situation and our preferences.
The python discussion started because PowerShell users felt left behind or left out so they expressed their preferences and asked if the script could be written in Python as a more “universal” option. We are finding it’s not as universal as assumed.
Windows 10/11 can run shell scripts (a checkbox to enable “linux subsystem” if I remember correctly) though I don’t know to what extent it might be “crippled”, as you put it, for running DBRepair.sh. So if QNAP not being able to run python is a reason not to support dbrepair for QNAP - as you seem to indicate here - then Windows not running .sh is a reason not to support windows.
I don’t think being dismissive of supporting device\OS on those grounds is a productive approach for either platform.
These are just points of discussion for feedback about DBRepair - an optional helpful maintenance tool for Plex. ChuckPa can choose whatever works best for them and I’ll happily support it. ![]()
I use Linux, so the Bash script works for me, but python is a better way to maintain this script.
IMO, of course ![]()
Folks:
- Python is, at present, an experiment.
- Linux Python is the standard – All good
- Synology Python, while not 100% current version, works without issue
- QNAP Python default is 2.7 which is not usable.
- QNAP Python 3 requires a shell wrapper (Shython)
[~] # export PATH=/usr/local/Python3/bin:${PATH}
[~] # export LD_LIBRARY_PATH=/usr/local/Python3/lib:${LD_LIBRARY_PATH}
[~] # python3
Python 3.7.5 (default, Dec 25 2025, 02:23:02)
[GCC 5.3.1 20160113] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> X="123"
>>> B=f"Hi, {X}"
>>> print(B)
Hi, 123
>>>
[~] # /usr/bin/env python3
Python 3.7.5 (default, Dec 25 2025, 02:23:02)
[GCC 5.3.1 20160113] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
[~] # ./p3.py
Traceback (most recent call last):
File "./p3.py", line 19, in <module>
from pathlib import Path
ModuleNotFoundError: No module named 'pathlib'
[~] #
I have a Python 3.12 option in App Center on QTS 5.2 if that makes a difference for the default 2.7 aspect on QNAP? Does that work better than the Shython wrapper or still lacking?
Edit: There’s also a QPython 3.9.5 package available via MyQnap repository as well if that works out. I don’t know enough about the environment requirements to know myself which would be “better” or pose same annoyances anyways, sorry.
No Python 2. Python 3.5 or better (current known minimum)
Try this in your python:
# Import major libraries
import datetime # Timestamp functions
import os # OS functions
import glob # Globbing (wildcard)
import subprocess # Need of shell
import shlex # Ensure string encapsulation safe for shell
# Types & Methods
from types import SimpleNamespace
from pathlib import Path
If that works, confirm f-strings
A="AAAAA"
B=f"Hi {A}"
print(B)
These two will confirm enough for HostConfig to run.
Given this is an experiment,
Windows users:
What are the values for the Windows (Using DSM 7 as a template) ?
## Synology (DSM 7)
if isDir("/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/Plex Media Server"):
h.PkgDir="/var/packages/PlexMediaServer/target"
h.PlexSQLite=h.PkgDir + "/Plex Sqlite"
h.LogTool = "logger"
h.AppSuppDir = "/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData"
SetPaths(f"{h.AppSuppDir}/Plex Media Server")
# We do have start/stop as root
h.HaveStartStop=True
h.StartCommand="/usr/syno/bin/synopkg start PlexMediaServer"
h.StopCommand="/usr/syno/bin/synopkg stop PlexMediaServer"
# We are done
h.HostType="Synology (DSM 7)"
return True
The PMS code is under “h.PkgDir”
The PMS instance (all your server internal data) is under “h.AppSuppDir”
Start & Stop commands are system dependent / obvious.
I recognize PMS can be installed on multiple drives (AppSuppDir).
Where is PMS and what’s the Top-Level directory template to find it
(( presuming "X:\…whatever-goes-here…\Plex Media Server ))
This will provide the necessary info as to whether this experment should continue.
If PMS cannot reliably be detected and configured in Windows,
I ask the question “Why do this?”
A simple test:
import platform
print (platform.system())
This is on Windows 11 25H2
Python 3.13.3 (tags/v3.13.3:6280bb5, Apr 8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime # Timestamp functions
>>> import os # OS functions
>>> import glob # Globbing (wildcard)
>>> import subprocess # Need of shell
>>> import shlex # Ensure string encapsulation safe for shell
>>>
>>> # Types & Methods
>>> from types import SimpleNamespace
>>> from pathlib import Path
>>> A="AAAAA"
>>> B=f"Hi {A}"
>>> print(B)
Hi AAAAA
Same system
>>> import platform
>>> print (platform.system())
Windows
>>>
Edit: Somehow I can’t type { and } in the terminal window - I’m probably missing something - but I can do it in the IDLE Shell.
OK, Ive installed Python 3.9.5 from the MyQNAP repo (thanks for pointing that out, @Insomnic_1) but have no clue what to do beyond that.
So, after a bit of googling this is what I did:
I have to run python with this command /opt/QPython39/bin/python3
I put the following into Chuck.py in /share/public
# Import major libraries
import datetime # Timestamp functions
import os # OS functions
import glob # Globbing (wildcard)
import subprocess # Need of shell
import shlex # Ensure string encapsulation safe for shell
# Types & Methods
from types import SimpleNamespace
from pathlib import Path
I SSH’d in as admin and ran /opt/QPython39/bin/python3 Chuck.py
There were no errors:
[/share/Public] # /opt/QPython39/bin/python3 Chuck.py
[/share/Public] #
I added the following to Chuck.py
A="AAAAA"
B=f"Hi {A}"
print(B)
and ran it again…
[/share/Public] # !!
/opt/QPython39/bin/python3 Chuck.py
Hi AAAAA
[/share/Public] #
…hope this helps. I wrote everything I did above in case, in my ignorance, I did this wrong (but it looks likes success to me).
[edited for clarifications]
You would likely start (once determining the platform is Windows), but identifying the local application support directory and then adding the Plex Media Server directory to it. This can be done with something similar to the following:
import os
localappdata = os.getenv('LOCALAPPDATA')
plexappdata = localappdata + '\\Plex Media Server'
plexdata will now be set to 'C:\\Users\\username\\AppData\\Local\\Plex Media Server'.
(The double backslashes are important in Windows; the first one escapes the second one.)
To determine binary locations, you could do something like:
import sys
# Are we 64-bit?
win64 = sys.maxsize > 2**32
if win64:
plexbin = 'C:\\Program Files\\Plex\\Plex Media Server'
else:
plexbin = 'C:\\Program Files (x86)\\Plex\\Plex Media Server'
plexsqlite3 = plexbin + '\\Plex SQLite.exe'
Putting it all together, you’d end up with something like:
import os
import sys
platform = sys.platform
if platform == 'win32':
localappdata = os.getenv('LOCALAPPDATA')
plexappdata = localappdata + '\\Plex Media Server'
plexappdata
# Are we 64-bit?
win64 = sys.maxsize > 2**32
if win64:
plexbin = 'C:\\Program Files\\Plex\\Plex Media Server'
else:
plexbin = 'C:\\Program Files (x86)\\Plex\\Plex Media Server'
plexsqlite3 = plexbin + '\\Plex SQLite.exe'
plexsqlite3
else:
print('Some other platform')
Of course, testing that those paths exist is likely in order. Because, as you’ve stated, it is possible to change the default application data location. But that is something advanced users do and requires modifying the Windows registry. Kind of like asking a very novice Linux user to change the app data directory by creating a systemd override.
My Plex data folder is in another location.
Can the Windows Registry be queried by Python? If so, you can get all the values you need from HKEY_CURRENT_USER\Software\Plex, Inc.\Plex Media Server
You could, but you’d need to use a module which isn’t included in the base package (winreg). I considered creating an example which used that, but then considered that the vast majority of users choose to use the default location (as changing it requires modifying the registry anyway).
This is exactly what I wanted to avoid.
At this point, I will look at creating compiled binaries in the same manner that PMS is built. It’s one source with “Conditional Compilation” dependent on the binary target.
This translates to having one more-complicated source to maintain than multiple flavors with all their ridiculous deficiencies.
I have some ideas for making this workable on Windows without external Python modules. It involves using the pathlib module (included with Python 3.5 and later) to find the PMS executables and database files (likely as a fallback to what I posted above, if the install and data are in non-standard locations).
It will likely only be a few lines of code, plus some error checking.
@ChuckPa previously I ran the script and it detected the fts indexes where damaged and fixed them, here is my previous post DBRepair development - #847 by dokuro.
Today I can the script again and it yet again detected damaged fts …
[2026-02-19 10.22.20] Checking FTS (Full-Text Search) indexes
[2026-02-19 10.22.20] FTS index 'fts4_metadata_titles' - DAMAGED
[2026-02-19 10.22.20] Error: Error: stepping, database disk image is malformed (11)
[2026-02-19 10.22.21] FTS index 'fts4_metadata_titles_icu' - DAMAGED
[2026-02-19 10.22.21] Error: Error: stepping, database disk image is malformed (11)
[2026-02-19 10.22.21] FTS index 'fts4_tag_titles' - DAMAGED
[2026-02-19 10.22.21] Error: Error: stepping, database disk image is malformed (11)
[2026-02-19 10.22.23] FTS index 'fts4_tag_titles_icu' - DAMAGED
[2026-02-19 10.22.23] Error: Error: stepping, database disk image is malformed (11)
[2026-02-19 10.22.23] FTS index 'fts4_metadata_titles' (blobs) - OK
[2026-02-19 10.22.23] FTS index 'fts4_metadata_titles_icu' (blobs) - OK
[2026-02-19 10.22.23] FTS index 'fts4_tag_titles' (blobs) - OK
[2026-02-19 10.22.23] FTS index 'fts4_tag_titles_icu' (blobs) - OK
[2026-02-19 10.22.23] FTS integrity check complete. One or more FTS indexes are DAMAGED.
[2026-02-19 10.22.23] Use 'reindex' command (option 6) or 'automatic' (option 2) to rebuild.
Is this an ongoing problem where the indexes continually need to be repaired ? BTW… running the tool again a second time today detected no damages so I guess it was just over time they become damaged again.
I suspect it’s an ongoing thing (for now at least)
Somewhere, PMS changed. That change is causing the indexes to break.
( I suspect a schema change is the cause and code wasn’t updated to address it)
I’m going to leave it in the code. as part of “Auto”, so it checks as part of your “stop auto start exit” normal sequence.
Perfect, thanks for the confirmation.
@ChuckPa , The indexes are fixed with:
6 - ‘reindex’ - Rebuild database indexes
DBRepair fixes the indexes, but I run DBRepair a little later, I get:
Checking FTS (Full-Text Search) indexes
FTS index ‘fts4_metadata_titles’ - DAMAGED
Error: Error: stepping, database disk image is malformed (11)
FTS index ‘fts4_metadata_titles_icu’ - OK
FTS index ‘fts4_tag_titles’ - DAMAGED
Error: Error: stepping, database disk image is malformed (11)
FTS index ‘fts4_tag_titles_icu’ - OK
FTS index ‘fts4_metadata_titles’ (blobs) - OK
FTS index ‘fts4_metadata_titles_icu’ (blobs) - OK
FTS index ‘fts4_tag_titles’ (blobs) - OK
FTS index ‘fts4_tag_titles_icu’ (blobs) - OK
FTS integrity check complete. One or more FTS indexes are DAMAGED.
Option 6 is a simple reindex. Given it’s ttalking about stepping,
did you also do the full repair (which also does the re-index) ?
Yes, did a full repair and DBRepair fixes it, but it “comes back”, (not immediately, in a few days) so not a DBRepair issue, not sure why it will need to be repaired again.