Show HN: Kyoo – selbst gehosteter Medienbrowser (Jellyfin/Plex-Alternative)

 (github.com/zoriya)
4 Punkte von GN⁺ 2024-04-07 | 1 Kommentare | Auf WhatsApp teilen
  • Kyoo ist ein selbst gehosteter Medienserver mit Fokus auf Videoinhalte wie Filme, Serien und Anime und versteht sich als Alternative zu Jellyfin oder Plex
  • Ziel ist ein Betrieb ohne erzwungene Ordnerstruktur oder manuelle Metadatenbearbeitung; wenn Medien wegen ungewöhnlicher Dateinamen nicht korrekt gescannt werden, gilt das als Bug
  • Funktionen sollen nicht über ein Plugin-System erweitert, sondern als integrierte Funktionen bereitgestellt werden; dazu gehören dynamisches Transcoding, Vorschau-Thumbnails, Intro-/Credit-Erkennung und erweiterte Untertitelunterstützung
  • Derzeit wird als Client das Web unterstützt; Android ist in v5 noch nicht verfügbar, und Unterstützung für iOS und tvOS ist wegen Hardwareanschaffung und jährlichen Entwicklerkosten von etwa $100 derzeit nicht geplant
  • Server-Admins können Dateien aus dem Download-Verzeichnis ohne zusätzliche Sortierung nutzen; Kyoo beschränkt den Umfang auf Videostreaming statt Musik, E-Books oder Spiele

Welches Problem Kyoo lösen will

  • Kyoo ist ein selbst gehosteter Medienserver, der auf Videoinhalte spezialisiert ist
    • Zielinhalte sind Movies, Series und Anime
    • Er wird als Alternative zu Jellyfin oder Plex vorgestellt
  • Ziel ist es, den Wartungsaufwand zu senken
    • Es ist keine bestimmte Ordnerstruktur erforderlich
    • Es ist keine manuelle Metadatenbearbeitung erforderlich
    • Medien sollen auch bei ungewöhnlichen Dateinamen korrekt gescannt werden; schlägt das fehl, wird es als Bug behandelt
  • Ein Plugin-System wird nicht angeboten
    • Funktionen sollen, soweit möglich, integriert sein

Hauptfunktionen

  • Dynamic Transcoding

    • Medien können in die gewünschte Qualität transkodiert werden
    • Durch automatische Qualitätsumschaltung kann die Qualität während der Wiedergabe geändert werden
    • Suchen ist sofort möglich, ohne auf den Transcoder zu warten

  • Video Preview Thumbnails

    • Beim Überfahren der Video-Fortschrittsleiste mit der Maus ist eine Videovorschau sichtbar

  • Intro/Credit detection

    • Intros und Credits werden per Audio-Fingerprinting automatisch erkannt
    • Auch der Abgleich von Kapiteltiteln kann genutzt werden

  • Enhanced Subtitle Support

    • PGS/VODSUB- sowie SSA/ASS-Untertitel werden unterstützt
    • Wenn möglich, werden im Video enthaltene Fonts verwendet

  • Anime Name Parsing

    • Auch komplexe Anime-Dateinamen wie [Some-Stuffs] Jojo's Bizarre Adventure Stone Ocean 24 (1920x1080 Blu-Ray Opus) [2750810F].mkv können zugeordnet werden

  • Helm Chart

    • Es gibt ein offizielles Helm Chart zur Bereitstellung in Kubernetes-Clustern
    • Mehrere Replicas sind in Arbeit

  • OIDC Connection

    • Login ist über OIDC-kompatible Dienste wie Google, Discord und Authelia möglich

Funktionen, die in v5 noch nicht neu implementiert sind

  • Watch List Scrubbing Support

    • Die automatische Synchronisierung von Watchlists mit verbundenen Diensten ist in v5 noch nicht neu implementiert
    • Ziel sind SIMKL und künftig weitere Dienste

  • Download and Offline Support

    • Downloads und Offline-Unterstützung zum Ansehen ohne Internet sind in v5 ebenfalls noch nicht neu implementiert
    • Vorgestellt wird dies als Funktion, die den Fortschritt synchronisiert, sobald das Gerät wieder online ist

Clients und Plattformen

  • Der aktuell unterstützte Client ist Web
  • Der Android-Client ist in v5 noch nicht verfügbar und befindet sich im Status „soon“
  • Weitere Plattformen werden geprüft
  • Das Frontend ist mit React-Native und Expo gebaut
  • Unterstützung für Apple-Geräte ist derzeit nicht geplant
    • Gemeint sind iOS und tvOS
    • Grund sind die Anschaffung von Hardware und jährliche Entwicklerkosten von etwa $100

