Sanity check: Emby Server in a container on an ESXi vm on Intel NUC

[PaulAdams 2]

I have installed the Emby Server app on my QNAP NAS (TS-531X) and it is happily delivering content from a local path and a second QNAP NAS, however as the CPU in both is ARM-based they won't be able to offer hardware transcoding (if I have understood things correctly).

I have a couple of Intel NUCs running ESXi so I was thinking of setting up a Linux VM (likely Ubuntu) with Docker to run Emby Server as a container on one of them and have it stream all media from either NAS.

It's a NUC10i5FNH and I have enabled passthrough for the device "Intel Corporation CometLake-U GT2 [UHD Graphics]" in ESXi in preparation.

From a quick review of the Docker installation instructions I'm guessing it's just a local mount for the configuration/database and remote mounts to each NAS I will be setting up?

Do I want the container to manage the mounts or should they be set up in the host OS and just passed through? (Unsure how authentication works.)

Are there any gotchas I should look out for when setting up the environment?

Thanks in advance for any input!

[PaulAdams 2]

Notes to self (in case I need to rebuild this in the future).

Attached: docker-compose.yaml

Accessing SMB shares from within the container

I chose the approach of creating a docker volume mapping to the CIFS shares, then presenting the volumes to the container under /mnt so Emby can grab them from the object picker.

Creating the volumes on the host:
docker volume create ... emby_tv
docker volume create ... emby_movies

docker-compose.yaml contents:
services:
  emby:
    volumes:
      - emby_tv:/mnt/tv
      - emby_movies:/mnt/movies
volumes:
  emby_tv:
    external: true
  emby_movies:
    external: true

This avoids storing credentials in clear text.

NOTE: The UNC path in the docker volume create has to use the IP address of the SMB server even if DNS works just fine.

 

Problem : container not automatically starting with the host

Container was set to restart "on-failure" but it appears a graceful host shutdown also takes the stops the containers gracefully, so when the host restarts it does not start the container again.

Solution was to change it to "unless-stopped".

 

Problem : "Failed to open the drm device /dev/dri/renderD129"

I ran into a problem figuring out how to expose the Intel QuickSync device to the container.

I was getting the following error in the hardware-detection log:
{
"DeviceIndex": 1,

"DeviceInfo": {
"VendorName": "Intel Corporation",
"DeviceName": "CometLake-U GT2 [UHD Graphics]",
"SubsytemVendorName": "Intel Corporation",
"VendorId": 32902,
"DeviceId": 39745,
"SubsytemVendorId": 32902,
"SubsytemDeviceId": 8321,
"DevPath": "/sys/bus/pci/devices/0000:0b:00.0",
"DrmCard": "/dev/dri/card1",
"DrmRender": "/dev/dri/renderD129",
"IsEnabled": 1,
"IsBootVga": 0,
"Error": {
"Number": -1,
"Message": "Failed to open the drm device /dev/dri/renderD129"
}

This, despite "ls /dev/dri" showing the devices inside the container.

No idea what permissions are required, but this shotgun approach appeared to work:
sudo chmod a+rw /dev/dri/card1
sudo chmod a+rw /dev/dri/renderD129

Now the log is a lot bigger and lists a whole bunch of decoders:
{
"DeviceIndex": 1,
"DeviceInfo": {
"VendorName": "Intel Corporation",
"DeviceName": "CometLake-U GT2 [UHD Graphics]",
"SubsytemVendorName": "Intel Corporation",
"VendorId": 32902,
"DeviceId": 39745,
"SubsytemVendorId": 32902,
"SubsytemDeviceId": 8321,
"DevPath": "/sys/bus/pci/devices/0000:0b:00.0",
"DrmCard": "/dev/dri/card1",
"DrmRender": "/dev/dri/renderD129",
"IsEnabled": 1,
"IsBootVga": 0,
"ApiVersionMajor": 1,
"ApiVersionMinor": 12,
"Driver": "Intel iHD driver for Intel(R) Gen Graphics - 21.2.2 (27b773b2)"
},
"Decoders": [
{
"CodecName": "MPEG2VIDEO",
"CodecProfile": "MPEG2_SIMPLE",
...
"CodecName": "MPEG2VIDEO",
"CodecProfile": "MPEG2_MAIN",
...
"CodecName": "H264",
"CodecProfile": "H264_MAIN",
...

 

Now to compare the 2 instances of Emby Server over the Internet from various devices, and of course buy an Emby Premiere license so I can actually test hardware transcoding!

docker-compose.yaml

[PaulAdams 2]

Discovered that the chmod changes don't survive a reboot of the host, so I created /etc/rc.local with the following contents:

#!/bin/bash
chmod -R 777 /dev/dri

Then marked it executable:

sudo chmod +x /etc/rc.local

 

Also changed the yaml file a bit:

- replaced the 2 /dev/dri... lines with a single /dev/dri

-removed privileged

- changed GID from 100 to 109 (render group on the host)

 

I first tried Linux about 20 years ago and found it to be thoroughly unhelpful and non-intuitive, not much seems to have changed

(Possible a little biased as I was a Support Escalation Engineer for Microsoft for 9 years ;))

Bought my Emby Premiere Lifetime key, I am thoroughly impressed with this software, nice job!

docker-compose.yaml

[Luke 37192]

Quote

From a quick review of the Docker installation instructions I'm guessing it's just a local mount for the configuration/database and remote mounts to each NAS I will be setting up?

Hi, mostly, yes, and also gpu setup.

Quote

I chose the approach of creating a docker volume mapping to the CIFS shares, then presenting the volumes to the container under /mnt so Emby can grab them from the object picker.

Hi, this is the route I would suggest as well.

[PaulAdams 2]

Cheers Luke, and props to the team on a great product!

I have scratched and rebuilt the container several times, plus restarted the host a couple of times to verify it comes up without errors, very pleased!