no, it was about automating with systemd but maybe cron is better for weekly or monthly bases. i will wait for your next release/ docs whenever that happen, in the mean time i will run in manually
lol fair enough, i will run your tool and report back, what about plex implementing your tool into plex ?
If you want to, you’re welcome to join my Development thread here in the forum.
We’re at “beta 3” level. It’s “beta 3” because with the huge fork-lift I did to the code, I’m still finding little things to tweak and make perfect ( That’s how I roll )
The tool has established itself as really having positive impact on Plex operation.
It’s fixed a lot of broken databases to date as well as really improved performance.
1 Like
will do sir and thank you for having the patience with me as well for develoing this tool. as for plex implementing this into plex…do u have an answer or cant answer it?
While I know what it will take for Plex to implement,
I don’t know if they can or will.
There’s quite a Fork Lift work for them to implement because PMS grabs the databases BEFORE the HTTP server and network connections come up.
Putting this functionality in PMS would require a “Maintenance Mode” set of pages in the HTTP server
- HTTP Server only
- Sockets
- The “Maintenance mode functions”
- Upon exiting maintenance mode – Main PMS
The real challenge is how to switch from “Live & serving media” to “Maintenance”.
I know the broad strokes but not the level of effort required.
I suspect it’s more than they would consider implementing.
Based on that is why I continue to improve my shell script tool.
cool and fair enough, well i will give this a try and report back. and in term of switching db is will be also a big task as well?
Switching to a different DB engine would, frankly never be entertained.
SQLite3 is capable of over 14,000,000 record files in a heartbeat without flinching (I’ve done it)
PMS, because it’s evolved, has too much “SQLite3” dependent code in it.
(Abstracting DB calls into “Generic member methods” in C++ is way harder than just writing dedicated SQLite code).
There is a whole branch of functionality of SQLite which is. as of yet, untapped. If the need arises. then maybe they’ll use it.
I’m really curious why you’re pushing for a different engine when you only have 100K items and I test with 3x that amount without issue.
My CPU is a much older Xeon E5-2690 v4 and I don’t use SSD for the DB.
I think this is just a case of learning to manage what you have.
fair enough. am only mentioning the different bd because of what other pp have said but you definitely know moire than me. Regardless You have given me some hope. i will run your script and report back.
i just ran your tool and plex hasn’t crashed yet but i just got the error again.
Let’s retrace
- You put the DBRepair.sh in wherever the container can see it.
- You got into the container with
docker exec -it xxxxx bash - you stopped PMS in the container
- now you , because you’re root in the container, ran
DBRepair.sh - Ran command options 1 - 4 - 3 without any errors
- Started PMS
- exited the container.
All this?
i rebooted the container instead but yes, i did not got any errors and i did not take any screenshots
in the databases directory, you’ll find DBRepair.log
Can you show me please? It’ll report what it was able to accomplish
which Ryzen 5 do you have 2600 or 3600 ?
is it safe to share the log here? and i have the 3600
The DBRepair.log ? Yeah. It’s only a list of what you did.
It shows a few file statistics. No names.
i think i didnt mention but issue i believe mainly happens when am scanning the library if am not mistaking
You did a vacuum
1 - Check
4 - Repair
3 - Reindex
Your DB might have a lot of junk in it too… Don’t know how much it’ll get out
ok i did it wrong ?
how can i run this ?
Slightly.
1 = Check
4 = Repair
3 = Reindex
I forget but I think 2 = Vacuum (been a while since I looked at the old UI)
You doing 1-2-3 is why I changed the UI. It’s not your fault
