Kan Jellyfin op ARM en x86 draaien met dezelfde gegevens?

Meestal wel, maar behandel ARM-naar-x86 als een gecontroleerde hostmigratie en niet als bewijs dat elk Jellyfin-onderdeel architectuuronafhankelijk is. Voor huidige Jellyfin-releases is ARM64 het relevante ARM-doelplatform; ook een x86-doel moet een ondersteund 64-bitsplatform zijn. Houd de bron intact totdat het doel herstarts en afspeeltests heeft doorstaan.

De belangrijke grens is operationeel: stop de bron voordat je persistente gegevens kopieert en laat nooit twee Jellyfin-instanties op verschillende hosts dezelfde actieve gegevensmap beschrijven. Jellyfin documenteert ARM64-naar-x86-64 niet als een speciale migratieroute zonder risico. Bewaar daarom een terugrolkopie en bouw platformspecifieke onderdelen afzonderlijk opnieuw op, zoals FFmpeg-pakketten, apparaatkoppelingen voor hardwareversnelling, systeemeigen plug-inafhankelijkheden, machtigingen en hostpaden.

Controleer of de architectuur van het doel daadwerkelijk wordt ondersteund

Begin met te controleren of het doel een momenteel ondersteund 64-bits Jellyfin-platform is. Ga er niet van uit dat een oudere ARM-kaart, een 32-bits besturingssysteem of een verouderde x86-machine geschikt is, alleen omdat Linux er nog op opstart.

Jellyfin 10.11 heeft formeel ondersteuning voor ARM32 verwijderd, waaronder armhf, en vereist nu een ARM64-besturingssysteem op ARM-platforms. Als de bron nog een oudere 32-bits ARM-build gebruikt, plan dan eerst een ondersteund 64-bitsdoel in plaats van de oude runtime als huidig migratiedoel te behandelen.

Gebruik op x86 een ondersteunde x86-64-host die voldoet aan de vereisten van de Jellyfin-versie die je wilt uitvoeren. Als het doel afhankelijk is van een onofficieel pakket, een niet-ondersteund besturingssysteem of een verouderde CPU, los dat platformprobleem dan op voordat je persistente gegevens verplaatst.

Behandel opgeslagen status als overdraagbaar, maar de implementatie als platformspecifiek

Een standaard Jellyfin-implementatie bewaart persistente serverstatus in de database, samen met configuratie- en metadatabestanden. Bij installaties die SQLite gebruiken, is de database-indeling op schijf ontworpen om overdraagbaar te zijn tussen processorarchitecturen. Alleen het verschil in CPU-familie is dus geen reden om de database vóór een migratie byte voor byte om te zetten.

SQLite beschrijft de bestandsindeling als een platformonafhankelijke database-indeling, inclusief overdraagbaarheid tussen 32-bits- en 64-bitssystemen en verschillende bytevolgorden. Dat ondersteunt het databasegedeelte van de migratie, maar garandeert niet dat elke Jellyfin-plug-in, elk extern uitvoerbaar bestand, elke driver of elk implementatiespecifiek pad ongewijzigd blijft werken.

Houd het onderscheid duidelijk: overdraagbare opgeslagen records vormen slechts één laag. Compatibiliteit van de Jellyfin-versie, volledige dekking van gegevens en configuratie, consistentie van mediapaden, plug-inafhankelijkheden, machtigingen en toegang tot hardwareapparaten bepalen nog steeds of het doel zich gedraagt als de bron.

Stop Jellyfin voordat je de actieve status verplaatst

Schakel voor een gecontroleerde architectuurmigratie het Jellyfin-proces op de bron uit voordat je de migratiekopie maakt. Zo voorkom je dat een actieve database of write-ahead-status verandert terwijl bestanden worden gekopieerd en heb je één consistent terugrolpunt.

Kopieer het volledige bereik van gegevens en configuratie in plaats van alleen jellyfin.db te selecteren. Een gedeeltelijke kopie kan gebruikers behouden, maar configuratie, plug-ins, metadata of andere status verliezen die het doel verwacht.

Hetzelfde beschermingsmodel als bij een back-upplan met meerdere kopieën geldt hier: houd de bron intact totdat het doel een echte herstel- en afspeelvalidatie heeft doorstaan.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Bouw architectuurspecifieke onderdelen opnieuw op de nieuwe host

Installeer het systeemeigen Jellyfin-pakket van het doel of gebruik de juiste multi-architectuurcontainerimage. Maak GPU-apparaatkoppelingen, groepsmachtigingen, FFmpeg-pakketten en hostspecifieke paden opnieuw aan in plaats van binaire bestanden van de oude architectuur te kopiëren.

Controleer de plug-ins na de eerste start. Plug-ins die afhankelijk zijn van systeemeigen bibliotheken, meegeleverde binaire bestanden of externe uitvoerbare bestanden hebben mogelijk een build nodig die overeenkomt met de nieuwe architectuur. Schakel een twijfelachtige plug-in tijdens de eerste validatie uit als deze het opstarten verhindert en voeg hem pas weer toe nadat je de compatibiliteit hebt bevestigd.

Als mediapaden tussen hosts verschillen, behoud dan waar mogelijk dezelfde paden via mounts. Plan anders een ondersteunde padmigratie in, in plaats van de interne databaserecords van Jellyfin handmatig te bewerken.

Valideer de migratie voordat je de bron opnieuw gebruikt

Start alleen de doelinstantie en controleer gebruikers, bibliotheken, kijkstatus, artwork, geplande taken en één Direct Play plus één vereiste transcodering. Controleer de logboeken op ontbrekende systeemeigen bibliotheken, fouten met machtigingen of paden die nog naar de oude host verwijzen.

Start het doel twee keer opnieuw op en herhaal een afspeeltest, zodat het succes blijvend is en niet slechts het resultaat van één start. Als het doel faalt, stop het dan en herstel de migratiekopie of keer terug naar de onaangeroerde bron, in plaats van beide instanties dezelfde status te laten beschrijven.

De migratie is pas voltooid wanneer de nieuwe host een herstart en normaal huishoudelijk gebruik doorstaat. Als je de oude machine beschikbaar wilt houden, geef deze dan een afzonderlijk herstelde kopie of laat hem uitgeschakeld; gebruik nooit één live Jellyfin-gegevensmap als gedeelde actieve opslag tussen ARM- en x86-servers.