Kann Jellyfin auf ARM und x86 mit denselben Daten ausgeführt werden?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Can Jellyfin Run on ARM and x86 With the Same Data? - Zima Store Online

In der Regel ja, aber behandeln Sie den Wechsel von ARM zu x86 als kontrollierte Host-Migration und nicht als Beweis dafür, dass jede Jellyfin-Komponente architekturunabhängig ist. Bei aktuellen Jellyfin-Versionen ist ARM64 das relevante ARM-Ziel; auch das x86-Ziel sollte eine unterstützte 64-Bit-Plattform sein. Lassen Sie die Quelle unverändert, bis das Ziel Neustart- und Wiedergabeprüfungen bestanden hat.

Die wichtige Grenze ist der Betrieb: Stoppen Sie die Quelle, bevor Sie den persistenten Zustand kopieren, und lassen Sie niemals zwei Jellyfin-Instanzen auf unterschiedlichen Hosts in dasselbe aktive Datenverzeichnis schreiben. Jellyfin dokumentiert ARM64-zu-x86-64 nicht als speziellen, risikofreien Migrationspfad. Bewahren Sie daher eine Rollback-Kopie auf und erstellen Sie plattformspezifische Komponenten wie FFmpeg-Pakete, Zuordnungen für Hardwarebeschleunigungsgeräte, native Plugin-Abhängigkeiten, Berechtigungen und Host-Pfade separat neu.

Überprüfen Sie, ob die Zielarchitektur tatsächlich unterstützt wird

Bestätigen Sie zunächst, dass das Ziel eine aktuell unterstützte 64-Bit-Jellyfin-Plattform ist. Gehen Sie nicht davon aus, dass ein älteres ARM-Board, ein 32-Bit-Betriebssystem oder ein veralteter x86-Rechner geeignet ist, nur weil Linux darauf noch startet.

Jellyfin 10.11 hat die Unterstützung für ARM32 entfernt, einschließlich armhf, und erfordert auf ARM-Plattformen nun ein ARM64-Betriebssystem. Wenn die Quelle noch einen älteren 32-Bit-ARM-Build ausführt, planen Sie zunächst ein unterstütztes 64-Bit-Ziel, statt die alte Laufzeit als aktuelles Migrationsziel zu behandeln.

Verwenden Sie auf x86 einen unterstützten x86-64-Host, der die Anforderungen der gewünschten Jellyfin-Version erfüllt. Wenn das Ziel auf einem inoffiziellen Paket, einem nicht unterstützten Betriebssystem oder einer veralteten CPU basiert, lösen Sie dieses Plattformproblem, bevor Sie den persistenten Zustand übertragen.

Behandeln Sie gespeicherten Zustand als portabel, die Bereitstellung jedoch als plattformspezifisch

Eine standardmäßige Jellyfin-Bereitstellung speichert den persistenten Serverzustand in ihrer Datenbank sowie in Konfigurations- und Metadatendateien. Bei Installationen mit SQLite ist das Datenbankformat auf dem Datenträger für die Portabilität zwischen Prozessorarchitekturen ausgelegt. Die CPU-Familie allein ist daher kein Grund, die Datenbank vor einer Migration byteweise umzuwandeln.

SQLite beschreibt sein Dateiformat als plattformübergreifendes Datenbankformat, einschließlich der Portabilität zwischen 32- und 64-Bit-Systemen sowie unterschiedlicher Byte-Reihenfolgen. Das unterstützt den Datenbankformat-Teil des Umzugs, garantiert jedoch nicht, dass jedes Jellyfin-Plugin, externe Programm, jeder Treiber oder jeder bereitstellungsspezifische Pfad unverändert funktioniert.

Halten Sie die Unterscheidung klar: Portable gespeicherte Datensätze sind nur eine Ebene. Jellyfin-Versionskompatibilität, vollständige Abdeckung von Daten und Konfiguration, konsistente Medienpfade, Plugin-Abhängigkeiten, Berechtigungen und der Zugriff auf Hardwaregeräte bestimmen weiterhin, ob sich das Ziel wie die Quelle verhält.

Stoppen Sie Jellyfin, bevor Sie den aktiven Zustand übertragen

Für einen kontrollierten Architekturwechsel fahren Sie den Jellyfin-Prozess auf der Quelle herunter, bevor Sie die Migrationskopie erstellen. Dadurch wird verhindert, dass sich eine aktive Datenbank oder ein Write-Ahead-Zustand während des Kopierens ändert, und Sie erhalten einen konsistenten Rollback-Punkt.

Kopieren Sie den vollständigen Daten- und Konfigurationsbereich, statt nur jellyfin.db auszuwählen. Eine unvollständige Kopie kann zwar Benutzer erhalten, aber Konfiguration, Plugins, Metadaten oder andere vom Ziel erwartete Zustände verlieren.

Das gleiche Schutzmodell wie bei einem Backup-Plan mit mehreren Kopien gilt auch hier: Bewahren Sie die Quelle unverändert auf, bis das Ziel eine echte Wiederherstellung und Wiedergabeprüfung bestanden hat.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Erstellen Sie plattformspezifische Komponenten auf dem neuen Host neu

Installieren Sie das native Jellyfin-Paket des Ziels oder verwenden Sie das passende Multi-Arch-Container-Image. Erstellen Sie GPU-Gerätezuordnungen, Gruppenberechtigungen, FFmpeg-Pakete und hostspezifische Pfade neu, statt Binärdateien der alten Architektur zu kopieren.

Überprüfen Sie die Plugins nach dem ersten Start. Plugins, die von nativen Bibliotheken, gebündelten Binärdateien oder externen Programmen abhängen, benötigen möglicherweise einen Build für die neue Architektur. Deaktivieren Sie ein fragliches Plugin bei der ersten Validierung, falls es den Start verhindert, und fügen Sie es erst wieder hinzu, wenn Sie die Kompatibilität bestätigt haben.

Wenn sich die Medienpfade zwischen den Hosts unterscheiden, behalten Sie nach Möglichkeit dieselben Pfade über Mounts bei. Andernfalls planen Sie eine unterstützte Pfadmigration, statt die internen Datenbankeinträge von Jellyfin manuell zu bearbeiten.

Validieren Sie die Migration, bevor die Quelle wiederverwendet wird

Starten Sie ausschließlich die Zielinstanz und bestätigen Sie Benutzer, Bibliotheken, Wiedergabestatus, Grafiken, geplante Aufgaben sowie eine Direct-Play-Wiedergabe und eine erforderliche Transkodierung. Prüfen Sie die Protokolle auf fehlende native Bibliotheken, Berechtigungsfehler oder Pfade, die noch auf den alten Host verweisen.

Starten Sie das Ziel zweimal neu und wiederholen Sie einen Wiedergabetest, damit der Erfolg dauerhaft und nicht nur ein einmaliger Startvorgang ist. Falls das Ziel fehlschlägt, stoppen Sie es und stellen Sie die Migrationskopie wieder her oder kehren Sie zur unveränderten Quelle zurück, anstatt beide Instanzen in denselben Zustand schreiben zu lassen.

Der Umzug ist erst abgeschlossen, wenn der neue Host Neustarts und die normale Nutzung im Haushalt zuverlässig übersteht. Wenn Sie den alten Rechner verfügbar halten möchten, verwenden Sie eine separate wiederhergestellte Kopie oder lassen Sie ihn ausgeschaltet. Verwenden Sie niemals ein einziges aktives Jellyfin-Datenverzeichnis als gemeinsam genutzten Speicher zwischen ARM- und x86-Servern.