Como evitar trabalhos ou importações duplicados no Immich

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Evite tarefas ou importações duplicadas do Immich começando por separar dois sintomas diferentes: o mesmo trabalho em segundo plano parece ser executado novamente e a mesma fotografia torna-se mais do que um recurso. Em seguida, identifique qual cliente, importador, análise da biblioteca, alteração de caminho ou nova tentativa produziu o segundo evento antes de eliminar qualquer coisa.

A conceção mais segura atribui a cada grupo de recursos um único caminho de ingestão canónico. Um arquivo histórico na nuvem, uma biblioteca externa e uma cópia de segurança ativa do telemóvel podem ser todos válidos, mas a sobreposição da propriedade dos mesmos ficheiros pode criar registos duplicados ou ciclos de carregamento repetido que nenhuma limpeza pós-importação consegue corrigir de forma fiável.

Identifique se tem trabalho repetido ou recursos duplicados

Para tarefas repetidas, registe o nome da fila, o ID do recurso, a hora de início, o estado de conclusão/falha e o evento que precedeu a nova tarefa. Uma tarefa legítima a jusante, criada depois do processamento de metadados, é diferente da repetição incessante da mesma tarefa falhada. Não limpe todas as filas até saber qual dos padrões está presente.

Para recursos duplicados, compare a biblioteca de origem, o caminho original, o comportamento das somas de verificação quando disponível, o estado da cópia de segurança do dispositivo, a hora de captura e o tamanho do ficheiro. A mesma imagem visível pode existir como dois ficheiros diferentes após uma exportação da nuvem, edições de metadados, transcodificação ou tratamento de uma biblioteca externa baseado no caminho, enquanto ficheiros idênticos ao nível dos bytes também podem existir em diferentes fontes de biblioteca do Immich.

Se os carregamentos normais começarem a produzir repetidamente erros de soma de verificação ou de restrição de unicidade, preserve a base de dados e inspecione o estado da migração/esquema antes de tratar o sintoma como um problema da origem da importação. Recursos duplicados entre dois tipos de origem legítimos e uma falha de restrição da base de dados são situações diferentes e não devem seguir a mesma limpeza.

O guia da ZimaSpace sobre o estado da cópia de segurança do telemóvel e o agendamento móvel é útil porque um cliente móvel tem a sua própria visão do que ainda precisa de ser salvaguardado. A limpeza no servidor que ignore o estado do cliente pode fazer com que a sessão seguinte do telemóvel envie novamente os ficheiros.

Utilize um único caminho de ingestão canónico para cada grupo de fotografias existente

Escolha como as fotografias antigas entrarão no Immich antes de ativar a cópia de segurança contínua do telemóvel: por exemplo, importe o arquivo histórico uma vez, verifique-o e, depois, deixe o telemóvel contribuir apenas com novas capturas. Se os mesmos ficheiros históricos estiverem montados como biblioteca externa e forem carregados através da biblioteca de carregamentos normal, não presuma que a deduplicação global reconciliará as duas fontes.

Um relatório de duplicados entre fontes do Immich documenta a coexistência de conteúdos idênticos quando estes provêm de uma biblioteca externa e da biblioteca de carregamentos. Considere isso um limite do comportamento do projeto: a propriedade da origem é importante, pelo que a prevenção é mais fiável do que esperar que uma ferramenta de duplicados posterior deduza qual das cópias prefere.

Evite mover ficheiros que o Immich carregou internamente para uma biblioteca externa sem o seu conhecimento enquanto o telemóvel ainda os considerar parte do conjunto de cópia de segurança. Se for necessário alterar a arquitetura de armazenamento, faça a migração através de um procedimento documentado, com cópias de segurança e um pequeno grupo de teste; em seguida, confirme que a aplicação móvel e o servidor estão de acordo antes de eliminar a cópia antiga.

Controle as novas tentativas e o estado do cliente antes de aumentar a escala da importação

Utilize um manifesto de preparação para uma importação manual de grandes dimensões: registe o caminho de origem, a contagem de ficheiros, o total de bytes e uma soma de verificação estável ou o resultado do importador, quando for prático. Se uma importação for interrompida, retome-a através da mesma ferramenta e destino, em vez de iniciar um segundo importador independente contra a mesma origem enquanto o estado da primeira tarefa permanece incerto.

Um relatório recente de carregamentos repetidos do Immich mostrou um cliente móvel a tentar continuamente carregar recursos que o servidor já possuía, com erros de restrição de unicidade no servidor. Considere-o uma evidência limitada à versão de que o estado da cópia de segurança do cliente pode ser o responsável pelo ciclo; não o generalize como um comportamento universal da aplicação móvel. As alterações de caminho continuam a ser um risco separado. Mantenha estáveis os caminhos das bibliotecas externas visíveis no contentor durante uma importação de grandes dimensões e, se for necessária uma mudança de armazenamento, migre primeiro um pequeno grupo. Se a segunda cópia aparecer apenas depois de uma alteração de caminho, siga o ramo da identidade do caminho em vez de repor o estado da cópia de segurança do telemóvel.

-15% OFF

Teste a interrupção, a nova tentativa e um recurso verdadeiramente novo

Crie um pequeno grupo representativo que inclua fotografias normais, vídeos, uma imagem editada e pelo menos um ficheiro que já exista no caminho de destino. Importe-o uma vez, registe as contagens e os IDs dos recursos e, em seguida, interrompa uma segunda tentativa controlada ou uma nova análise, de acordo com o fluxo de trabalho que planeia utilizar em produção.

O teste é bem-sucedido quando não existe um segundo recurso sem explicação para o mesmo objeto de origem pretendido, as novas tentativas terminam sem uma fila em crescimento permanente e uma fotografia genuinamente nova continua a ser importada com sucesso. Reabra também o cliente móvel depois do teste, para que o seu estado de cópia de segurança não fique silenciosamente em desacordo com o servidor.

Se os duplicados regressarem apenas entre fontes de carregamento e de biblioteca externa, redesenhe o limite de propriedade em vez de as fundir repetidamente. Se o mesmo ID de recurso receber uma tarefa falhada sem fim, isole essa tarefa e esse ficheiro. Ao pedir ajuda, inclua o tipo de origem, os caminhos, os hashes quando relevantes, as versões, o estado da cópia de segurança do cliente e o menor grupo reproduzível.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.