Request for assist -- Interfacing PlexDBRepair tool

[ChuckPa]

I've been informed, and have now confirmed myself, my existing method of uniquely identifying binhex/plex containers is no longer valid since python was updated (3.11 ?).

Is there anything (file/directory) you can point me to, not version specific, which will always allow me to identify binhex plex containers?

With thanks,
Chuck

[binhex]

There are two files you could check, firstly you could cat /etc/os-release, if the IMAGE_ID matches archlinux then there is a high chance its an image produced by me, im the only person i know of that creates arch linux based docker images, a sample output from /etc/os-release for one of my images:-

sh-5.1# cat /etc/os-release 
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo
IMAGE_ID=archlinux
IMAGE_VERSION=2023.01.01

The second thing you could then check for confirmation is to look for the presence of the file /home/nobody/start.sh, this is the script that sets up env vars and then kicks off plex.

FYI i have recently created a Plex DB repair script as i still see corruption issues occurring on my support thread, its fairly basic tbh but seems to work reasonably well:- https://github.com/binhex/arch-plex/blob/master/run/nobody/dbrepair.sh

[ChuckPa]

Thank you for this info. I'll be of great help. I'll make time this weekend to update.

As for your version, I have a few suggestions.

1. Don't kill (default signal) PMS
2. Give it kill -15 (it's programmed to exit nicely on sig 15). Anything else will promote more corruption.

• You might want to include this in your start/stop for the main container too if applicable.
• Also, because some normal shutdown sequences take a long time time to flush (WAL file is big), you might wait to
  actually give it up to 20 seconds and then retry. (this is common on QNAP)
• I must be very careful with each NAS OS because some 'kill' events are abrupt and brutal while others aren't.
  My scripting for PMS itself is customized to work for each platform it runs on.

3. Don't use recover. Recover can leave you with a 0-length DB file.

If you want, I'll beef up my routines but please do understand, I've written them to be /bin/sh compatible.
(we can discuss via another vehicle if you wish). I cannot afford the luxury on NAS boxes of using BASH (my code would be so much more elegant) because bash is not guaranteed present where /bin/sh is.

Last question:
If I am to add my standard Start and Stop controls, how do you like that done from inside the container?
(exact shell command would be ideal as I set StartCommand="shell command" and similarly for StopCommand)

[ChuckPa]

@binhex

Can we chat somewhere ? We have an issue to resolve.