Emby auf der Synology DS einrichten - Docker vs Nativ und weitere Fragen

Commerzpunk

Kann schon sein, aber alles andere hab ich nicht hinbekommen.
Diesbezüglich habe ich mit Linux aufgegeben.
Root soll man nicht, aber anders geht es meistens nicht, zumindest nicht mit vertrebarem Aufwand.

Sag mir, welche andere Zahl als 0 da rein soll, bzw. wie ich diese ohne Umstände rausfinden kann und ich mache es.

keyboarder2k

Ich habe mich heute Vormittag mit dem Thema auseinandergesetzt. Letztlich sieht meine Lösung nun so aus.

1. Anlegen eines Users und einer Gruppe "video" auf der Synology und ermitteln der zugehörigen UID/GID (im Beispiel hier 1234 bzw. 54321). Diesem User gehören die Shares für die Video-Dateien und er hat darauf volle Rechte. Andere User haben ggf. auch noch Lese-/Schreibrechte.

2. Im Aufgabenplaner wird eine Aufgabe generiert, die die Transcoding-Devices auch für die Gruppe "video" zugreifbar macht. Wichtig ist hier, dass die Aufgabe nach jedem Boot der DS wieder ausgeführt werden muss (lässt sich für die Aufgabe als Trigger auswählen), da per default nur der root-User Zugriff auf die Devices hast (keine Gruppe).

Bash

