Moving from Project Trident to Docker

[mlcarson 13]

Project Trident just announced that their moving from FreeBSD to Linux.  Unfortunately for me, I moved my Emby system from Windows to Project Trident a couple months ago.   All of my media files are on a ZFS pool if that matters.    I now have to make a choice again on what OS to use.  I could simply install FreeBSD and install a Desktop Environment on top of it, move to GhostBSD, or give the Linux/Docker concept a go.    I'm leaning towards Docker but have no experience with it.   

 

Does the underlying Linux distribution make any difference on Docker containers?    If I just do a minimal install of Docker on Alpine Linux, can I get a functional emby-server by just grabbing the latest emby-server container?   Or maybe I want to give Void Linux a try since that's what Trident is moving to. Does it matter?   If the underlying Linux makes a difference even with containers, what's the recommended Linux distro for Emby?

 

 

 

[Luke 37056]

Hi, it shouldn't matter, although I can tell you we haven't tested Void Linux ourselves, although I would be interested to see the results.

 

But I would say Ubuntu and Debian are the most commonly used.

[mastrmind11 717]

Yeah go with docker, it's super simple.  I'm running emby docker and all my media is in a zfs pool, no problems ever.

[mlcarson 13]

I'm assuming now this must have been sarcasm but I didn't read it as such.  My FreeBSD installation was much quicker than this without knowing anything about FreeBSD.  I could have installed directly on Linux much much easier than trying to use Docker.   I'm about to give up on it.

 

I have a base Debian 10.1 install on an EXT4 partitioned boot drive that uses LVM.   It's configured for UEFI boot.   Debian installation was relatively painless.  I added ZFS on Linux 0.8.2 package.  I was a bit cautious on getting the FreeBSD created ZFS pool online because I didn't want to destroy it but it was relatively painless getting it to mount.  I see all of my files so I'm thinking all is going well.   I add the contrib & non-free options to the /etc/apt/sources.list so I can get the Nvidia video drivers and the nvidia-container-runtime package for the NVDEC/NVENC GPU acceleration.   I installed docker and pull the latest emby/embyserver and then everything goes to hell.

 

The run command for the emby/embyserver Docker container needs a LOT more documentation. 

What's the first parameter of the --volume option?  What's the second parameter?

Both are nonexistent paths -- typically one would be a variable/logical representation and the other a physical/actual location.

If I need another volume, do I used /path/to/share3:

The --device parameter is just as ambiguous and points to a directory and not the actual renderer which I believe would be /dev/dri/renderD128.

The --runtime =nvidia just gives me an error so I deleted it.

 

The UID and GID defaults are bizarre.  Why aren't they 989?

 

For the GIDLIST, why would 100 be included if it were the GID of Emby?   Should it include the renderer or the video group or both?

 

My ZPOOL is simply named storage and is mounted as /storage and includes a top level directory called media.   I was hoping just to be able to mount a single share volume as /storage/media but that didn't seem to work.  I have directories under /storage/media for Movies, Recordings, and "TV Shows".  Note the space in "TV Shows".    This was the next directory that I tried mapping to Emby with no success so I thought maybe it was the space and tried various options to get it in and it would appear to work but Emby has never found any files on it.  If I su to the emby user it can see the directories/files so it doesn't seem to be an underlying permissions issue.    So I give up on "TV Shows" and go to Movies.  I add it to the run parameters and it shows up as an option to map in the libraries but again it contains no files.

 

My run command looks like this currently:

docker run -d \

--volume /path/to/programdata:/config \

--volume /path/to/share1:'/storage/media/TV Shows' \

--volume /path/to/share2:/storage/media/Movies \

--device /dev/dri/renderD128 \

--publish 8096:8096 \

--publish 8920:8920 \

--env UID=989 \

--env GID=989 \

--env GIDLIST=107,989 \

emby/embyserver:latest

 

This so far has been anything but super simple. 

 

Yeah go with docker, it's super simple.  I'm running emby docker and all my media is in a zfs pool, no problems ever.

[mlcarson 13]

