Como é que o Jellyfin deteta e reconcilia alterações entre dispositivos?
O Jellyfin reconcilia a maioria das alterações entre dispositivos através de um servidor central, que deteta atualizações da biblioteca, consolida o estado partilhado e disponibiliza a vista resultante aos clientes.
Um telemóvel, uma televisão, um navegador e um tablet normalmente não negoceiam diretamente entre si a verdade da biblioteca multimédia. Comunicam com o mesmo servidor Jellyfin, que gere os metadados indexados da biblioteca e o estado por utilizador, como o progresso de visualização. A deteção do sistema de ficheiros, as atualizações de reprodução e as atualizações dos clientes são etapas separadas que convergem numa única autoridade do lado do servidor, pelo que os dispositivos normalmente ficam de acordo depois de o servidor aceitar a alteração e cada cliente atualizar a sua vista.
O servidor é a autoridade partilhada, não os clientes individuais
Os clientes apresentam as vistas da biblioteca e enviam ações do utilizador, mas o catálogo partilhado persistente reside no servidor. Esta arquitetura permite que uma televisão e um telemóvel vejam o mesmo item sem copiarem entre si toda a base de dados. Cada cliente pode armazenar em cache o estado da apresentação, mas o registo autoritativo da pertença à biblioteca e do progresso do utilizador permanece centralizado.
Um servidor multimédia é normalmente a autoridade sobre o que está efetivamente disponível e sobre o que foi reproduzido pelos seus utilizadores locais. Um modelo útil de fonte de verdade considera o servidor multimédia para reprodução como distinto dos sistemas portáteis de acompanhamento. A mesma lógica explica os clientes Jellyfin: convergem para o estado do servidor, em vez de escolherem um vencedor entre dispositivos pares.
Este modelo simplifica a gestão dos conflitos, porque existe um único local onde as alterações aceites se tornam persistentes. Um cliente pode apresentar temporariamente dados desatualizados em cache, mas não se transforma numa segunda base de dados equivalente só porque ainda não atualizou a sua vista. Reconciliar significa devolver a vista do cliente ao estado aceite pelo servidor.
As alterações no sistema de ficheiros tornam-se estado da biblioteca através da deteção no servidor
Adicionar, substituir, mudar o nome ou remover um ficheiro multimédia altera primeiro o armazenamento, não o catálogo Jellyfin. O servidor tem de detetar esse evento do sistema de ficheiros através de uma análise, de um acionador de monitorização ou de um sinal de automatização, inspecionar o caminho afetado e atualizar a sua representação indexada. Só depois dessa consolidação é que os clientes podem receber a nova vista da biblioteca.
Ferramentas de automatização direcionada, como as atualizações direcionadas da biblioteca, existem porque a deteção pode ser acionada com maior precisão do que através da espera por uma análise agendada abrangente. O princípio arquitetural mantém-se: um evento de ficheiro torna-se uma atualização da biblioteca no servidor antes de se tornar uma alteração da interface em vários dispositivos.
Isto separa a verdade do armazenamento da verdade do catálogo durante a janela de deteção. Um ficheiro pode existir no disco enquanto os clientes ainda não o conseguem ver, ou um item indexado pode permanecer brevemente até o processamento da remoção terminar. Medir o tempo entre a alteração do sistema de ficheiros e a atualização do índice do servidor é, portanto, diferente de medir a rapidez com que um cliente atualiza a sua vista depois de o servidor já ter consolidado a alteração.
O progresso de reprodução regressa ao mesmo estado do utilizador no servidor
O progresso de visualização segue um caminho de entrada diferente da deteção do sistema de ficheiros. O ficheiro multimédia não muda quando o espetador chega ao minuto quarenta; o cliente comunica o estado da reprodução associado ao utilizador autenticado, e o servidor regista essa atualização específica do utilizador. Outro dispositivo com sessão iniciada na mesma conta pode posteriormente consultar o estado partilhado do servidor e retomar a partir da posição aceite.
É por isso que o Jellyfin consegue sincronizar o histórico de visualização entre dispositivos e clientes sem copiar diretamente um ficheiro de progresso local entre a televisão e o telemóvel. Ambos os dispositivos convergem porque leem e escrevem através do mesmo registo de utilizador no servidor, não porque efetuam uma reconciliação entre pares.
A fronteira observável é o momento da escrita. Se um dispositivo ficar offline antes de a sua atualização de progresso chegar ao servidor, outro dispositivo pode legitimamente apresentar o valor mais antigo armazenado no servidor. Quando a conectividade regressar, o resultado final dependerá da atualização que a aplicação aceitar e da ordem em que o fizer. O progresso local offline não deve ser confundido com um estado partilhado já consolidado.
Os clientes reconciliam-se através de atualizações a partir do servidor, não através de fusões entre si
Depois de o servidor consolidar uma alteração, os clientes continuam a precisar de uma atualização, de um evento, de uma ação de navegação ou de um pedido subsequente que obtenha o novo estado. Uma televisão pode manter na memória uma grelha de capas desatualizada enquanto um navegador já mostra a atualização. Essa divergência temporária é um problema de cache da apresentação, a menos que o próprio servidor contenha registos em conflito.
A diversidade dos clientes torna esta distinção visível, porque diferentes clientes Jellyfin podem apresentar o mesmo servidor com interfaces e comportamentos de reprodução diferentes. Se um cliente parecer desatualizado enquanto outro está atualizado, verifique primeiro o estado do servidor e, em seguida, atualize ou volte a ligar o cliente divergente antes de considerar a discrepância um conflito da base de dados.
Esta distinção é importante durante a resolução de problemas. Se dois clientes discordarem, consulte ou inspecione primeiro o estado do servidor. Se o servidor tiver o valor esperado e apenas um cliente estiver desatualizado, o comportamento de atualização ou da cache é provavelmente a causa. Se o próprio servidor não tiver a atualização, investigue a deteção, as permissões ou o evento de escrita antes de culpar o segundo cliente.
Limite de falha: servidores separados não reconciliam automaticamente as suas bases de dados
O modelo de autoridade central aplica-se dentro de uma única instância do servidor Jellyfin. Se uma família executar dois servidores independentes, cada um pode acumular os seus próprios utilizadores, estados de visualização, alterações de metadados e alterações na base de dados da biblioteca. Não existe uma presunção geral de que essas bases de dados se detetarão e fundirão com segurança apenas por apontarem para ficheiros multimédia semelhantes.
Ferramentas entre servidores, como a sincronização explícita do estado de visualização, existem precisamente porque os servidores multimédia independentes precisam de um mecanismo de reconciliação explícito para o progresso partilhado. Essa ferramenta pode sincronizar um subconjunto definido do estado; não transforma duas bases de dados Jellyfin completas num cluster transparente com vários mestres.
O mesmo limite aplica-se aos dispositivos offline. Um cliente pode manter uma vista local desatualizada, mas não deve ser tratado como uma base de dados autoritativa a fundir manualmente no Jellyfin. Quando são introduzidos vários escritores ou servidores, defina qual é o estado autoritativo, que campos são sincronizados e como são resolvidas as atualizações em conflito antes de considerar o sistema “reconciliado”.
Execute um teste de reconciliação em quatro passos com dois dispositivos
Utilize dois clientes com sessão iniciada no mesmo utilizador de teste e um item multimédia conhecido. Primeiro, adicione ou mude o nome de um ficheiro de teste e cronometre a deteção pelo servidor. Segundo, confirme que ambos os clientes recebem o novo estado do catálogo após a atualização. Terceiro, altere o progresso de visualização no cliente A e confirme que o cliente B recebe o valor aceite pelo servidor. Quarto, reinicie o servidor e verifique se o estado consolidado persiste.
A explicação interna sobre a consistência do estado simultâneo fornece o limite complementar da base de dados: as escritas aceites precisam de regras de transação e ordenação para que a atividade sobreposta não exponha atualizações incompletas. O teste entre dispositivos acrescenta a temporização da deteção e da atualização dos clientes a essa garantia de estado persistente.
Considere o teste aprovado apenas quando o servidor se torna a mesma autoridade observável após cada passo: as alterações do armazenamento são indexadas uma vez, ambos os clientes convergem para o mesmo resultado da biblioteca, o progresso do utilizador não é duplicado nem perdido e o reinício não reverte uma atualização consolidada. Se a discordância persistir, identifique se a falha ocorreu na deteção, na consolidação do servidor, na atualização do cliente ou no limite entre servidores separados.
Perguntas frequentes
Os clientes Jellyfin sincronizam diretamente entre si?
Normalmente, não. Um telemóvel, uma televisão, um navegador e um tablet convergem através do servidor Jellyfin: os clientes enviam atualizações para o servidor e, mais tarde, leem o estado do servidor. Tratar os clientes como réplicas pares faz com que atrasos normais de atualização pareçam conflitos que, na realidade, não existem.
Porque é que um cliente Jellyfin pode apresentar dados desatualizados da biblioteca?
O servidor pode já ter consolidado uma alteração da biblioteca ou da reprodução enquanto um cliente ainda apresenta uma vista em cache mais antiga. Confirme o estado no servidor através de outro cliente ou da interface Web e, em seguida, atualize ou volte a ligar o cliente divergente antes de investigar problemas de deteção ou da base de dados.
Dois servidores Jellyfin separados podem sincronizar automaticamente o progresso de visualização?
Os servidores Jellyfin separados não formam um sistema de estado automático com vários mestres. Se o mesmo utilizador tiver de transportar o histórico de visualização entre servidores independentes, utilize um fluxo de sincronização explícito com uma fonte de verdade definida e teste o comportamento em caso de conflito antes de depender dele.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
As câmaras domésticas conseguem sincronizar eventos sem serviços de hora na nuvem?
Uma explicação baseada primeiro no mecanismo do tempo da câmara sem cloud, as suas contrapartidas na partilha de recursos, três perguntas frequentes sobre a...
Um serviço de IA local consegue detetar camadas de modelos corrompidas antes da inferência?
Uma explicação baseada primeiro no mecanismo da deteção de corrupção na camada do modelo, dos seus compromissos em termos de recursos partilhados, de três...
É possível restaurar um sistema RAG sem regenerar todos os embeddings?
Uma explicação, centrada no mecanismo, do restauro de RAG sem re-embedding, das suas contrapartidas em recursos partilhados, de três perguntas frequentes sobre a expansão...
