No Powershell at this time.
The Windows/PS developer is on travel for work
I only spent about 10 seconds looking at the code, figured Iād ask instead. 
Does this perform the rebuild or just flag them for rebuild by Plex?
If the latter, does it truncate or delete them? Would it make sense to?
1 Like
When it finds FTS (Full Text Search) indexes are damaged, the indexes are rebuilt (repaired) just a regular indexes are rebuilt (repaired) by the Reindex command.
Now, FTS4 indexes, which are maintained separately in the DB, are expressly checked and rebuilt.
The most common manifestation of a FTS index failure is with Collections.
The server will return 500 (internal server error) in the PMS logs
2 Likes
Any timeline as to when it might become available? Full respect to needing to complete the paying job part of life.
No idea.
If there are any powershell-capable folks out there, I donāt think Dan would mind.
Iām going to put this out there again, just because the Unix-like OS vs. Windows dichotomy comes up so often, and causes such frictionā¦
Why not port this to Python 3? Python is available in every environment worth supporting (in general, if it gives you a Bourne shell, you get Python). It would be a port once, run anywhere solution.
2 Likes
The only reason itās not in Python is because Python is not available on every platform by default.
I wrote DBRepair to be free-standing.
NAS platforms and various containers are not guaranteed to have bash.
If you look, it uses /bin/sh and not /bin/bash because not even bash is available in all environments.
2 Likes
I hope I didnāt imply it was, by default. I know that it needs to be installed manually on some platforms. But, as far as I know, it is available on nearly every platform (including all Linux-based NAS devices, as far as I know).
But itās not. It now requires porting to Windows, arguably (probably able to be shown by usage stats) the most popular server platform. Its lack of consistent, timely support for updates or new features is noteworthy.
The āBourne shellā is /bin/sh. Bash is the āBourne again shell.ā Thatās why I made distinction.
I donāt mean to be antagonistic. I think it would be beneficial to many more users in the long run. And I donāt mean to dismiss the great efforts youāve made, or that the folks who port your script to Windows have made. It just doesnāt need to be this hard. In my opinion. Others are, of course, are fee to disagree.
Has anyone tried this with the bash/sh that comes with Windows Subsystem for Linux (WSL)?
Is installing WSL any harder than installing python on Windows?
Honestly, I donāt know. Neither one is installed on my laptop.
Harder? Not necessarily. But it does require more knowledge. You have to first install WSL. Then you must install a particular (full) Linux distribution. Then one must be knowledgable in how to use Linux, from the command line. And it consumes a great deal of disk space (depending on the distro, and I know that disk space isnāt always the primary factor).
Fair enough, Like I said, I have not experience with it. I thought it just gave you a shell like environment. Seems like it would be easier to just install a vm or docker thing to do it.
In fairness, I donāt use a vm or docker things either, lol. So I plead ignorance.
You or I could likely do that with ease. My concern is for the general Windows user who just wants their stuff to work. Installing WSL, a VM, or Docker just to fix Plex issue might seem a bit too much for them. While running a simple Python script would be within their grasp.
My concern is for the (likely) largest segment of PMS users. I donāt think it needs to be that way. If I had the time Iād port it myself. Unfortunately I do not.
Since Python is wanted, Iāll look at it.
Itāll be a full rewrite.
3 Likes
If you have questions, let me know, Iāll try to help.
I looked at WSL a LOOOOOOOOOOOOOOOOOOOOOOONG time ago.
It was a bash shell (cygwin style) on windows.
Best I can paraphrase.
A shell-only container, with driver letters mapped as paths, with exception of a minimal ā/binā directory
+1 for Python if it canāt be done with PowerShell 
1 Like
Itās just a personal liking, but I like the non-python approach very much. Iāve seen a Plex python project going downhill once and it was not a pleasure. Python is one of the packages that is tightly controlled by NAS vendors, so in the future, there will be the same problems with P3 as there were with the change from P2 ā P3.
I am glad with whatever @ChuckPa comes up with, but I like the Linux/Unix script approach.
BTW, thank you @ChuckPa to keep this aliveānākicking.
2 Likes
May I ask why, specifically? This isnāt a Plex-sponsored project. Itās a user created utility which can conform to a common platform. Right now, the largest single PMS user base is a bit disenfranchised. Porting to Python could help remedy that. It would require upkeep, but all projects do. Right now, every change requires a complete reimplementation in PS.
And again, I appreciate @ChuckPaās efforts here. It was a great start. I just donāt think itās the end.
I thought I did tell alreadyā¦ itās a personal liking.
I can still use shell scripts that have been written 20 years agoā¦ they still work (not all of them do, of course). I am not battling other peopleās opinions, I just raise my own opinion.
I hear what you are saying. It doesnāt convince me. If P4 will be the same change compared to P3 than P3 has been compared to P2, then hassle will be on the horizon even on Linux-based systems. Python is a tool not easily updated in NAS environments, so all Python scripts will run into problems as soon as they do no longer support older version of Python. Burned hand syndrome of mine.
It might be true that today, all major NAS providers did the change to P3, but it took them quite a while to do so, because they donāt want to break their environments.
Call me apologethic, but I rather have a working Linux script than something that might or might not work in two or five-years time on my NAS.
You have different views and I am fine with this. As I said, I am happy with whatever @ChuckPa comes up with.
1 Like
This is a tool ostensibly created help Plex Media Server users recover from server database errors. As it stands now, a disproportionately large amount of those users cannot use it, at least in a timely manner.
An implementation in a more cross-platform scripting language (of which Python is arguably the most ubiquitous) would benefit all. Python is not going anywhere. Even if Python 4 comes along and changes things, it will be a single porting operation.
As it stands now, every simple change to the script requires extensive porting to a different scripting language for Windows users (by a 3rd party, not Chuck).
Porting to Python and specifying a common baseline version would ensure that most users, regardless of platform, would have immediate access to all the features and updates of the utility.
1 Like