if [ -d /dev/dri ]; then
  chgrp video /dev/dri -R
  chmod 755 /dev/dri
  chmod 666 /dev/dri/*
fi

3. Docker-Image von linuxserver.io und nicht von Emby
Das habe ich gemacht, weil nur dort die Nutzung der PUID/PGID und auch die Übergabe der TZ-Variable sauber funktionierte. Im Image von Emby selbst funktionierte beides nicht. Zudem ermöglicht das Image von linuxserver.io die Variable "UMASK_SET". Damit werden alle Files, die vom Emby-Container erzeugt werden, für alle anderen lesbar angelegt (644/755). Weiterhin ist es mir mit dem Emby-Image nicht gelungen ein Terminal im Container zu öffnen.

4. Anlegen des Containers über den Aufgabenplaner der DiskStation als 1x-Aufgabe als root. Die Pfade/Volumes sind natürlich ggf. anzupassen.

Bash

#!/bin/bash
docker run -d\
  --name=emby \
  --net=host \
  -e PUID=1234 \
  -e PGID=54321 \
  -e TZ=Europe/Berlin \
  -e UMASK_SET=022 \
  -p 8096:8096 \
  -p 8920:8920 \
  -v /volume/docker/emby_config:/config \
  -v /volume/videos/:/data \
  --device /dev/dri:/dev/dri \
  --restart unless-stopped \
  linuxserver/emby

Alles anzeigen

Als Ergebnis habe ich nun ein lauffähiges Emby-System als Docker-Container inkl. HW-Transcoding auf meiner Synology DS1019+.

bennySB

Zitat von keyboarder2k

3. Docker-Image von linuxserver.io und nicht von Emby
Das habe ich gemacht, weil nur dort die Nutzung der PUID/PGID und auch die Übergabe der TZ-Variable sauber funktionierte. Im Image von Emby selbst funktionierte beides nicht. Zudem ermöglicht das Image von linuxserver.io die Variable "UMASK_SET". Damit werden alle Files, die vom Emby-Container erzeugt werden, für alle anderen lesbar angelegt (644/755). Weiterhin ist es mir mit dem Emby-Image nicht gelungen ein Terminal im Container zu öffnen.

Super Anleitung, finde ich klasse wenn so etwas für andere geteilt wird, jedoch muss ich dich in einem Punkt korrigieren:

Das offizielle Emby Image unterstützt sehr wohl die Einstellung der User und Group-IDs

Code

docker run -d \
    --volume /path/to/programdata:/config \ # This is mandatory
    --volume /path/to/share1:/mnt/share1 \ # To mount a first share
    --volume /path/to/share2:/mnt/share2 \ # To mount a second share
    --device /dev/dri:/dev/dri \ # To mount all render nodes for VAAPI/NVDEC/NVENC
    --runtime=nvidia \ # To expose your NVIDIA GPU
    --publish 8096:8096 \ # To expose the HTTP port
    --publish 8920:8920 \ # To expose the HTTPS port
    --env UID=1000 \ # The UID to run emby as (default: 2)
    --env GID=100 \ # The GID to run emby as (default 2)
    --env GIDLIST=100 \ # A comma-separated list of additional GIDs to run emby as (default: 2)
    emby/embyserver:latest

Alles anzeigen

Habe es bei mir selbst am laufen, mit angepassten IDs, aber unter OMV.

Nichts desto trotz sind die Images von linuxserver auch spitze.

keyboarder2k

Zitat von bennySB

[...] jedoch muss ich dich in einem Punkt korrigieren:
Das offizielle Emby Image unterstützt sehr wohl die Einstellung der User und Group-IDs [...]

Das stimmt schon. Aber in einem stumpfen Test mit beiden Images hatte ich beim Emby-Image keinen Zugriff auf meine Files, mit dem von Linuxserver.IO hingegen schon. Deshalb schrieb ich ja auch "funktionierte nicht" und nicht "gibt es nicht". Wenn es bei anderen oder auf anderen Plattformen mit dem originären Image klappt, umso besser.

Seger

Und vielleicht nochmal die Ausgangsfrage, würdet ihr sagen das es besser läuft als es es Nativ über DSM zu installieren? Oder sind die Vorteile einzig und alleine in der Dockerwelt? Soll nicht wertend klingen, ist wertfrei!

habt ihr Erfahrungen?

Viele Grüße
Seger

keyboarder2k

Der Vorteil ist für mich, dass ich das Ganze z.B. einfach wieder komplett löschen kann und keine Änderungen am Synology-System zurückbleiben, von der User/Group Geschichte in diesem Falle mal abgesehen. Auch gibt es einen Sicherheitsaspekt, weil aus der Docker-Umgebung nicht ohne weiteres ausgebrochen werden kann, um Änderungen am Host-System vorzunehmen. Auch ein Parallelbetrieb von z.B. einer zukünftigen oder Beta-Version von Emby wäre hier möglich - über andere Ports natürlich. Ebenso wäre ein Umzug des Docker-Containers auf ein anderes System relativ einfach unter Anpassung der einhängten Volumes möglich.

Besser oder schlechter ist und war immer sehr subjektiv. Für mich ist Docker u.a. aus den o.g. Punkten "besser"

postboy99

Zitat von keyboarder2k
Ich habe mich heute Vormittag mit dem Thema auseinandergesetzt. Letztlich sieht meine Lösung nun so aus.
1. Anlegen eines Users und einer Gruppe "video" auf der Synology und ermitteln der zugehörigen UID/GID (im Beispiel hier 1234 bzw. 54321). Diesem User gehören die Shares für die Video-Dateien und er hat darauf volle Rechte. Andere User haben ggf. auch noch Lese-/Schreibrechte.
2. Im Aufgabenplaner wird eine Aufgabe generiert, die die Transcoding-Devices auch für die Gruppe "video" zugreifbar macht. Wichtig ist hier, dass die Aufgabe nach jedem Boot der DS wieder ausgeführt werden muss (lässt sich für die Aufgabe als Trigger auswählen), da per default nur der root-User Zugriff auf die Devices hast (keine Gruppe).
Bash
if [ -d /dev/dri ]; then
  chgrp video /dev/dri -R
  chmod 755 /dev/dri
  chmod 666 /dev/dri/*
fi
3. Docker-Image von linuxserver.io und nicht von Emby
Das habe ich gemacht, weil nur dort die Nutzung der PUID/PGID und auch die Übergabe der TZ-Variable sauber funktionierte. Im Image von Emby selbst funktionierte beides nicht. Zudem ermöglicht das Image von linuxserver.io die Variable "UMASK_SET". Damit werden alle Files, die vom Emby-Container erzeugt werden, für alle anderen lesbar angelegt (644/755). Weiterhin ist es mir mit dem Emby-Image nicht gelungen ein Terminal im Container zu öffnen.
4. Anlegen des Containers über den Aufgabenplaner der DiskStation als 1x-Aufgabe als root. Die Pfade/Volumes sind natürlich ggf. anzupassen.
Bash
#!/bin/bash
docker run -d\
  --name=emby \
  --net=host \
  -e PUID=1234 \
  -e PGID=54321 \
  -e TZ=Europe/Berlin \
  -e UMASK_SET=022 \
  -p 8096:8096 \
  -p 8920:8920 \
  -v /volume/docker/emby_config:/config \
  -v /volume/videos/:/data \
  --device /dev/dri:/dev/dri \
  --restart unless-stopped \
  linuxserver/emby
Alles anzeigen
Als Ergebnis habe ich nun ein lauffähiges Emby-System als Docker-Container inkl. HW-Transcoding auf meiner Synology DS1019+.
Alles anzeigen

HAllo Zusammen,

ich versuche nun seit längerem Emby im Docker auf der Synology zum laufen zu bekommen mit VAAPI unterstützung.
Vorne weg: Wenn ich Emby als normales installiertes Paket benutze geht VAAPI ohne Problem. Im Docker einfach nicht, egal ob Emby/Embyserver oder linuxserver/emby.

Ich bin genau vorgegangen wie hier beschrieben.
Habe den User "video" angelegt und die PUID:1042 und GUID:100 geändert

Code

id video
uid=1042(video) gid=100(users) groups=100(users),65537(video)

Habe das Skript angelegt und ausgeführt, zusätzlich noch manuell geändert:

Code

ls /dev/dri/ -l
total 0
crw-rw-rw- 1 root video 226,   0 Oct  2 11:22 card0
crw-rw-rw- 1 root video 226,  64 Oct  2 11:22 controlD64
crw-rw-rw- 1 root video 226, 128 Oct  2 11:22 renderD128

Natürlich den Emby Prime Key eingetragen.
Dennoch ist das Transkoding nur Software-Transkoding. Er benutzt einfach nicht VAAPI.
Was ist falsch?

Bitte um Hilfe!

bennySB

Hast du auch das richtige Device durchgereicht?
Ich kenne mich leider nicht mit Synology aus, aber bei anderen System muss man dem Docker Container noch die Grafikeinheit durchreichen, damit er sie auch für das transcoding nutzen kann.
Aus deinem Code wäre das richtige Gerät "renderD128" oder stammt der Auszug aus dem Container?

postboy99

Zitat von bennySB

Hast du auch das richtige Device durchgereicht?
Ich kenne mich leider nicht mit Synology aus, aber bei anderen System muss man dem Docker Container noch die Grafikeinheit durchreichen, damit er sie auch für das transcoding nutzen kann.
Aus deinem Code wäre das richtige Gerät "renderD128" oder stammt der Auszug aus dem Container?

Du meinst also renderD128 mit durchreichen. Weil ja hier der ganze ORdner weitergegeben wird oder?

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

Also soll ich --device /dev/dri/renderD128:/dev/dri/RenderD128 machen oder was genau meinst du?

bennySB

Jup letzteres.

Also nicht nur den Ordner sondern direkt das Gerät. So hatte 8ch es bei mir inkl. funktionierenden Hardware Transcoding unter OMV als docker laufen.

postboy99

hatte ich getestet ohne erfolg

bennySB

Sorry, dann bin ich leider raus....keine Syno.

keyboarder2k

@postboy99 Du hattest mich angeschrieben. Aber eine echte Idee habe ich leider auch nicht. Bei mir läuft es nach wie vor so, wie ich es beschrieben hatte und du es ja auch "nachgebaut" hast. Gibt an der Stelle eigentlich nur drei Fehlerquellen:

1. Der Premiere-Key passt nicht. Das wirst du aber sicher schon geprüft. -> Da es mit dem nativen Paket aber geht, sollte das passen.
2. Deine Syno hat keine passende CPU (welches Modell nutzt du denn?). -> Da es mit dem nativen Paket aber geht, sollte das passen.
3. Der Container erkennt das Device nicht oder nicht korrekt.

Ansätze zur Lösung, wenn Punkt 1 und 2 OK sind:

1. via SSH auf der Syno prüfen, ob die Devices auch wirklich zum Container durchgereicht werden

Bash

docker inspect emby ## <--- oder wie der Container bei dir heißt

Hier sollte es nun einen Abschnitt geben, der so aussieht:

XML

"Devices": [
                {
                    "PathOnHost": "/dev/dri",
                    "PathInContainer": "/dev/dri",
                    "CgroupPermissions": "rwm"
                }
            ],

2. in Emby prüfen, ob die Devices korrekt erkannt wurden. Dazu rechts im Baum unter Erweitert -> Protokolle einen Blick in die "hardware_detection-*.txt" werfen (ggf. dafür das Debug-Logging aktivieren und Emby neu starten. Kann danach wieder deaktiviert werden). Dort sollte sich folgendes finden lassen:

XML

"Devices": [
{
"DeviceIndex": 0,
"DeviceInfo": {
"VendorId": 32902,
"DeviceId": 23173,
"SubsytemVendorId": 32902,
"SubsytemDeviceId": 29296,
"DevPath": "/sys/bus/pci/devices/0000:00:02.0",
"DrmCard": "/dev/dri/card0",
"DrmRender": "/dev/dri/renderD128",
"IsEnabled": 1,
"IsBootVga": 1,
"ApiVersionMajor": 1,
"ApiVersionMinor": 7,
"Driver": "Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 (223f94d)"
},

Alles anzeigen

postboy99

Hallo keyboarde,

danke für deine Mühe.
Hier paar Infos dazu:

1. + 2. ist klar, es muss 3. sein.
So sieht es im docker inspec auch aus:

Hier mal ein Vergleich der hardware_detection logs zwischen Emby und Emby_docker:

Docker(4.5.1.0):

Code

"Devices": [
        {
            "DeviceIndex": 0,
            "DeviceInfo": {									  
                "VendorId": 32902,
                "DeviceId": 8881,
                "SubsytemVendorId": 32902,
                "SubsytemDeviceId": 29296,
                "DevPath": "/sys/bus/pci/devices/0000:00:02.0",
                "DrmCard": "/dev/dri/card0",
                "DrmRender": "/dev/dri/renderD128",
                "IsEnabled": 0,
                "IsBootVga": 1,
                "ApiVersionMajor": 1,
                "ApiVersionMinor": 7,
                "Driver": "Intel i965 driver for Intel(R) CherryView - 2.4.0"
            },

Alles anzeigen

NAS(4.5.0.13):

Code

"Devices": [
        {
            "DeviceIndex": 0,
            "DeviceInfo": {
                "VendorName": "Intel Corporation",
                "DeviceName": "Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller",
                "SubsytemVendorName": "Intel Corporation",
                "VendorId": 32902,
                "DeviceId": 8881,
                "SubsytemVendorId": 32902,
                "SubsytemDeviceId": 29296,
                "DevPath": "/sys/bus/pci/devices/0000:00:02.0",
                "DrmCard": "/dev/dri/card0",
                "DrmRender": "/dev/dri/renderD128",
                "IsEnabled": 0,
                "IsBootVga": 1,
                "ApiVersionMajor": 1,
                "ApiVersionMinor": 6,
                "Driver": "Intel i965 driver for Intel(R) CherryView - 2.4.0"
            },

Alles anzeigen

Was mir aber auffällt, eventuell hat es damit was zu tun(auch im hardware_detection.[definition='1','0']log[/definition]):

NAS: "Configuration": "--prefix=/var/packages/EmbyServer/target/ffmpeg --enable-cross-compile --cross-prefix=x86_64-syno-linux-gnu- --target-os=linux ...
Docker: "Configuration": "--cc=x86_64-unknown-linux-gnu-gcc --prefix=/home/embybuilder/Buildbot/x64/ffmpeg-x64/staging ...

Wenn ich ins Docker gehe, finde ich in diesem Ordner kein "/home/embybuilder/Buildbot/x64/ffmpeg-x64/staging":

Code

bash-4.3#   docker exec -it emby2 /bin/bash
root@9e8462adb28b:/# ls -la /home/
total 0
drwxr-xr-x 1 root root   0 Apr 24  2018 .
drwxr-xr-x 1 root root 288 Oct  5 10:39 ..

PS ich hab es zusätzlich noch im Jellyfin Docker getestet, dort gehts.

keyboarder2k

Die Hardware wird also zumindest korrekt erkannt. Dann kann es natürlich noch ein SW-Problem im oder mit dem Docker-Image sein. Aber warum sich das bei uns unterscheiden sollte, ist mir nicht klar. Ich nutze "linuxserver/emby:latest" mit derzeitigem Stand "build_version=Linuxserver.io version:- 5b0118e3-ls54 Build-date:- 2020-09-23T12:10:51-04:00" und daraus resultiert "Emby Version 4.5.1.0".

Ich bin dann mit meinem Docker-Latein auch schon am Ende ... bin da nur User und freue mich, wenn's läuft.

postboy99

Ok danke trotzdem, ich mache mal ein Post im Emby-Forum direkt.

Seger

Ich will mir nicht gleich wieder einen einfangen, aber es hat sich doch auch einiges an der nativen Lösung getan. Neues gemeinsames Laufwerk wird eingerichtet. Alle Dateien und Configeinstellungen sind schnell greifbar. Es kann per SPK installiert werden. Als Pfad kann auch eine SSD ausgewählt werden (Volumen 2 z.B.) und mit dem Backup-Addon kann man es auch jederzeit auf einer anderen Maschine aufsetzen.

gibt es noch irgend einen Docker Vorteil?

postboy99

Zitat von Seger

Ich will mir nicht gleich wieder einen einfangen, aber es hat sich doch auch einiges an der nativen Lösung getan. Neues gemeinsames Laufwerk wird eingerichtet. Alle Dateien und Configeinstellungen sind schnell greifbar. Es kann per SPK installiert werden. Als Pfad kann auch eine SSD ausgewählt werden (Volumen 2 z.B.) und mit dem Backup-Addon kann man es auch jederzeit auf einer anderen Maschine aufsetzen.
gibt es noch irgend einen Docker Vorteil?

Gibt keine großen Vorteile, Docker ist einfach nur übersichtlicher und schnell auf andere Systeme übertragbar.

PS: Ich konnte mein Problem lösen indem ich UID und GID vom root user genommen haben. Ich hatte den user video und mein admin user getestet, ohne Erfolg.
Root User geht.

Commerzpunk

Zitat von Seger

Ich will mir nicht gleich wieder einen einfangen, aber es hat sich doch auch einiges an der nativen Lösung getan. Neues gemeinsames Laufwerk wird eingerichtet. Alle Dateien und Configeinstellungen sind schnell greifbar. Es kann per SPK installiert werden. Als Pfad kann auch eine SSD ausgewählt werden (Volumen 2 z.B.) und mit dem Backup-Addon kann man es auch jederzeit auf einer anderen Maschine aufsetzen.
gibt es noch irgend einen Docker Vorteil?

Wenn mir das native Paketmeine Synology zerballert ist sie zerballert.
Wenn der Docker Containter hochgeht mache ich ihn im größten Notfall grad neu.

Das ist ein riesiger Vorteil.

Emby auf der Synology DS einrichten - Docker vs Nativ und weitere Fragen

Jetzt mitmachen!

Benutzer online in diesem Thema