Native install vs Flatpak vs Docker?

[raevengel 0]

Hi,

I’ve been running a “native” Emby install on Linux Mint for the last year or so installed via the .deb package. I’m having just awful issues with Mint and impossible to pin down bugs so I decided to grab an NVMe SSD and start over with OpenSUSE Tumbleweed (so I’m keeping the Mint install limping along till I get the new one sorted out). 

oST is now installed and I’m about to install Emby but before I proceed, I wondered if anyone had compared running Emby as a native install, via Flatpak, vs Docker. I’ve read that for Plex, Docker can limit the number of threads/CPU making things like transcoding a much different experience (in this case, the person could do I think 10 transcodes in the native install vs around 2 transcodes in the Docker install). I’ve run Plex on my Mint install via a Snap and found that Snaps take up a lot of CPU usage and I’d find myself with 100% usage on all CPU/threads on my quad core/8 thread Core i7 setup. What I don’t know is what is from the Mint bug issues, what is from running in a Snap, and if Docker, Flatpak or a native install would be better (or if either of them would be similar/worse).

The thing I like about Snap/Flatpak/Docker is the sandboxing of files and not worrying as much as dependencies running into each other. Obviously, that means there can be duplicated dependencies and I worry about the performance. 

What have any of you used and has anyone compared performance of running Emby in Docker vs Flatpak vs native install? I’d love to hear any thoughts, advice, experiences, etc. Thanks so much in advance!

[fredflix 23]

I don't think Docker limits the number of cores for containers unless you specify it.
I run Emby server on Debian in a docker container and all my 8 cores get used when transcoding.
Your 100% CPU usage might be due to Snap not detecting quicksync or maybe you have to point the snap package to your CPU device driver, I'm not really familiar with Snap.

I tell you this because for Docker, provided you have a recent i3-i5-i7 CPU, you have to provide the path to the driver to get quicksync working.
In my case I gotta use the "--device /dev/dri" to the docker run command. If I don't specify that, transcodes take pretty much all my CPU resources instead of maybe 1/10th of that with quicksync enabled. Native install doesn't have this issue because the installed app has full access to your computer. In Docker, you kinda got to tell it what resource can be used for your container.
Once you get familiar with Docker, you won't go back. It's so much more customizable than a Snap/Flatpak package. You can specify where you want all the config files to be stored at making backups very easy. With native or Snap/Flatpak, you gotta hunt for the location of settings/config files and sometimes they all over the place.
Where Snap/Flatpak is useful is for Apps that don't rely on user configs. If there are user configs to be setup, I'd recommend Docker instead.

As for native installs, I usually would only do it in a VM where there's nothing else on it. You can then back up the whole VM file.
If there's gonna be other stuff installed on that machine, then I go for Docker.

If you don't need/want to backup anything, then just native install everything.

Edited July 3, 2020 by fredflix

[Luke 37006]

If hardware accelerated transcoding is important to you then the native package will generally be the easiest to get that working with.