Alright, I think I've discovered through trial and error that the volume syntax is the exact opposite of what I thought it would be.  By swapping the first and 2nd parameters I was able to get files to show up.   This is not documented well and is an ordering that goes against normal conventions.

So the run command looks like this:

 

docker run -d \

    --volume /storage/media/Emby/config:/config \ # This is mandatory

    --volume /storage/media/TV Shows:/mnt/tvshows \

    --volume /storage/media/Movies:/mnt/movies \

--volume /storage/mediaRecordings:/mnt/recordings \

    --device /dev/dri:/dev/dri \

    --runtime=nvidia \

    --publish 8096:8096 \

    --publish 8920:8920 \

    --env UID=989 \

    --env GID=989 \

    --env GIDLIST=989,107 \ 

    emby/embyserver:latest

Edited October 27, 2019 by mlcarson

[mastrmind11 717]

you might consider adding  --restart unless-stopped in your command too.

[mlcarson 13]

I'm still trying to figure out this "easy implementation" so am constantly destroying the container.   The --runtime=nvidia syntax is obsolete and no longer works; apparently it's no longer needed and the field gpus was introduced so --gpus=all or --gpus=1.   I'm still not sure whether the --device should be what I put in post#5 or if it should be --device /dev/dri/renderD128:/dev/dri/renderD128.  I have not gotten hardware transcoding to work at all.

 

The relevant error message seems to be in the hardware detection log:

"Devices": [
{
"DeviceIndex": 0,
"DeviceInfo": {
"VendorId": 4318,
"DeviceId": 5050,
"SubsytemVendorId": 4156,
"SubsytemDeviceId": 4247,
"DevPath": "/sys/bus/pci/devices/0000:06:00.0",
"DrmCard": "/dev/dri/card0",
"DrmRender": "/dev/dri/renderD128",
"IsEnabled": 1,
"IsBootVga": 1,
"Error": {
"Number": -1,
"Message": "Failed to initialize VA /dev/dri/renderD128. Error -1"
}
}
}
],
"Log": [
{
"Level": 40,
"Category": 0,
"Message": "Found 37 device entries"
},
{
"Level": 24,
"Category": 0,
"Message": "GetDeviceName: unable to open pci.ids file "
},
{
"Level": 24,
"Category": 0,
"Message": "GetDeviceName unable to load pci.ids file"
}
]
}

Edited October 27, 2019 by mlcarson

[Luke 37056]

Just in case it might help at all:

https://emby.media/community/index.php?/topic/76937-docker-hwa-nvidia-instructions/

[mlcarson 13]

It did help.  I now have HW transcoding working.

This is my final run file now:

docker run -d --name=Emby \
--volume /storage/media/Emby/config:/config \
--volume '/storage/media/TV Shows':/mnt/tvshows \
--volume /storage/media/Movies:/mnt/movies \
--volume /storage/media/Recordings:/mnt/recordings \
--device /dev/dri/renderD128:/dev/dri/renderD128 \
--gpus all \
--publish 8096:8096 \
--publish 8920:8920 \
--env UID=989 \
--env GID=989 \
--env GIDLIST=107,989 \
--env NVIDIA_VISIBLE_DEVICES=all \
--env NVIDIA_DRIVER_CAPABILITIES=compute,utility,video \
emby/embyserver:latest

 

I verified that my host settings were working with vainfo and vpdauinfo and then tried the extra --env settings.  The NVIDIA env settings are what made the difference.

So my setup is:

AMD Ryzen 7 1700

Debian Buster 10.1 KDE Plasma

Linux Kernel: 4.19.0-6

Nvidia Quadro K2200

Nvidia 418.74 nonfree driver

ZFS on Linux 0.8.2

Docker Engine 19.03.4

API version: 1.40

Containerd: 1.2.10

 

So I guess now I have to figure out how to actually use this in production starting with the "--restart unless-stopped "

 

 

 

 

 

Just in case it might help at all:

https://emby.media/community/index.php?/topic/76937-docker-hwa-nvidia-instructions/

Edited October 28, 2019 by mlcarson

[Luke 37056]

Thanks for the feedback !