Jellyfin può funzionare su ARM e x86 con gli stessi dati?

In genere sì, ma considera il passaggio da ARM a x86 come una migrazione controllata dell’host, non come una prova che ogni componente di Jellyfin sia indipendente dall’architettura. Per le versioni attuali di Jellyfin, il target ARM rilevante è ARM64; anche la destinazione x86 dovrebbe essere una piattaforma a 64 bit supportata. Mantieni intatta la sorgente finché la destinazione non avrà superato i controlli di riavvio e riproduzione.

Il confine importante è operativo: arresta la sorgente prima di copiare lo stato persistente e non permettere mai a due istanze di Jellyfin su host diversi di scrivere nella stessa directory dati attiva. Jellyfin non documenta ARM64-to-x86-64 come un percorso di migrazione speciale a rischio zero, quindi conserva una copia per il rollback e ricrea separatamente gli elementi specifici della piattaforma, come i pacchetti FFmpeg, le mappature dei dispositivi per l’accelerazione hardware, le dipendenze native dei plugin, i permessi e i percorsi dell’host.

Verifica che l’architettura della destinazione sia effettivamente supportata

Inizia confermando che la destinazione sia una piattaforma Jellyfin a 64 bit attualmente supportata. Non dare per scontato che una vecchia scheda ARM, un sistema operativo a 32 bit o una macchina x86 obsoleta siano accettabili solo perché Linux continua ad avviarsi su di essa.

Jellyfin 10.11 ha formalmente rimosso il supporto ARM32, incluso armhf, e ora richiede un sistema operativo ARM64 sulle piattaforme ARM. Se la sorgente esegue ancora una vecchia build ARM a 32 bit, pianifica prima una destinazione supportata a 64 bit invece di considerare il vecchio runtime come destinazione di migrazione attuale.

Su x86, utilizza un host x86-64 supportato che soddisfi i requisiti della versione di Jellyfin che intendi eseguire. Se la destinazione dipende da un pacchetto non ufficiale, da un sistema operativo non supportato o da una CPU obsoleta, risolvi il problema della piattaforma prima di trasferire lo stato persistente.

Considera lo stato memorizzato portabile, ma la distribuzione specifica della piattaforma

Una distribuzione standard di Jellyfin conserva lo stato persistente del server nel database, insieme ai file di configurazione e ai metadati. Per le installazioni che utilizzano SQLite, il formato del database su disco è progettato per essere portabile tra architetture di processore, quindi la sola famiglia della CPU non è un motivo per convertire il database a livello binario prima della migrazione.

SQLite documenta il proprio formato di file come un formato di database multipiattaforma, inclusa la portabilità tra sistemi a 32 e 64 bit e tra diverse architetture con ordine dei byte. Questo supporta l’aspetto relativo al formato del database, ma non garantisce che ogni plugin di Jellyfin, eseguibile esterno, driver o percorso specifico della distribuzione possa funzionare invariato.

Tieni distinta la situazione: i record memorizzati portabili sono solo un livello. La compatibilità della versione di Jellyfin, la copertura completa di dati e configurazione, la coerenza dei percorsi multimediali, le dipendenze dei plugin, i permessi e l’accesso ai dispositivi hardware determinano comunque se la destinazione si comporterà come la sorgente.

Arresta Jellyfin prima di spostare lo stato attivo

Per una migrazione controllata tra architetture, arresta il processo Jellyfin sulla sorgente prima di creare la copia per la migrazione. In questo modo eviti che un database attivo o uno stato di scrittura anticipata cambino durante la copia dei file e ottieni un unico punto di rollback coerente.

Copia l’intero ambito dei dati e della configurazione invece di selezionare solo jellyfin.db. Una copia parziale può conservare gli utenti, ma perdere configurazione, plugin, metadati o altri dati di stato richiesti dalla destinazione.

Lo stesso modello di protezione utilizzato in un piano di backup con più copie si applica anche qui: mantieni intatta la sorgente finché la destinazione non avrà superato una verifica reale del ripristino e della riproduzione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ricrea gli elementi specifici dell’architettura sul nuovo host

Installa il pacchetto Jellyfin nativo della destinazione oppure utilizza l’immagine container multi-arch corretta. Ricrea le mappature dei dispositivi GPU, i permessi dei gruppi, i pacchetti FFmpeg e tutti i percorsi specifici dell’host invece di copiare i binari dalla vecchia architettura.

Controlla i plugin dopo il primo avvio. I plugin che dipendono da librerie native, binari inclusi o eseguibili esterni potrebbero richiedere una build compatibile con la nuova architettura. Disabilita un plugin sospetto durante la prima verifica se impedisce l’avvio, quindi riattivalo solo dopo averne confermato la compatibilità.

Se i percorsi multimediali differiscono tra gli host, mantieni gli stessi percorsi tramite mount quando possibile. In caso contrario, pianifica una migrazione dei percorsi supportata invece di modificare manualmente i record interni del database di Jellyfin.

Verifica la migrazione prima di riutilizzare la sorgente

Avvia solo l’istanza sulla destinazione e verifica utenti, librerie, stato di visione, copertine, attività pianificate, una riproduzione Direct Play e una transcodifica necessaria. Controlla i log per individuare librerie native mancanti, errori di autorizzazione o percorsi che fanno ancora riferimento al vecchio host.

Riavvia due volte la destinazione e ripeti un test di riproduzione, così da verificare che il risultato sia persistente e non limitato a un singolo avvio. Se la destinazione non funziona, arrestala e ripristina la copia della migrazione oppure torna alla sorgente intatta, invece di consentire a entrambe le istanze di scrivere nello stesso stato.

Lo spostamento è completo solo quando il nuovo host supera il riavvio e l’uso domestico normale. Se vuoi mantenere disponibile la vecchia macchina, assegnale una copia ripristinata separata oppure lasciala spenta; non utilizzare una singola directory dati Jellyfin attiva come spazio condiviso tra server ARM e x86.