Kan Jellyfin köras på ARM och x86 med samma data?

Vanligtvis ja, men behandla ARM-till-x86 som en kontrollerad värdmigrering i stället för ett bevis på att alla Jellyfin-komponenter är arkitekturoberoende. För aktuella Jellyfin-versioner är det relevanta ARM-målet ARM64; en x86-destination bör på samma sätt vara en plattform med stöd för 64 bitar. Behåll källan intakt tills destinationen har klarat omstarts- och uppspelningskontroller.

Den viktiga gränsen är operativ: stoppa källan innan du kopierar beständigt tillstånd, och låt aldrig två Jellyfin-instanser på olika värdar skriva till samma aktiva datakatalog. Jellyfin dokumenterar inte ARM64-till-x86-64 som en särskild migrationsväg utan risk, så spara en återställningskopia och bygg separat om plattformsspecifika delar som FFmpeg-paket, mappningar av enheter för hårdvaruacceleration, inbyggda plugin-beroenden, behörigheter och värdsökvägar.

Verifiera att destinationsarkitekturen faktiskt stöds

Börja med att bekräfta att destinationen är en aktuell Jellyfin-plattform med stöd för 64 bitar. Anta inte att ett äldre ARM-kort, ett 32-bitarsoperativsystem eller en gammal x86-maskin är godtagbar bara för att Linux fortfarande startar på den.

Jellyfin 10.11 tog formellt bort stödet för ARM32, inklusive armhf, och kräver nu ett ARM64-operativsystem på ARM-plattformar. Om källan fortfarande kör en äldre 32-bitars ARM-version bör du först planera för en stödd 64-bitarsdestination i stället för att behandla den gamla körmiljön som ett aktuellt migrationsmål.

På x86 ska du använda en x86-64-värd som stöds och uppfyller kraven för den Jellyfin-version du tänker köra. Om destinationen är beroende av ett inofficiellt paket, ett operativsystem som inte stöds eller en föråldrad processor bör du lösa plattformsproblemet innan du flyttar beständigt tillstånd.

Behandla lagrat tillstånd som portabelt men driftsättningen som plattformsspecifik

En standardinstallation av Jellyfin sparar beständigt servertillstånd i databasen tillsammans med konfigurations- och metadatafiler. För installationer som använder SQLite är databasformatet på disken utformat för att vara portabelt mellan processorarkitekturer, så själva processorarkitekturen är inget skäl att konvertera databasen byte för byte före en migrering.

SQLite beskriver sitt filformat som ett plattformoberoende databasformat, inklusive portabilitet mellan 32- och 64-bitarsystem samt mellan olika byteordningar. Det stöder databasformatdelen av flytten, men garanterar inte att alla Jellyfin-pluginprogram, externa körbara filer, drivrutiner eller driftsättningsspecifika sökvägar fungerar oförändrade.

Håll isär begreppen: portabla lagrade poster är bara ett lager. Kompatibilitet mellan Jellyfin-versioner, fullständig täckning av data och konfiguration, konsekventa mediesökvägar, plugin-beroenden, behörigheter och åtkomst till maskinvaruenheter avgör fortfarande om destinationen fungerar som källan.

Stoppa Jellyfin innan du flyttar det aktiva tillståndet

Vid en kontrollerad arkitekturmigrering ska du stänga av Jellyfin-processen på källan innan du skapar migrationskopian. Det förhindrar att en aktiv databas eller ett skrivförberedande tillstånd ändras medan filer kopieras och ger dig en enhetlig återställningspunkt.

Kopiera hela data- och konfigurationsomfattningen i stället för att bara välja jellyfin.db. En ofullständig kopia kan bevara användare men förlora konfiguration, pluginprogram, metadata eller annat tillstånd som destinationen förväntar sig.

Samma skyddsmodell som används i en säkerhetskopieringsplan med flera kopior gäller här: behåll källan intakt tills destinationen har klarat en verklig återställning och validering av uppspelning.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Bygg om arkitekturspecifika delar på den nya värden

Installera destinationens inbyggda Jellyfin-paket eller använd rätt containeravbildning för flera arkitekturer. Skapa om GPU-enhetsmappningar, gruppbehörigheter, FFmpeg-paket och värdspecifika sökvägar i stället för att kopiera binärfiler från den gamla arkitekturen.

Granska pluginprogrammen efter den första starten. Pluginprogram som är beroende av inbyggda bibliotek, medföljande binärfiler eller externa körbara filer kan kräva en version som motsvarar den nya arkitekturen. Inaktivera ett tveksamt pluginprogram under den första valideringen om det hindrar starten och lägg sedan tillbaka det först när kompatibiliteten har bekräftats.

Om mediesökvägarna skiljer sig mellan värdarna bör du bevara samma sökvägar genom monteringar där det är praktiskt. Annars bör du planera en stödd sökvägsmigrering i stället för att manuellt redigera Jellyfins interna databasposter.

Validera migreringen innan källan används igen

Starta endast destinationsinstansen och bekräfta användare, bibliotek, visningsstatus, bildmaterial, schemalagda uppgifter, en Direct Play-uppspelning och en transkodning som krävs. Kontrollera loggarna efter saknade inbyggda bibliotek, behörighetsfel eller sökvägar som fortfarande hänvisar till den gamla värden.

Starta om destinationen två gånger och upprepa ett uppspelningstest så att resultatet är beständigt och inte bara beror på en lyckad engångsstart. Om destinationen inte fungerar ska du stoppa den och återställa migrationskopian eller återgå till den orörda källan i stället för att låta båda instanserna skriva till samma tillstånd.

Flytten är klar först när den nya värden klarar omstart och normal användning i hemmet. Om du vill behålla den gamla maskinen tillgänglig ska du ge den en separat återställd kopia eller låta den vara avstängd; använd inte en enda aktiv Jellyfin-datakatalog som delad lagring mellan ARM- och x86-servrar.