O Jellyfin pode funcionar em ARM e x86 com os mesmos dados?

Normalmente, sim, mas trate a migração de ARM para x86 como uma migração controlada do anfitrião, e não como prova de que todos os componentes do Jellyfin são independentes da arquitetura. Nas versões atuais do Jellyfin, o destino ARM relevante é ARM64; um destino x86 também deverá ser uma plataforma de 64 bits suportada. Mantenha a origem intacta até o destino ter passado pelos testes de reinício e reprodução.

A fronteira importante é operacional: pare a origem antes de copiar o estado persistente e nunca permita que duas instâncias do Jellyfin, em anfitriões diferentes, escrevam no mesmo diretório de dados ativo. O Jellyfin não documenta a migração de ARM64 para x86-64 como um percurso especial sem riscos, por isso preserve uma cópia para reversão e reconstrua separadamente os componentes específicos da plataforma, como os pacotes FFmpeg, os mapeamentos dos dispositivos de aceleração de hardware, as dependências nativas dos plugins, as permissões e os caminhos do anfitrião.

Verifique se a arquitetura do destino é realmente suportada

Comece por confirmar que o destino é uma plataforma Jellyfin de 64 bits atualmente suportada. Não presuma que uma placa ARM antiga, um sistema operativo de 32 bits ou uma máquina x86 antiga são aceitáveis apenas porque o Linux ainda arranca nesses equipamentos.

O Jellyfin 10.11 removeu o suporte para ARM32, incluindo armhf, e passou a exigir um sistema operativo ARM64 nas plataformas ARM. Se a origem ainda executar uma compilação ARM antiga de 32 bits, planeie primeiro um destino de 64 bits suportado, em vez de tratar o ambiente de execução antigo como um destino de migração atual.

Em x86, utilize um anfitrião x86-64 suportado que cumpra os requisitos da versão do Jellyfin que pretende executar. Se o destino depender de um pacote não oficial, de um sistema operativo não suportado ou de um processador obsoleto, resolva esse problema da plataforma antes de mover o estado persistente.

Trate o estado armazenado como portátil, mas a implementação como específica da plataforma

Uma implementação normal do Jellyfin mantém o estado persistente do servidor na base de dados, juntamente com ficheiros de configuração e metadados. Nas instalações que utilizam SQLite, o formato da base de dados em disco foi concebido para ser portátil entre arquiteturas de processador, pelo que a família do CPU, por si só, não é motivo para converter a base de dados antes de uma migração.

O SQLite documenta o seu formato de ficheiro como um formato de base de dados multiplataforma, incluindo portabilidade entre sistemas de 32 e 64 bits e entre diferentes ordenações de bytes. Isto sustenta a parte relativa ao formato da base de dados, mas não garante que todos os plugins do Jellyfin, executáveis externos, controladores ou caminhos específicos da implementação sobrevivam sem alterações.

Mantenha a distinção clara: os registos armazenados portáteis são apenas uma camada. A compatibilidade da versão do Jellyfin, a cobertura completa dos dados e da configuração, a consistência dos caminhos multimédia, as dependências dos plugins, as permissões e o acesso aos dispositivos de hardware continuam a determinar se o destino se comportará como a origem.

Pare o Jellyfin antes de mover o estado ativo

Para uma migração controlada entre arquiteturas, encerre o processo do Jellyfin na origem antes de criar a cópia de migração. Isto impede que uma base de dados ativa ou um estado de escrita antecipada se altere enquanto os ficheiros estão a ser copiados e proporciona um único ponto de reversão consistente.

Copie todo o âmbito dos dados e da configuração, em vez de selecionar apenas jellyfin.db. Uma cópia parcial pode preservar os utilizadores, mas perder a configuração, os plugins, os metadados ou outro estado de que o destino necessita.

O mesmo modelo de proteção utilizado num plano de cópias de segurança múltiplas aplica-se aqui: mantenha a origem intacta até o destino ter passado por uma restauração real e por uma validação da reprodução.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Reconstrua os componentes específicos da arquitetura no novo anfitrião

Instale o pacote nativo do Jellyfin para o destino ou utilize a imagem de contentor multi-arquitetura correta. Recrie os mapeamentos dos dispositivos GPU, as permissões dos grupos, os pacotes FFmpeg e quaisquer caminhos específicos do anfitrião, em vez de copiar binários da arquitetura antiga.

Reveja os plugins após o primeiro arranque. Os plugins que dependem de bibliotecas nativas, binários incluídos ou executáveis externos poderão necessitar de uma compilação compatível com a nova arquitetura. Desative um plugin duvidoso durante a primeira validação se este impedir o arranque e volte a adicioná-lo apenas depois de confirmar a compatibilidade.

Se os caminhos multimédia forem diferentes entre os anfitriões, preserve os mesmos caminhos através de montagens, sempre que possível. Caso contrário, planeie uma migração de caminhos suportada, em vez de editar manualmente os registos internos da base de dados do Jellyfin.

Valide a migração antes de reutilizar a origem

Inicie apenas a instância de destino e confirme os utilizadores, as bibliotecas, o estado de visualização, as ilustrações, as tarefas agendadas e uma reprodução em Direct Play, além de uma transcodificação necessária. Consulte os registos para detetar bibliotecas nativas em falta, falhas de permissões ou caminhos que ainda referenciem o anfitrião antigo.

Reinicie o destino duas vezes e repita um teste de reprodução, para garantir que o sucesso é persistente e não apenas o resultado de um arranque pontual. Se o destino falhar, pare-o e restaure a cópia de migração ou volte à origem intocada, em vez de permitir que ambas as instâncias escrevam no mesmo estado.

A migração só estará concluída quando o novo anfitrião sobreviver a um reinício e ao uso normal em casa. Se quiser manter a máquina antiga disponível, atribua-lhe uma cópia restaurada separada ou mantenha-a desligada; não utilize um único diretório de dados ativo do Jellyfin como armazenamento partilhado entre servidores ARM e x86.