SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor

Jellyfin auf einem VPS installieren und sicher streamen

Betreiben Sie Jellyfin im Docker-Container auf einem VPS: mit Block-Storage, korrekten Dateirechten, Direct Play statt CPU-Transcoding und sicherem Fernzugriff.

Was Sie erstellen

Einen Jellyfin-Medienserver auf einem VPS: einen Container, drei Volumes und eine Block-Storage-Disk mit Ihren Filmen und Serien, erreichbar über jeden Browser und jede Jellyfin-App. Die Installation besteht aus einer Compose-Datei mit 15 Zeilen. Alles, was danach schiefgeht, hat meist eine von zwei Ursachen: Dateiberechtigungen, wegen derer der Container nicht lesen kann, oder der Versuch, einen VPS ohne GPU zum Transkodieren von Videos zu verwenden, für den er nicht ausgelegt ist. Dieser Leitfaden widmet sich deshalb größtenteils diesen beiden Themen. Dort entstehen die meisten Supportanfragen.

Jellyfin ist kostenlos und vollständig Open Source. Es gibt kein Konto, keine kostenpflichtigen Funktionen und keine Telemetrie. Deshalb erscheint Jellyfin auf fast jeder Liste der Dinge, die sich 2026 zum Self-Hosting lohnen. Jellyfin gibt Medien wieder, die Sie besitzen. Jellyfin liefert keine Inhalte mit. In diesem Leitfaden geht es nicht um die Beschaffung solcher Inhalte.

Die Realität beim Transcoding, bevor Sie etwas mieten

Lesen Sie diesen Abschnitt zuerst, weil er Ihre Kaufentscheidung beeinflusst. Ein Media-Server führt beim Start der Wiedergabe eine von zwei Aktionen aus. Direct Play überträgt die Datei unverändert: Der VPS liest die Bytes vom Datenträger und sendet sie über das Netzwerk. Das benötigt fast keine CPU-Leistung. Transcoding codiert das Video während der Wiedergabe neu, beispielsweise mit einer anderen Auflösung oder einem anderen Codec oder mit fest ins Bild eingebrannten Untertiteln. Das ist reine CPU-Arbeit.

Ein typischer VPS hat keine GPU. Daher läuft jedes Video-Transcoding auf der CPU mit libx264/libx265, und Software-Encoding benötigt viel Rechenleistung. Schon ein einzelner 1080p-H.264-Transcoding-Vorgang kann mehrere gemeinsam genutzte vCPUs vollständig auslasten. Ein 4K- oder HEVC-Transcoding-Vorgang kann die Echtzeitwiedergabe in der Regel überhaupt nicht aufrechterhalten. Die Wiedergabe stockt dann und puffert dauerhaft. Hardware-Transcoding, das auf einem Heimserver mit einer Intel-iGPU oder einer Nvidia-Grafikkarte für geringe Kosten sorgt, steht Ihnen nicht zur Verfügung, sofern Ihr Provider keine GPU-Instanzen vermietet.

Die Strategie auf einem VPS lautet daher: Vermeiden Sie Transcoding. Speichern Sie Ihre Bibliothek in Codecs, die Ihre Clients nativ wiedergeben können: H.264-Video, AAC- oder AC3-Audio in einem MP4- oder MKV-Container. Verwenden Sie Client-Apps mit Direct Play: die nativen Jellyfin-Apps für Android TV, iOS und Roku sowie Infuse, Kodi und den Jellyfin Media Player für Desktop-Systeme. Dann muss der VPS während der Wiedergabe kein ffmpeg-Transcoding ausführen, und ein System mit 2 vCPUs kann gleichzeitig an mehrere Personen streamen. Wenn Sie Transcoding einplanen, benötigen Sie ein deutlich größeres und teureres System. Selbst dann ist 4K keine zuverlässige Option.

