Apparently exactly 1 year ago I made a similar post
At the time, I tried to find the optimal set up. @ChuckPa your answer was to migrate over from my native Synology package over to Docker with the “overlay” method. Meaning this whole time Docker has been auto-updating (1.32.1.6954) and the native package has remained installed but not running (1.25.7.5604-7000). I believe the reason the Docker is on an April release is because it only actually auto-updates on a reboot and my last reboot was in April.
Now with 7.2 out and the new Container Manager, I was doing some reading to see if there are any breaking changes with upgrade. I did not find any, but in this time, I discovered that HW transcoding with HDR no longer requires this double set-up that I had set up last year. With that in mind, is there a new “optimal set-up”?
Do I uninstall the package and just keep Docker?
Or do I uninstall the Docker version and just update the Synology package to the latest version available from Plex?
Or do I just keep the setup I have now? Does the new Container Manager change anything about this?
Is there one advantage to one over the other? In terms of performance, upgrades, stability, future ease to move to another machine, etc.
Now might not be the best time for me to do this because I saw the current version of Plex has a bug with HW transcode and requires a pre-release hotfix. But assuming the next version, for example, what would be the answer to those questions?
Upgrading to DSM 7.2, do I just keep my current Docker set-up that auto-updates? I guess the passthrough was done without GUI, so I don’t really need to change anything since it’s already set-up. Or is there a reason to go to native package?
If sticking with Docker, is there still a reason to keep the Synology package installed (but not running)?
I’m curious as to where you netted out with this. I have a 1520+ on 7.2 and I’m doing a fresh install and if there’s an easier way than the 2 year old method I’m all ears.
If you want hardware transcoding AND require Docker (which isn’t required)
Then the only way to create the container is either with docker compose or docker run from the SSH command line or Scheduled Task - User-script.
It’s a “Pick your poison” decision.
The native app has everything the docker container does and then some.
The native app does all the setup for you. Docker requires you to handle it.
The native app has always supported HW transcoding.
HW tone mapping was added over a year ago now.
After setup is complete, there is no difference. You’re running the same exact executable program binaries in either environment. The only change is how it’s packaged / installed.
The setup of the native app is the biggest advantage.
Thank you for the clarification - I browsed the forum a bit before posting, and the amount of work you put in here is crazy. Appreciate the quick responses and all the work you do.
myself
