O Immich apresenta dados desatualizados após a alteração do caminho de armazenamento

Os dados desatualizados do Immich após uma alteração do caminho de armazenamento têm três causas diferentes que não devem ser misturadas: uma mudança da raiz de multimédia gerida, uma alteração do caminho de importação de uma biblioteca externa ou um cliente que continua a apresentar um estado em cache. As versões modernas do Immich podem reconciliar uma localização de multimédia gerida movida quando a localização de multimédia configurada e a montagem do volume permanecem consistentes, enquanto as mudanças de bibliotecas externas podem continuar a ser tratadas como novas identidades de ativos.

Preserve o caminho antigo e a base de dados antes de voltar a analisar. Primeiro, confirme qual o caminho que o contentor em execução consegue ver; depois, determine se o registo do lado do servidor do Immich está incorreto ou se apenas um cliente está desatualizado. Essa distinção determina se deve corrigir uma montagem, restaurar um caminho estável visível pelo contentor, voltar a analisar um subconjunto de teste ou limpar apenas a cache do cliente.

Distinguir uma Mudança da Raiz de Multimédia Gerida de uma Mudança de Biblioteca Externa

Se alterou a localização no anfitrião dos carregamentos geridos pelo Immich, confirme que a definição efetiva da localização de multimédia e a montagem anfitrião-contentor foram alteradas em conjunto. Uma mudança moderna de multimédia gerida não deve ser diagnosticada da mesma forma que a mudança do nome do caminho de importação de uma biblioteca externa.

O mapa do estado persistente do Immich da ZimaSpace é útil neste caso, porque a base de dados e os caminhos do sistema de ficheiros formam um único limite de recuperação. Os ficheiros corretos no anfitrião não são suficientes se o contentor estiver montado noutro local.

Se a raiz de multimédia gerida não corresponder, corrija primeiro o ambiente e o mapeamento de volumes e reinicie o serviço antes de executar tarefas da biblioteca. Se o caminho alterado pertencer a uma biblioteca externa, mantenha a base de dados intacta e teste essa situação separadamente.

Manter Estável o Caminho da Biblioteca Externa Visível pelo Contentor Sempre que Possível

Numa biblioteca externa, uma mudança de armazenamento no anfitrião é mais segura quando o caminho de importação visível pelo contentor pode permanecer inalterado. Se o caminho apresentado ao Immich mudar, registe um pequeno conjunto de IDs de ativos, álbuns, pessoas e caminhos antigos antes de uma análise, para poder determinar se os ativos existentes foram religados ou recriados.

Um relatório sobre alteração do caminho de uma biblioteca externa do Immich descreveu ficheiros relocalizados a serem tratados como novos ativos, com reprocessamento e perda de relações exclusivas do Immich. É um caso específico de uma versão, mas sustenta a regra conservadora de que uma alteração do caminho de uma biblioteca externa não é automaticamente uma mudança de nome transparente.

Se um subconjunto de teste aparecer como novos ativos enquanto os registos antigos ficam em falta ou são enviados para o lixo, pare a análise completa. Restaure o caminho antigo visível pelo contentor, se for prático, ou utilize uma abordagem de migração adequada à versão; não reescreva manualmente os caminhos da base de dados de produção sem uma cópia de segurança testada.

Não confunda esta situação com uma migração do Modelo de Armazenamento para ficheiros geridos pelo Immich. O sintoma pode parecer semelhante na linha temporal, mas a propriedade dos ficheiros e o caminho de migração suportado são diferentes.

Separar os Caminhos Guardados no Servidor da Cache do Cliente

Inspecione o mesmo ativo conhecido no cliente Web e noutro cliente autenticado e compare-o com os registos do servidor ou com o caminho visível pelo servidor. Se as tarefas do lado do servidor ainda indicarem o caminho antigo, limpar a cache do navegador não pode corrigir o registo subjacente.

Um problema posterior de metadados de um caminho antigo do Immich mostrou que o processamento continuava a referenciar um caminho anterior de uma biblioteca externa após uma mudança de nome. Isto é uma forte indicação para verificar os caminhos usados pelas tarefas antes de atribuir a culpa à interface móvel ou Web.

Se o caminho do servidor estiver correto, mas apenas uma vista Web estiver desatualizada, atualize ou limpe a cache desse cliente e volte a testar o ficheiro original. Miniaturas em cache e um estado desatualizado do cliente podem fazer com que um servidor corrigido pareça avariado, enquanto uma pré-visualização em cache também pode fazer com que um caminho do servidor avariado pareça funcionar.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Corrigir o Limite de Caminho Mais Pequeno e Validar uma Nova Análise Controlada

Faça uma única correção reversível: sincronize a definição de multimédia gerida e a montagem, restaure o caminho anterior da biblioteca externa visível pelo contentor, corrija um caminho de importação ou limpe a cache de um cliente. Faça uma cópia de segurança da base de dados antes de qualquer ação que possa levar à redescoberta de uma biblioteca extensa.

Execute a análise mais pequena possível e verifique se os registos existentes continuam associados, se os erros relativos ao caminho antigo param e se não aparecem ativos antigos e novos duplicados. Depois, abra os originais selecionados, confirme as relações com álbuns e pessoas, execute uma pesquisa e reinicie a pilha.

Peça assistência se os registos dos caminhos antigo e novo continuarem ativos em simultâneo, se uma biblioteca externa extensa for reprocessada inesperadamente ou se as relações desaparecerem enquanto os originais continuam legíveis. Preserve o mapa exato das montagens antes e depois, a versão do Immich, os IDs dos ativos afetados, o comportamento relativo a maiúsculas e minúsculas do sistema de ficheiros e o carimbo de data/hora da cópia de segurança da base de dados.