Berechnen Sie auch den Bandbreitenbedarf. Direct Play überträgt die Datei mit ihrer eigenen Bitrate. Eine komprimierte 1080p-Datei benötigt 8-12 Mbps. Ein 1080p-Blu-ray-Remux benötigt 20-30 Mbps. 4K HDR benötigt 40-80 Mbps. Drei Personen, die Dateien mit jeweils 10 Mbps per Direct Play wiedergeben, erzeugen auf Ihrem VPS einen anhaltenden Upload von 30 Mbps. Prüfen Sie in Ihrem Tarif zwei Werte: die Portgeschwindigkeit, also ob der VPS 30 Mbps im Upload übertragen kann, und das monatliche Transferlimit. Ein zweistündiger Film mit 10 Mbps erzeugt etwa 9 GB ausgehenden Datenverkehr. Ein limitiertes Kontingent von 1 TB pro Monat reicht daher für etwas mehr als hundert solcher Filme pro Monat, also für drei oder vier pro Tag. Ein Haushalt, der 4K-Inhalte mit der vier- bis achtfachen Bitrate ansieht, verbraucht das Kontingent deutlich schneller. Berücksichtigen Sie auch alle anderen Daten, die über denselben Server übertragen werden, einschließlich eines selbst gehosteten RustDesk-Relays. Dieses überträgt eine vollständige Remote-Desktop-Sitzung, wenn zwei Peers keine direkte Verbindung herstellen können.

Voraussetzungen

  • Ein frischer Ubuntu-24.04-KVM-VPS mit root- oder sudo-Zugriff sowie installiertem Docker und Compose-Plugin.
  • Ein Block-Storage-Volume für die Medien, dessen Größe an Ihre Bibliothek angepasst ist (siehe Größenplanung unten). Auf dem kleinen Root-Datenträger eines VPS sollten Ihre Filme nicht gespeichert werden.
  • Ein Domainname, wenn Sie öffentlichen HTTPS-Zugriff benötigen, oder ein WireGuard-VPN auf demselben VPS, wenn Sie das gesamte System lieber privat halten möchten.
  • Medien, die Sie rechtmäßig streamen dürfen, eigene Rips, eigene Aufnahmen und Dateien, deren Eigentümer Sie sind.

Blockspeicher zuerst einbinden

Binden Sie das Volume im Panel Ihres Providers an. Ermitteln Sie es anschließend und hängen Sie es ein. Den Gerätenamen finden Sie mit lsblk. Er sieht beispielsweise wie /dev/sdb oder /dev/vdb aus. Es handelt sich dabei niemals um das Root-Laufwerk.

lsblk
sudo mkfs.ext4 /dev/sdb          # ONLY on a new, empty volume: this ERASES it
sudo mkdir -p /mnt/media
sudo blkid /dev/sdb              # copy the UUID shown for this device

Binden Sie das Volume über die UUID ein, nicht über /dev/sdb. Die Gerätebezeichnungen können sich nach einem Reboot ändern. Andernfalls kann das falsche Laufwerk formatiert oder eingebunden werden. Fügen Sie eine Zeile zu /etc/fstab hinzu:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /mnt/media  ext4  defaults,nofail  0  2
sudo mount -a
df -h /mnt/media

nofail ist wichtig. Ohne diese Option startet der Server nicht mehr und wechselt in eine Emergency Shell, wenn das Block-Volume einmal getrennt wurde. Der schwerwiegendste Fehler besteht darin, mkfs.ext4 auf einem Volume auszuführen, das bereits Daten enthält. Dabei werden die Daten gelöscht. Formatieren Sie nur neue Volumes. Wenn sich Ihre Bibliothek bereits auf dem Laufwerk befindet, fahren Sie direkt mit der Zeile für fstab fort.

Medien so anordnen, wie Jellyfin sie erwartet

Jellyfin ordnet Metadaten anhand von Ordner- und Dateinamen zu. Bei einer falschen Struktur werden Filme als Dateien ohne Titel und Poster eingelesen, oder eine Folge wird der falschen Serie zugeordnet. Vier Konventionen decken fast alle Fälle ab: Jeder Film liegt in einem eigenen Ordner mit übereinstimmendem Dateinamen und wird als Name (Year) benannt (Jellyfin behandelt das Jahr als optional, die Zuordnung wird dadurch aber deutlich zuverlässiger); Staffelordner werden als Season 01 und nicht als S01 benannt; Episodendateien verwenden S01E01; und Specials gehören in Season 00.

/mnt/media
├── Movies
│   ├── Blade Runner (1982)
│   │   └── Blade Runner (1982).mkv
│   └── Arrival (2016)
│       └── Arrival (2016).mkv
└── Shows
    └── Severance (2022)
        ├── Season 01
        │   ├── Severance - S01E01.mkv
        │   └── Severance - S01E02.mkv
        └── Season 00
            └── Severance - The Lexington Letter.mkv

