Another vote for python.
And for checking code, I have found using Google Gemini in Pro Mode very helpful (just don’t blindly rely on what Gemini provides), it really does a great job with code checking (better than ChatGPT)
I do not use AI to write code. Never have – Never will.
The biggest problem with it is that it’s not perfect. It’s just a great big ruleset which is known to be incomplete.
I do use linters to double check my syntax but never semantics.
I’m the only one who knows what I’m trying to accomplish.
I will stop here before I offend anyone who things AI-written code is “Cat’s Pajamas”
4 Likes
Did I say to write code?
Didn’t I say don’t blindly rely on what Gemini provides.
Lint is old school (I used to use it). AI is a faster lint.
Ask Gemini to explain what I said.
Oh, what the hell, I will 
Answer: The speaker recommends Python for development and suggests using Google Gemini (specifically Pro Mode) for code verification, noting that it outperforms ChatGPT in this regard but requires human oversight.
The user is providing a testimonial based on personal experience, highlighting a shift in preference toward Google’s AI for technical tasks. They include a standard industry warning: AI tools can produce errors (“hallucinations”), so manual verification is mandatory.
You can have it fast or you can have it correct. Please choose one.
- I WILL write this by hand
- I HAVE a class structure already in mind
- I WILL create the Python version in the same manner as I did the original DBRepair (Start small and add as it’s vetted)
Questions:
-
Maintain & distribute two different packages?
-
Distribute as one package or two ?
2 Likes
Maintain and distribute one package, python would be my vote.
1 Like
ALL:
Very simple question - Is python available for Windows platforms?
If so, is it native or must it be installed ?
If DBRepair is to be distributed in Python, should installing python be a prerequisite ? ( regular Linux, Synology, and QNAP have it installed by default )
Yes, Python is available on Windows (and is fully-supported by Python’s developers). I do some dev work on Windows using Python which is why I suggested it.
Python may require a simple one-click installation on Windows (from the Windows Store). Once installed, it will be updated like any other Windows application. On Windows 11 (at least) if you attempt to run python from the command-line, and it’s not already installed, it will take you directly to the store listing for it where you can immediately install it. There’s nearly zero friction.
1 Like
We’re off …
I have a full schedule so this will take a bit but I’ll get there.
Function HostConfig() is the biggest amount of work.
4 Likes
Short update.
Couldn’t sleep.
Started working on the new HostConfig function which is central to DBRepair.
I’m 400+ lines into it with about 200 to go.
BSD will be an issue as will some of the containers .
They will require a completely new detection strategy
The new implementation is largely named like the old familiar DBRepair with some additions
- A new
Hostclass object for all host-specific (configuration) variables. - Still mostly procedural but restructured .
- Added new functions to clean up past evils (to make room for new evils)
When I think I’m ready, I’d like to present it here so we can test-drive HostConfig.
It should properly detect and report the specifics of the machine it’s invoked on.
5 Likes
About to hit the sack. Offline a few days.
Today’s progress 
[chuck@lizum python.547]$ ./d3.py
<class '__main__.HostClass'>
Invoking HostConfig
Found Linux Host
Host Configured: Ubuntu 24.04.3 LTS
Ubuntu 24.04.3 LTS
--- type Members ---
__module__ = __main__
__init__ = <function HostClass.__init__ at 0x774467a14220>
__dict__ = <attribute '__dict__' of 'HostClass' objects>
__weakref__ = <attribute '__weakref__' of 'HostClass' objects>
__doc__ = None
PkgDir = /usr/lib/plexmediaserver
PlexSQLite = /usr/lib/plexmediaserver/Plex SQLite
LogTool = logger
AppSuppDir = /var/lib/plexmediaserver/Library/Application Support
DBDir = /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases
CacheDir = /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/PhotoTranscoder
Pidfile = /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/plexmediaserver.pid
Logfile = /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases/DBRepair.log
TmpDir = /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/tmp
SysTmp = /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/tmp
HostType = Ubuntu 24.04.3 LTS
HaveStartStop = True
StartCommand = systemctl start plexmediaserver
StopCommand = systemctl stop plexmediaserver
[chuck@lizum python.548]$
Thi is the default. Overrides not tested. Other hosts not tested.
Small steps. I forgot a lot more than i realized
PS: HostConfig is fully written. It has everything the shell has with several improvements.
- BSD support is cleaner
- Variable HDD selection on Netgear and WD
- Checks paths really exist before accepting them.
HostConfig is 60 lines less than with sh/Bash. This includes how Python wants things formatted. Coming in at 401 lines
5 Likes
Dev update:
- QNAP will require ‘Shython’ wrapper
- Synology cannot be tested at this time.
If folks will be gentle, ( Linux and Docker containers - Only)
For those who know Python, I’d like to continue detection testing.
It’s of no help to say “Doesn’t work on XXXXXXX” without the necessary info about what doesn’t and why.
Thanks,
DBRepair-Py-Dev.zip (5.6 KB)
1 Like
QNAP as odd ball out again (no QNAP builds for latest beta\public or the new NFO preview build). 
Dang QNAP being all finicky.
I assume the native Python install from QNAP App Store is missing functionality needed for the script. 
Corrections here:
I will add to this as I find things.
Corrections:
Line 242: os.chdir(CurrDir)
Confirmed
@ChuckPa Looks like Python on QNAP is missing f strings, so sadly needs to use format() instead. (Like Python 2.7 does)
1 Like
Question. For Docker, I am guessing this would be run similar to the current DBRepair.sh, right? Meaning I would exec into the Docker container and then run the script, i.e., ./DBRepair.py (making sure it is executable of course).
If so, I am using the Linuxserver.io container and I tried running this from within the container and it fails with /usr/bin/env: ‘python3’: No such file or directory.
I did a quick Google search and found command -v program_name as a way to check that the executable is on your system. I ran command -v python3 in the Docker container, which came back with no output (so not installed). I also ran the same command on the host as verification and it returned /usr/bin/python3.
So not sure if I am doing something wrong (very possible when it comes to Linux) or it just means that Python is not included in the Linuxserver.io container (seems like the likely possibility).
My host is Debian 13 Trixie if that matters.
-Shark2k
DBRpair.py will be run using the same environment as DBRepair.sh
Regarding containers (Docker, LXC, or VM), it will be run from inside that namespace / environment.
If you want to test the actual detection within the container, you can modify the #! on line 1 to give it your actual python3 path
Here we are, running into trouble invoking python and seeing which vendors offer (or don’t offer) which libraries
There’re a lot more Python funtions which will be needed as the functions within DBRepair are ported.
Folks want portability and what me to write in Python , which I’ve resisted.
I suggest that Python is already showing how “Not Universally Portable” it actually is.
I will press on until(if) a complete “Show Stopper” is encountered.
2 Likes
Remember that we came from “oh, Windows users have to wait for somebody to do the PowerShell conversion”…. we are now not that far away from that for QNAP users since we all know how crippled the Python installation on this vendor’s system can be. Older QNAP systems are even worse (but could still use the shell script).
I will probably not go the extra mile to install something else to my ecosystem in order to use what could be used OOTB before.
Don’t get me wrong… I can fully understand anybody who wants it to work in their own ecosystem more flawlessly (older version of DBRepair is available in PowerShell). In my view, the use of Python is simply shifting the problem from one group of users to another group of users. I will now save the current version to keep it to have something that I could use later.
Let’s watch how this will evolve… maybe @ChuckPa can work it out.
1 Like
I fear this also and, whilst I am very happy with how to run the script, I have been unable to follow the Python portion of this thread and think that maybe I will not be able to use it (at least the effort required to learn how to use it and then actually use it will be more than I am prepared or able to do).
I totally get why we’re moving to Python, but I fear that I’m effectively precluded going forward.
Edit: I’m on a QNAP
1 Like
I’ll second (third?) the last two folks… I’ll keep the latest .sh version around instead of trying to setup an environment for python compatibility. I use synology and qnap for simplicity and am not interested in the awkward steps required so far to get a “python is more universal” environment setup on my NAS servers. Just weighing in, not making a case or argument.
I do appreciate the intent and the efforts being put in here. 