Unterschiede zu Jellyfin/Plex

  • Jellyfin und Plex werden technisch als auf SQLite angewiesen und als Ansatz beschrieben, bei dem alles in einem einzigen Container liegt
  • Kyoo verfolgt den Ansatz, bei Bedarf zusätzliche Container zu verwenden
    • Als Beispiel wird der transcoder genannt
  • Die Betriebsphilosophie ist „einmal einrichten und vergessen“
    • Es werden keine manuellen Änderungen von Dateinamen verlangt
    • Es wird keine bestimmte Ordnerstruktur verlangt
    • Ziel ist es, Dateien im Download-Verzeichnis unverändert zu nutzen
  • Der Umfang ist auf Streaming von Filmen, TV-Shows und Anime beschränkt
    • Musik, E-Books und Spiele werden nicht abgedeckt

Einstieg und Integrationsressourcen

  • API Documentation: API-Dokumentation zur Integration von Kyoo mit anderen Diensten
  • Join the discord: Discord für Fragen, Entwicklungsdiskussionen, Feature-Requests und Bug-Meldungen
  • weblate: Übersetzungen für Sprachen hinzufügen, die Kyoo noch nicht unterstützt
  • kyoo.zoriya.dev: Bietet eine Live-Demo mit urheberrechtsfreien Filmen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-07