Das (Year) bei Filmen ist keine reine Dekoration. Es unterscheidet Remakes, damit der Matcher den richtigen Titel auswählt. Halten Sie Movies und Shows als separate Ordner auf oberster Ebene vor, da jeder Ordner zu einer Jellyfin-Mediathek eines bestimmten Inhaltstyps wird. Eine Mischung verwirrt den Metadatenanbieter. Jellyfin kann problemlos einen dritten Ordner mit Fotos indizieren. Die Fotoverwaltung ist dort im Vergleich zu einem spezialisierten Fotoserver jedoch eingeschränkt. Wenn Ihre Alben wichtig sind, geben Sie ihnen ein eigenes System mit PhotoPrism oder Immich und verwenden Sie dieses System nur für Filme und Serien.

Berechtigungen: Der häufigste Grund für leere Bibliotheken

Hier liegt ein verbreitetes Missverständnis vor, das schnell einen ganzen Abend kostet. Das offizielle jellyfin/jellyfin-Image berücksichtigt die Umgebungsvariablen PUID und PGID nicht. Diese gehören zum LinuxServer.io-Image (lscr.io/linuxserver/jellyfin). Beim offiziellen Image legen Sie den Benutzer mit dem Schlüssel user: in Compose fest. Wenn Sie ihn weglassen, läuft der Container als root. Unabhängig vom verwendeten Image gilt dieselbe Regel: Die uid/gid, unter der der Container läuft, muss jedes Medienverzeichnis lesen und durchlaufen können.

Wir verwenden die uid/gid 1000, also den ersten Benutzer ohne root-Berechtigungen auf einem unveränderten Ubuntu-System. Ermitteln Sie Ihre Werte und setzen Sie den Besitz:

id                                  # confirm your user is uid=1000 gid=1000
sudo chown -R 1000:1000 /mnt/media
sudo find /mnt/media -type d -exec chmod 755 {} \;
sudo find /mnt/media -type f -exec chmod 644 {} \;
mkdir -p ~/jellyfin/config ~/jellyfin/cache
sudo chown -R 1000:1000 ~/jellyfin

Verzeichnisse benötigen das Bit execute (das x in 755), nicht nur Leserechte. Ohne dieses Bit kann der Container das Verzeichnis nicht betreten, obwohl er dessen Namen auflisten kann. Die Ursache für eine vollständig leere Bibliothek ist häufig das übergeordnete Verzeichnis: Wenn die uid des Containers den Mount selbst nicht durchlaufen kann, erreicht sie /media/Movies oder /media/Shows nicht. Dann bleibt jede Bibliothek auf einmal leer, und im Log erscheint Access to the path ... is denied. Jedes einzelne Medienverzeichnis, das der Container nicht lesen kann, wird protokolliert und übersprungen. Eine Gruppe von Dateien, die als root kopiert wurde, verschwindet daher scheinbar still aus der Bibliothek. Deshalb ändern wir den Besitz rekursiv und setzen das execute-Bit für jedes Verzeichnis, statt nur ein einzelnes Verzeichnis zu korrigieren.

Die docker-compose-Datei

services:
  jellyfin:
    image: jellyfin/jellyfin:12
    container_name: jellyfin
    user: "1000:1000"
    restart: unless-stopped
    ports:
      - "127.0.0.1:8096:8096"
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /mnt/media:/media:ro
    environment:
      - JELLYFIN_PublishedServerUrl=https://jellyfin.example.com

Zeile für Zeile: jellyfin/jellyfin:12 verfolgt den aktuellen 12.x-Release-Zweig (12.2 am 2026-10-10). user: "1000:1000" legt die UID/GID fest, unter der der Jellyfin-Prozess ausgeführt wird. Dadurch werden weder Eigentümer noch Modus einer Datei geändert, da Docker bei eingebundenen Verzeichnissen die UID/GID des Hosts beibehält. Deshalb muss chown dem oben genannten Wert entsprechen. /config enthält den gesamten Server, Konten, Bibliotheken, Metadaten und den Wiedergabestatus. Das Verzeichnis muss daher beschreibbar sein und ist der Inhalt, den Sie sichern. /cache ist temporärer Arbeitsbereich. Das Medienverzeichnis wird absichtlich als :ro (schreibgeschützt) eingebunden: Jellyfin speichert Grafiken und Metadaten standardmäßig unter /config. Daher muss Jellyfin nie in Ihre Bibliothek schreiben. Der Schreibschutz schützt Ihre Dateien außerdem vor versehentlichem Löschen oder einem fehlerhaften Plugin. Der Port wird absichtlich an 127.0.0.1 gebunden. Die Webanmeldung von Jellyfin verwendet unverschlüsseltes HTTP. Deshalb veröffentlichen wir Port 8096 nie im öffentlichen Internet. JELLYFIN_PublishedServerUrl ist die Adresse, die der Server für die lokale automatische Erkennung bekannt gibt, also ein UDP-Broadcast im LAN. Clients im Internet sehen diese Adresse daher nicht und verwenden einfach die URL, die Sie in der App eingeben. Legen Sie die Adresse fest, die den Clients mitgeteilt werden soll. Auf entfernten Geräten müssen Sie diese URL voraussichtlich manuell eingeben.

