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

  • 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. :)

  • 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.

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

    Hardware: Nvidia Shield TV 2017
    Datenquelle: Synology DS1019+
    Datenbank: Emby Server Docker (linuxserver.io) auf der Synology
    KODI: aktuelle 19er via Google Play-Store
    Skin: Embuary
    Video/Sound: via HDMI and Yamaha RX-V685 on Philips 55OLED804
    Remote: Logitech Harmony Elite

  • 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

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

    Nichts desto trotz sind die Images von linuxserver auch spitze.

    NAS: Gehäuse: Jonsbo G3, Mainboard: MSI B460M PRO, CPU: Intel Pentium G6400, OS: OMV 6

    Client: NVIDIA Shield Pro 2019

  • [...] 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. :thumbup:

    Hardware: Nvidia Shield TV 2017
    Datenquelle: Synology DS1019+
    Datenbank: Emby Server Docker (linuxserver.io) auf der Synology
    KODI: aktuelle 19er via Google Play-Store
    Skin: Embuary
    Video/Sound: via HDMI and Yamaha RX-V685 on Philips 55OLED804
    Remote: Logitech Harmony Elite

  • 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

  • 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" :)

    Hardware: Nvidia Shield TV 2017
    Datenquelle: Synology DS1019+
    Datenbank: Emby Server Docker (linuxserver.io) auf der Synology
    KODI: aktuelle 19er via Google Play-Store
    Skin: Embuary
    Video/Sound: via HDMI and Yamaha RX-V685 on Philips 55OLED804
    Remote: Logitech Harmony Elite

  • 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!

  • 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?

    NAS: Gehäuse: Jonsbo G3, Mainboard: MSI B460M PRO, CPU: Intel Pentium G6400, OS: OMV 6

    Client: NVIDIA Shield Pro 2019

  • 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?

  • 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.

    NAS: Gehäuse: Jonsbo G3, Mainboard: MSI B460M PRO, CPU: Intel Pentium G6400, OS: OMV 6

    Client: NVIDIA Shield Pro 2019

  • @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:

    Hardware: Nvidia Shield TV 2017
    Datenquelle: Synology DS1019+
    Datenbank: Emby Server Docker (linuxserver.io) auf der Synology
    KODI: aktuelle 19er via Google Play-Store
    Skin: Embuary
    Video/Sound: via HDMI and Yamaha RX-V685 on Philips 55OLED804
    Remote: Logitech Harmony Elite

    Einmal editiert, zuletzt von keyboarder2k (5. Oktober 2020 um 08:12)

  • 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):

    NAS(4.5.0.13):

    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.

  • 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.

    Hardware: Nvidia Shield TV 2017
    Datenquelle: Synology DS1019+
    Datenbank: Emby Server Docker (linuxserver.io) auf der Synology
    KODI: aktuelle 19er via Google Play-Store
    Skin: Embuary
    Video/Sound: via HDMI and Yamaha RX-V685 on Philips 55OLED804
    Remote: Logitech Harmony Elite

  • 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?

  • 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.

  • 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. :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!