Meinungen auf Hacker News

  • Die Demo ist hübsch und gut gemacht. Als zufriedener Plex-Nutzer, der für Audio Plexamp und für Video die Plex-App auf Apple TV verwendet, habe ich zwar nicht vor zu wechseln, aber ich finde, dass ein Projekt, das als Sandbox-Projekt begann, um interessante Technologien zu lernen, und dann immer weiter gewachsen ist, eine wirklich gute Motivation ist, etwas zu bauen.

    • Wenn man auch Hörbücher hört, lohnt sich ein Blick auf Bookcamp. Mit Plexamp geht das vermutlich auch, aber Bookcamp fühlt sich eher wie Audible an.
    • Mich würde interessieren, wie man Plexamp nutzt. Lädt man Alben herunter und streamt dann von dort, also als Spotify-ähnliche Alternative?
    • Plexamp ist der einzige Grund, der mich weiterhin bei Plex hält.
      Für den Fall, dass Plex irgendwann in die Phase der enshittification eintritt, habe ich Jellyfin parallel eingerichtet, aber die Lifetime-Mitgliedschaft, die ich 2012 gekauft habe, war ihr Geld bisher absolut wert.

  • Ich wollte von Plex zu Jellyfin wechseln, aber Jellyfins größte Einschränkung war für mich, dass es sich offenbar wenig für Bibliotheksverwaltung interessiert und sehr starke Annahmen über die Dateistruktur macht.
    Im Wiki gibt es einen eigenen Abschnitt dazu, wie man Dateien korrekt benennt — etwas, worüber man sich bei Plex keine Gedanken machen muss. Mich würde interessieren, ob Kyoo einen ähnlichen Ansatz verfolgt oder benutzerfreundlicher ist. Plex’ Monetarisierung ist absurd, aber Jellyfin fühlt sich noch nicht bereit für den ernsthaften Einsatz an.

    • Genau das finde ich wirklich seltsam. Kyoos Ziel ist es, die Bibliothek für einen aufzuräumen; man sollte den Download-Ordner direkt als Bibliotheksordner verwenden können, ohne Dateien umzubenennen, und es sollte einfach funktionieren.
      Im Moment gibt es noch Randfälle, vor allem Extras und ähnliche Einträge werden manchmal nicht gut verarbeitet. Aber selbst merkwürdige Anime-Dateinamen wie „[SomeGroup] Jojo's bizzare adventure - golden wings 12.mkv“ werden verarbeitet.
    • Ich frage mich, warum ein Medienserver weniger strikt bei der Struktur sein sollte. Mir gefällt, dass Jellyfin mit ein paar Klicks alles selbst erledigt und ich mir keine Gedanken über die Struktur machen muss.
    • Ich nutze Jellyfin, verwalte die Dateien aber mit TMM (tiny media manager). Jellyfin kommt mit den von TMM erzeugten Ergebnissen ziemlich gut zurecht.
      Ehrlich gesagt würde ich auch gern ein leichtgewichtiges Jellyfin sehen, das überhaupt keinen Medienverwaltungs-Code enthält und nur streamt.
    • Natürlich hängt es von der jeweiligen Umgebung ab, aber Jellyfin unterstützt manuelles Tagging gut genug. Man muss die Ordnerstruktur, die man im Dateibrowser bequem findet, nicht zerstören oder Dateien umbenennen; man klickt bei einer Datei oder einem Ordner einfach auf „Identify“ und sucht in der aktivierten Datenbank nach Titel oder IMDB-Nummer.
      Sobald man einmal festgelegt hat, zu welcher TV-Serie ein Ordner gehört, scheinen die Episoden automatisch erkannt zu werden. Der erste Schritt funktioniert nur dann nicht automatisch, wenn der Ordnername nicht „korrekt“ ist; mit Tiny Media Manager könnte man das vermutlich auch umgehen, indem man massenhaft NFO-Dateien erzeugt.
    • Mich würde interessieren, warum Plex’ Monetarisierung absurd sein soll. Im Vergleich zu Open Source ist ein Premium-Freemium-Modell zwar weniger ideal, aber ich habe vor vier Jahren gern ein lebenslanges Plex-Pass-Abo gekauft und es bis heute kein bisschen bereut.

  • Sieht gut aus. Ich finde es interessant, dass Medienserver-Projekte offenbar besonders zu C# tendieren. Mich würde interessieren, ob es dafür technische Gründe gibt oder ob es eher daran liegt, dass die großen Projekte den Standard gesetzt haben.

    • Der Großteil der verwandten Software, insbesondere die *arr-Familie, ist ebenfalls in .NET geschrieben. Es ist eine Plattform mit ordentlicher Performance, ohne die Developer Experience zu opfern.
    • C# glänzt auf der Webserver-Seite, also ist das nicht ungewöhnlich. Persönlich mag ich es allerdings zunehmend weniger.
      Kyoo verwendet für einige Komponenten auch Python und Go und fürs Frontend TypeScript.
    • Dieses Projekt scheint in mehreren Sprachen geschrieben zu sein. Ich sehe C#, Go, Python, und vermutlich gibt es auch Frontend-Code, aber dagegen bin ich allergisch.

  • Postgres und RabbitMQ beide zu verwenden, wirkt übertrieben. Ich frage mich, ob ein PR akzeptiert würde, der alles auf Postgres vereinheitlicht, um den Betriebsaufwand zu reduzieren.
    Wenn ich wieder am Desktop bin, sollte ich mir ansehen, was RabbitMQ in einem Medienserver genau macht.

    • RabbitMQ wird für die Kommunikation zwischen Diensten verwendet. Es wurde gerade erst eingeführt, soll künftig aber für Websocket-Kommunikation mit Clients, Job-Queues zum Erzeugen neuer Einträge und für Rescan-Anfragen, die Synchronisierung von Watchlists mit externen Diensten sowie die Synchronisierung zwischen mehreren Replikas bei Kubernetes-Deployments genutzt werden.
      Allerdings braucht die Kubernetes-Synchronisierung noch weitere Arbeit.
    • RabbitMQ ist großartig. Es war besonders nützlich, wenn ein Teil eines Programms naturgemäß langsamer ist als andere Teile.
      Es bietet ein sehr robustes und bewährtes Queue-System, ist aber trotzdem leicht zu betreiben. Dadurch kann die Architektur einfach bleiben.

  • Interessantes Projekt. Allerdings frage ich mich bei der Aussage „einfaches Spulen, ohne auf den Transcoder zu warten“.
    Je nach Container und Codec war das immer ein Problem. Mich würde interessieren, wie das gelöst wurde und ob libav nicht verwendet wird.

    • Für kleine Videosegmente wird jeweils ffmpeg gestartet; wenn man zu weit von der aktuellen Transcoding-Position wegspult, wird ein neuer ffmpeg-Prozess erzeugt.
      Der schwierige Teil ist, diese Segmente ohne Unterbrechungen oder Probleme abspielbar zu machen und sicherzustellen, dass sich Audio- oder Videosegmente nicht wiederholen. Wenn genügend Interesse besteht, könnte ich dazu einen ausführlichen Blogpost schreiben.

  • Schade, dass Musik nicht unterstützt wird. Der Hauptgrund, warum ich Plex nutze, ist die Verwaltung meiner Musikbibliothek; selbst bei Plex wirkt Musik eher wie ein Nebenschwerpunkt, aber es ist trotzdem gut genug nutzbar.

  • Vor ein paar Tagen habe ich Jellyfin und tailscale auf einem n100 eingerichtet.
    Lokal lief es gut, aber als ich es per tailscale mit meiner Familie am anderen Ende der Welt geteilt habe, war irgendetwas kaputt. Obwohl die Upload-Geschwindigkeit ausreichend hoch ist, dauerte es etwa eine Minute, bis der Stream startete; vielleicht hat es mit der Latenz zu tun. Ich werde das hier einmal ausprobieren.

    • Ich hatte ein ähnliches Problem. Ich hatte Jellyfin hinter einen Reverse Proxy über WireGuard gesetzt, und bei hoher Latenz, etwa bei Besuchern von einem anderen Kontinent, sprang die Übertragungsrate anfangs noch ordentlich hoch, wurde aber innerhalb weniger Sekunden unbrauchbar langsam. Es hat lange gedauert, das Problem als etwas im Zusammenhang mit Paketstau einzugrenzen.
      Ich empfehle, auf dem Jellyfin- und dem Reverse-Proxy-Server die Standard-Staukontrolle von Linux (net.ipv4.tcp_congestion_control) auf bbr umzustellen. Ich kenne die Details nicht genau, es könnte Nebenwirkungen geben [1], und es gibt vielleicht bessere Congestion-Control-Algorithmen, aber in meinem Fall hat das das Problem vollständig gelöst. Vorher blieb die Verbindung selbst unter ruhigen, optimalen Netzwerkbedingungen bei weniger als 10 %, manchmal sogar bei nur 1 % der Leitungsgeschwindigkeit hängen.
      Außerdem aktiviert Caddy standardmäßig HTTP/3, daher habe ich HTTP/2 erzwungen. Später sollte ich mir wohl auch neuere Versionen von bbr ansehen.
      [1] https://news.ycombinator.com/item?id=37408406

  • Sieht wirklich gut aus. Ich frage mich, ob man auf den Fernseher casten kann. Das ist der einzige Grund, warum ich noch an Plex gebunden bin; ansonsten mag ich Plex nicht.

    • Noch nicht. Das ist eine ziemlich wichtige Funktion, daher plane ich, sie innerhalb der nächsten 6 Monate bereitzustellen, aber vorher möchte ich erst die meisten Client-Funktionen fertigstellen.
    • Casting in Jellyfin war früher ziemlich schlecht, ist aber inzwischen deutlich besser geworden. Ich kann mich gar nicht mehr erinnern, wann ich zuletzt Probleme damit hatte.
    • Man kann es im Browser auf dem Mac öffnen und per AirPlay an Apple TV senden. Unter Windows geht Ähnliches über Cast-Varianten.

  • Angesichts der Richtung, in die Plex geht, ist es schön, mehr Optionen zu haben. Es wäre gut, Hooks zu bauen, die direkt mit SONARR/RADARR verbunden sind, sodass man auf einen Kalendereintrag klicken und direkt zum Player springen kann.
    Wegen rechtlicher Fragen zögern sie vielleicht, das selbst zu bauen, aber es wäre praktisch, Self-Hosting-Medien und Funktionen zur Verwaltung von Raubkopien in einer Oberfläche zu vereinen.

  • Sieht gut aus. Ich habe auf der Demo-Seite ein paar Filme angeklickt und zufällig herumgestöbert, und alles funktionierte perfekt.
    Ich frage mich, wie es mit der Skalierbarkeit aussieht. Ich würde gern wissen, wie viele Nutzer ein einzelner Server bewältigen kann und welche Art von Server nötig ist. Außerdem interessiert mich, worauf die Demo-Seite läuft und ab welcher Nutzerzahl sie überlastet wäre.

    • Die Demo läuft mit dem docker-compose aus dem README auf der Always-Free-Stufe eines Oracle VPS.
      Server-Benchmarks habe ich nicht gemacht, aber der begrenzende Faktor dürfte mit ziemlicher Sicherheit die Encoding-Geschwindigkeit der Maschine sein. Wenn alle Clients gleichzeitig unterschiedliche h265-8K-Filme transcodieren müssen, erfordert das eine völlig andere Größenordnung an GPU-/CPU-Leistung als wenn dieselbe Anzahl von Nutzern direkt abspielt.