Starten Sie den Stack aus dem Compose-Verzeichnis:

docker compose up -d
docker logs -f jellyfin

Erster Start: der Einrichtungsassistent und Ihre Mediatheken

Da der Port nur an localhost gebunden ist, greifen Sie über einen SSH-Tunnel von Ihrem Laptop auf den Assistenten zu, anstatt eine Lücke in der Firewall zu öffnen:

ssh -L 8096:127.0.0.1:8096 you@your-vps-ip

Rufen Sie nun http://localhost:8096 auf. Der Assistent führt Sie zunächst durch die Sprachauswahl und anschließend durch das Anlegen eines Administratorkontos mit einem starken Passwort. Dieses Konto verwaltet Ihren Server. Verwenden Sie daher kein Wegwerfpasswort erneut. Fügen Sie Ihre erste Mediathek hinzu: Wählen Sie als Inhaltstyp Movies, verweisen Sie auf /media/Movies (den Pfad innerhalb des Containers, nicht den Hostpfad), und wiederholen Sie den Vorgang mit Shows und /media/Shows. Schließen Sie den Assistenten ab. Jellyfin beginnt anschließend mit dem Scan. Bei einer kleinen Mediathek sollten innerhalb von ein bis zwei Minuten Poster und Titel angezeigt werden. Später können Sie Mediatheken unter Dashboard → Libraries hinzufügen oder bearbeiten. Mit Scan All Libraries erzwingen Sie einen erneuten Scan. Diese Poster machen auch ein alternatives Frontend interessant, sobald die Grundlagen funktionieren, denn Halcyon baut aus den bereits von Jellyfin abgerufenen Bildern dieselbe Mediathek als begehbare Videothek der 90er-Jahre neu auf.

Wenn Sie überhaupt eine Transcodierung verwenden, öffnen Sie Dashboard → Playback → Transcoding und setzen den temporären Transcodierungspfad auf /cache/transcodes. Dadurch werden die temporären Daten auf dem Cache-Volume abgelegt, statt /config aufzublähen. Lassen Sie die Hardwarebeschleunigung auf None eingestellt, da keine GPU für die Beschleunigung vorhanden ist.

Remote-Zugriff: TLS-Reverse-Proxy oder Zugriff über das VPN

Sie haben zwei sichere Möglichkeiten, Jellyfin von außerhalb zu erreichen. Eine unsichere Möglichkeit sollten Sie vermeiden. Die unsichere Variante besteht darin, Port 8096 direkt im Internet zu veröffentlichen: Die Anmeldung wird im Klartext übertragen, und der Port wird innerhalb weniger Stunden durch Brute-Force-Angriffe angegriffen.

Option A, TLS-Reverse-Proxy. Binden Sie Jellyfin über eine Subdomain hinter Traefik mit automatischem TLS für Ihre Docker-Anwendungen ein oder verwenden Sie nginx mit einem von Certbot ausgestellten Let's-Encrypt-Zertifikat. Jellyfin verwendet WebSockets für Echtzeitaktualisierungen. Der Proxy muss daher die Upgrade-Header weiterleiten. Traefik erledigt das automatisch. Bei nginx müssen Sie diese Header ausdrücklich konfigurieren. Außerdem muss die Verbindung zum Upstream HTTP/1.1 verwenden, sonst findet das Upgrade nicht statt:

location / {
    proxy_pass http://127.0.0.1:8096;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Setzen Sie JELLYFIN_PublishedServerUrl auf die Adresse von https://. Dadurch kündigt jede lokale automatische Erkennung die richtige URL an. Remote-Anwendungen verwenden die von Ihnen angegebene Adresse. Fügen Sie außerdem fail2ban zum Verlangsamen von Brute-Force-Versuchen gegen die Anmeldung hinzu. Sobald der Server öffentlich erreichbar ist, überwachen Sie die URL mit Uptime Kuma. So erfahren Sie von einem Ausfall, bevor Ihre Zuschauer ihn bemerken. Richten Sie die Benachrichtigungen auf einen selbst gehosteten ntfy-Server aus. Bei einer fehlgeschlagenen Prüfung erhalten Sie dann eine Push-Benachrichtigung auf dem Telefon statt einer E-Mail, die Sie erst am nächsten Morgen lesen. Eine Anmeldung im öffentlichen Internet ist außerdem ein guter Zeitpunkt, um den restlichen Server zu prüfen. Verlassen Sie sich nicht darauf, dass nur Port 443 erreichbar ist: sudo ss -tlnp listet jeden lauschenden Port und den zugehörigen Prozess auf. Wenn Sie auf dem Server auch eigenen Code bereitstellen, scannt open-kritt Repositories und deren Abhängigkeiten auf Schwachstellen. Das Tool prüft den Quellcode, nicht lauschende Ports.

Option B, privat über ein VPN betreiben. Veröffentlichen Sie Port 8096 überhaupt nicht im öffentlichen Internet. Greifen Sie nur über einen WireGuard-Tunnel auf Jellyfin zu, der auf demselben Server endet. Für einen Haushalt ist dies die einfachste sichere Lösung: kein Zertifikat, keine öffentliche Erreichbarkeit und keine Angriffsfläche für Brute-Force-Versuche. Das Binden an localhost aus der Compose-Datei reicht hier allein nicht aus. Ein auf 127.0.0.1 veröffentlichter Port ist nur vom VPS selbst erreichbar, nicht von VPN-Peers. Veröffentlichen Sie den Port stattdessen auf der Tunneladresse des Servers, beispielsweise "10.8.0.1:8096:8096", wobei Sie die eigene WireGuard-Server-IP verwenden. Alternativ können Sie localhost beibehalten und davor einen Proxy setzen, der auf der Tunneladresse lauscht. Verbinden Sie sich anschließend über das VPN. Einzelheiten zum Tunnel finden Sie unter WireGuard-VPN-Einrichtung für einen privaten VPS.

Speicherplanung und Backups

Planen Sie nach Qualität, nicht nach Dateianzahl. Komprimierte 1080p-Filme benötigen jeweils 4-15 GB, ein 1080p-Remux 20-40 GB, eine Staffel in 1080p 15-40 GB. 4K-Inhalte benötigen 40-100 GB pro Film. Eine Bibliothek mit einigen hundert Filmen und mehreren Serien benötigt ein Volume mit 2-4 TB. Es ist günstiger, das Block-Volume einmal großzügig zu dimensionieren, als später eine Migration durchzuführen.

/config enthält den vollständigen Serverstatus. Daher müssen Sie genau diesen sichern. Erstellen Sie einen Snapshot oder stoppen Sie den Dienst und packen Sie die Daten mit tar. Bewahren Sie die Kopie außerhalb des Servers auf:

docker compose down
sudo tar czf jellyfin-config-$(date +%F).tgz -C ~/jellyfin config
docker compose up -d

/cache und der Transcode-Ordner können jederzeit neu erstellt werden. Die Medien auf /mnt/media sichern Sie separat oder akzeptieren, dass Sie sie bei Bedarf erneut rippen müssen. Angesichts der Größe entscheiden sich die meisten für die zweite Option. Upgrades erfolgen über docker compose pull && docker compose up -d. Der Tag :12 bleibt dabei innerhalb der 12.x-Linie. Der Wechsel zur nächsten Hauptversion erfordert daher eine gezielte Änderung des Tags. Lesen Sie vorher die Jellyfin-Release-Notes, weil bei Hauptversionen Migrationen des Bibliotheksschemas stattfinden. Jellyfin hat mit 12.0 die führende Zeichenfolge "10." aus den Versionsnummern entfernt (September 2026): 12.0 entspricht der früheren Version 10.12. Eine 11.x-Linie gibt es nicht. 10.11.x war die letzte Linie nach dem alten Schema. Wenn Ihre ältere Compose-Datei noch jellyfin/jellyfin:10 enthält, bleibt sie auf 10.11 eingefroren. Dieser Tag wurde zuletzt am 2026-06-06 auf 10.11.11 geändert und wird niemals 12.x abrufen. Die Änderung auf :12 ist mehr als eine reine Tag-Änderung: 12.0 ändert das Datenbankschema und schreibt die Daten beim ersten Start neu. Stoppen Sie den Server daher vorher und erstellen Sie zunächst das oben beschriebene Backup. Nur dieses Backup ermöglicht eine Rückkehr. 12.0 kann direkt von 10.10.7 oder jeder 10.11.x-Version aktualisiert werden. Danach ist ein vollständiger Scan der Bibliothek erforderlich. Dieser dauert deutlich länger als gewöhnlich. Ein festgelegter Tag plus ein gesichertes Statusverzeichnis ist das vollständige Vorgehen für jeden dauerhaft laufenden Container. Dasselbe Muster sorgt dafür, dass der Status und die Zeitpläne eines selbst gehosteten Agents über Reboots hinweg erhalten bleiben.

Fehlerbilder mit den angezeigten Meldungen

Die Bibliothek ist nach einem Scan leer. Das Protokoll unter Dashboard → Logs (oder ~/jellyfin/config/log/log_*.log) zeigt:

System.UnauthorizedAccessException: Access to the path '/media/Movies' is denied.

Die Container-UID kann diesen Pfad nicht lesen. Ursache sind Medien, die root oder einer anderen UID als dem Wert user: gehören, ein Verzeichnis ohne Ausführungsbit oder ein übergeordneter Mount, der für diese UID selbst nicht durchquerbar ist. Beheben Sie das mit chown -R 1000:1000 /mnt/media, setzen Sie für Verzeichnisse 755 und für Dateien 644. Führen Sie anschließend den Scan erneut aus.

Bei der Wiedergabe ist die CPU-Auslastung sehr hoch und die Wiedergabe puffert. docker stats jellyfin zeigt eine CPU-Auslastung nahe 100% multipliziert mit der Anzahl Ihrer Kerne. Unter Dashboard → Playback wird die Sitzung als Transcode mit einer Geschwindigkeit unter 1.0x angezeigt. Der Client gibt die Datei nicht direkt wieder. Der VPS transcodiert daher per CPU langsamer als in Echtzeit und fällt zurück. Ursache sind ein nicht unterstützter Codec oder Container, das Einbrennen von Untertiteln oder HDR-Tonemapping. Wechseln Sie zu einem Client mit Direct Play. Verwenden Sie Quellen in H.264/AAC. Verwenden Sie text-Untertitel (SRT) statt image-Untertiteln (PGS/VOBSUB). Die meisten Jellyfin-Clients können Bilduntertitel nicht selbst darstellen und erzwingen deshalb ein Einbrennen. Verwenden Sie 4K-HDR auf einem System ohne GPU-Transcoding grundsätzlich nicht.

„Keine kompatiblen Streams verfügbar.“ Die vollständige Meldung lautet meist: „Dieser Client ist mit den Medien nicht kompatibel, und der Server sendet kein kompatibles Medienformat.“ Der Client hat die Quelle abgelehnt, und auch das Fallback-Transcoding konnte nicht gestartet werden. Ursache sind ein fehlerhafter ffmpeg-Befehl, eine nicht lesbare Datei oder ein Benutzerprofil, das die Videokonvertierung blockiert. Lesen Sie die ffmpeg-Zeile unter Dashboard → Logs. Prüfen Sie, ob die Datei überhaupt wiedergegeben werden kann. Prüfen Sie die Wiedergabeberechtigungen des Benutzers, wenn Sie auf Transcoding angewiesen sind. Testen Sie außerdem einen zweiten Client, um Codec-Eigenheiten des Browsers auszuschließen.

Filme haben kein Poster oder das falsche Poster. Die Metadaten wurden nicht korrekt zugeordnet. Ursache sind ein Ordner- oder Dateiname, der nicht mit dem Titel übereinstimmt, unter dem Ihr Metadatenanbieter ihn führt, ein Remake oder ein allgemeiner Titel ohne Jahreszahl zur Unterscheidung der Versionen, ein nach S01 statt nach Season 01 benannter Staffelordner oder Episoden, die nicht dem Format S01E01 entsprechen. Benennen Sie die Dateien entsprechend der oben beschriebenen Struktur um. Wählen Sie anschließend Refresh metadata → Replace all. Alternativ können Sie bei einem einzelnen Eintrag Identify verwenden, um den richtigen TMDB-/TVDB-Eintrag festzulegen.

FAQ

Kann ein VPS Videos ohne GPU transkodieren?

Ja, aber dann ausschließlich über die CPU, und das ist ressourcenintensiv. Ein einzelner 1080p-Software-Transkodierungsvorgang kann mehrere vCPUs vollständig auslasten. 4K oder HEVC kann meist nicht in Echtzeit verarbeitet werden, sodass die Wiedergabe puffert. Am besten vermeiden Sie die Transkodierung: Halten Sie Ihre Bibliothek in H.264/AAC vor und verwenden Sie Client-Apps mit Direct Play. Dann streamt der VPS lediglich Daten. Mieten Sie nur dann eine GPU-Instanz, wenn Sie tatsächlich Transkodierung während der Wiedergabe benötigen.

Warum ist meine Jellyfin-Bibliothek nach einem Scan leer?

Fast immer sind fehlende Berechtigungen die Ursache. Das offizielle jellyfin/jellyfin-Image läuft mit dem von Ihnen gesetzten user: oder als root. Wenn dieser Benutzer die Dateien nicht lesen kann, protokolliert der Scan Access to the path ... is denied und überspringt die Dateien. Korrigieren Sie den Eigentümer mit chown -R 1000:1000 /mnt/media, setzen Sie für Verzeichnisse das Execute-Bit mit 755 und starten Sie den Scan erneut. Prüfen Sie auch das übergeordnete Verzeichnis. Wenn die Benutzer-ID des Containers /mnt/media selbst nicht durchlaufen kann, erreicht sie die Bibliotheksverzeichnisse nicht und die Bibliothek bleibt vollständig leer. Die zweithäufigste Ursache ist eine Verzeichnisstruktur, die nicht den Erwartungen von Jellyfin entspricht.

Wie greife ich remote und sicher auf Jellyfin zu?

Es gibt zwei gute Optionen. Betreiben Sie Jellyfin hinter einem TLS-Reverse-Proxy auf einer Subdomain. Dadurch werden Anmeldung und Stream verschlüsselt. Ergänzen Sie fail2ban. Veröffentlichen Sie niemals den unverschlüsselten Port 8096, da er Ihr Passwort im Klartext überträgt. Alternativ können Sie Jellyfin vollständig privat halten und ausschließlich über ein VPN darauf zugreifen. Für einen Haushalt ist das die einfachste sichere Lösung. Konfigurieren Sie die Apps direkt mit der öffentlichen Adresse. Autodiscovery verwendet einen Broadcast im lokalen Netzwerk und erreicht daher keine Clients, die über das Internet zugreifen.

Wie viel Speicherplatz und Bandbreite benötigt ein Jellyfin-VPS?

Der Speicherbedarf hängt von der Qualität ab: Planen Sie 4-15 GB pro komprimiertem 1080p-Film, 20-40 GB pro Remux und 40-100 GB für 4K ein. Die meisten Bibliotheken benötigen daher ein Block-Volume mit 2-4 TB. Der Bandbreitenbedarf wird durch die Bitrate von Direct Play bestimmt: 8-12 Mbps pro 1080p-Stream und deutlich mehr für 4K. Prüfen Sie daher, ob die Portgeschwindigkeit für die Anzahl gleichzeitiger Zuschauer ausreicht, und behalten Sie das monatliche Transfervolumen im Blick. Planen Sie Transkodierung ein, benötigen Sie zusätzliche CPU-Reserven. Bei Direct Play sollten Sie der Bandbreite gegenüber zusätzlichen Kernen den Vorrang geben.

Jellyfin selbst ist freie Open-Source-Software. Sein Betrieb ist vollständig legal. Entscheidend ist der Inhalt: Streamen Sie nur Medien, die Ihnen gehören oder für deren Nutzung Sie eine Lizenz besitzen. Dazu gehören eigene Disc-Rips, Aufnahmen oder Dateien, zu deren Nutzung Sie berechtigt sind. Jellyfin enthält keine Medien und bietet keine Möglichkeit, Medien zu beziehen. Es ist ein Player für eine Bibliothek, die Sie bereits besitzen.