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.
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

Como otimizar as ligações à base de dados do Immich para contentores simultâneos
Não aumente primeiro o valor de max_connections. Meça as sessões do Immich, some a procura total de cada contentor, preserve margem para o administrador...

Como reparar o Immich depois de o volume da base de dados ficar cheio
Nunca elimine o WAL do PostgreSQL para libertar espaço. Pare as escritas do Immich, preserve o estado da base de dados, adicione capacidade de...

Por que motivo o Immich recria ficheiros em falta com o proprietário errado?
O Immich não deve recriar silenciosamente os originais de origem em falta. Identifique o tipo de ficheiro regenerado e o autor, e corrija depois...

