Continuing the discussion from HDR Tone mapping - force software transcoding:
Server Version#: 1.25.0.5282
Player Version#: Samsung 2.012
Hi, I found the old thread on the topic that some libraries (Beignet and OpenCL) are required to support tone mapping in hardware. Since it’s been a while since the other topic was active, is there any news on supporting/providing these for QNAP devices, or when it would roughly be available?
Thanks and best
I keep pressing Engineering to allocate the time — Not there yet.
in lieu of that, how about docker ( which Container Station controls VERY nicely )
You have to do this via the command line / shell script because we cannot pass devices in the container station setup
This is my working QNAP version
It creates a container which perfectly overlays your existing PMS installation.
PMS MUST be INSTALLED and DISABLED (Stopped status in App Center) when the container is active. There are no safety checks so caution is strongly advised. The container setup function does stop it but doesn’t disable it.
I have tested this remotely on our HQ NAS but don’t have anything local for proper HDR → SDR tonemapping testing. The 2 minute sample did not look washed out.
When you want to update the container (image) rerun the script.
Change Time Zone as appropriate.
#!/bin/sh
# DockerPlex for QNAP with HDR - SDR tone mapping support.
# author: ChuckPa
#
# Find Container Station
DOCKER_DIR=$(getcfg -f /etc/config/qpkg.conf container-station Install_path)
# verify installed
if [ "$DOCKER_DIR" = "" ]; then
echo ERROR: Container Station not installed.
exit 1
fi
# Set alias
Docker="$DOCKER_DIR/bin/docker"
# Find Plex
PLEX_DIR=$(getcfg -f /etc/config/qpkg.conf PlexMediaServer Install_path)
# Verify Plex installed
if [ "$PLEX_DIR" = "" ]; then
echo ERROR: Plex not installed.
exit 1
fi
# Stop Plex
/etc/init.d/plex.sh stop
# Warn if no HW detected for HW transcoding
[ ! -e "/dev/dri/renderD128" ] && echo "WARNING: NO QSV hardware found."
# Remove the old container image (prepare to update the image)
echo Stop and remove Plex container
$Docker stop Plex
$Docker rm Plex
# Remove old image if exists
Image="$($Docker images | grep -i Plex | awk '{print $3}')"
if [ "$Image" != "" ]; then
echo Removing image
$Docker stop Plex
$Docker stop Plex
$Docker rm Plex
$Docker rmi -f $Image
fi
# Should be both QTS and QuTS compatible as-is (verified on QuTS Hero)
$Docker run \
-d \
--name Plex \
--network=host \
-e TZ="EST" \
-e LANG="en_US.UTF-8" \
-e PLEX_UID=0 \
-e PLEX_GID=0 \
-e PUID=0 \
-e PGID=0 \
-h DockerPlex \
-v ${PLEX_DIR}/Library/:"/config/Library/Application Support" \
-v ${PLEX_DIR}/tmp:/tmp \
-v ${PLEX_DIR}/tmp:/transcode \
-v /share:/share \
--device=/dev/dri:/dev/dri \
plexinc/pms-docker:plexpass
#$Docker start Plex
$Docker update --restart=unless-stopped Plex
I didn’t have much better to do tonight so decided to write it and give everyone something they can use and enjoy.
Oh my god it works! Very simple to test:
I was finally able to experience Plex’s tone mapping, which I must say is excellent. I ran 3 videos side-by-side on my MacBook Pro (original HDR vs transcoding via this PLX container vs transcoding via Shield TV with tone-mapping off). The former 2 were almost indistinguishable, while the latter had colors heavily washed out.
@ChuckPa thanks a million for making progress on this! I’m finally pretty close to retiring my Nvidia Shield as my primary Plex server. The only thing that remains is to make this method survives a reboot and/or a crash. Can this be accomplished by packaging this as a QTS app and changing docker command run to be interactive?
Do you see the -h DockerPlex ?
whatever name you put there (-h = ‘hostname’), is how the server will appear
I can make it into a package.
I’ll speak to my colleague about it when he returns to get his thoughts.
Thanks for the hint! I’m not that concerned with changing the Plex instance name, but it’s nice to see that it’s possible.
My biggest concern is to have the container auto-start so that I can depend on it when I want to watch something. My attempt to schedule your script auto-start (strictly after container station starts) using the fake QPKG method fails either because QTS wipes my script from /usr/local/sbin/ on restart, or because I’m missing some parameters. QTS marks the config section with “Enable = FALSE Incomplete_Conf = 1” and nothing works.
I did notice that starting the container from Container Station after it was created by the script works just fine, and I’ve reconfigured the container to restart automatically which also works. I’ll give it a couple of days to see how it works over time, will report back with results.
[EDIT] Is there a way to instruct Container Station to autostart the container on creation?
it will auto start.
$Docker update --restart=unless-stopped Plex
You have full control of it in container station.
Somehow this doesn’t work to make the container start on boot. Container Station’s own “autostart” policy is set to off after that script is run.
I tested on TS-453BE with the latest firmware installed.
Hmmm.
It works for me. I must have done something / forgot something for the script
Per this page
always or unless-stopped will restart the container.
You can change my script to use always in case it’s a QNAP quirk
I changed the -h value in the script and confirmed that the server name has changed in the Plex app. Nice!
I tried both “always” and “unless-stopped” values for --restart command, and it doesn’t look like it has any effect. The container still has “Auto start” set to off, and it indeed doesn’t restart on reboot or if manually stopped.
In order to fix it, I stop the container, change the setting to on, and restart it manually. Then everything seems to work just as it should.
I don’t think this is exceptionally hard to use as is, but in order to make this workaround perfect I’d suggest:
what I’ve written works with any dockerd .
It seems QNAP has something special.
If this changes the “how-to” for qnap. I’m ok with that.
This isn’t really a supported package. It’s my way of helping out because the bigger issue.
I’ve done this for Synology and now for QNAP.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
