Como evitar entradas de filmes duplicadas após alterar os caminhos de armazenamento
Evite filmes duplicados tornando os caminhos antigo e novo mutuamente exclusivos antes de o servidor multimédia analisar a biblioteca migrada.
Uma migração de armazenamento pode expor o mesmo filme através de duas montagens bind, duas raízes de biblioteca, uma cópia temporária ou um registo obsoleto da base de dados que permanece depois de o caminho antigo ser removido. O fluxo de trabalho mais seguro consiste em suspender as análises automáticas, fazer uma cópia de segurança da base de dados da aplicação, mapear os caminhos antigo e novo exatos, mover ou copiar os conteúdos num período controlado, remover a origem obsoleta da biblioteca e executar uma única nova análise deliberada apenas depois de o servidor conseguir ver uma única localização canónica.
Mapeie todos os caminhos que podem chegar ao mesmo filme
Liste as raízes da biblioteca, as montagens bind do Docker, as ligações simbólicas, os sistemas de ficheiros merger, as montagens de rede e as pastas temporárias de migração. Resolva o caminho real de um filme tanto a partir do anfitrião como do contentor.
Os duplicados aparecem frequentemente porque o analisador recebe o mesmo ficheiro através de um novo caminho, enquanto o item antigo da base de dados continua válido. Um relatório de migração do Jellyfin reproduziu o problema quando a movimentação de pastas da biblioteca criou entradas duplicadas.
Escolha um caminho canónico no contentor, como /media/movies, e mantenha-o estável mesmo que a origem do armazenamento no anfitrião mude. Um caminho estável no contentor reduz futuras alterações na base de dados, porque a aplicação não precisa de aprender uma nova localização para cada migração de grupo de armazenamento ou unidade.
Pause as análises automáticas antes de copiar ou mudar o nome dos conteúdos
Desative a monitorização em tempo real e as análises agendadas da biblioteca durante a migração. Caso contrário, o servidor poderá indexar cópias incompletas, detetar ambas as localizações ou registar o mesmo título enquanto as pastas estão a ser renomeadas por etapas.
Faça uma cópia de segurança da configuração e da base de dados do servidor multimédia antes de alterar os caminhos. Isto protege o estado de visualização, as escolhas de ilustrações, as coleções, os utilizadores e os identificadores dos fornecedores, que uma reconstrução de uma biblioteca limpa poderá não reproduzir exatamente.
Copie ou mova primeiro uma pequena pasta de teste, verifique as somas de verificação ou os tamanhos dos ficheiros e mantenha a origem antiga intacta até que a nova localização possa ser lida pela conta de serviço. Não permita que ambos os caminhos permaneçam como raízes ativas da biblioteca durante este período de verificação.
Remova o caminho antigo da biblioteca antes de analisar o novo
Depois de verificar o novo caminho, remova a pasta obsoleta da configuração da biblioteca ou remapeie o caminho existente no contentor para a nova origem no anfitrião. Confirme que o caminho antigo deixou de estar acessível através de outra biblioteca ou ligação simbólica.
A remoção de um caminho nem sempre elimina imediatamente todos os registos associados. Um problema do Jellyfin indica que os metadados associados a caminhos removidos permaneceram, razão pela qual a limpeza dos caminhos deve ser verificada e não presumida.
Execute a limpeza da biblioteca suportada pela aplicação ou uma análise completa apenas depois de a origem antiga deixar de estar disponível. Evite editar manualmente a base de dados, a menos que tenha uma cópia de segurança testada e um plano de recuperação específico para a versão.
Preserve a identidade dos conteúdos enquanto os ficheiros são movidos
Mantenha consistentes os nomes das pastas dos filmes, os nomes dos ficheiros, os marcadores de ano, as etiquetas de edição, os identificadores dos fornecedores e os ficheiros de metadados locais. Um título renomeado durante a mesma migração poderá ser tratado como um item diferente, mesmo quando os bytes do vídeo não foram alterados.
Armazene intencionalmente os metadados e as ilustrações locais. Se identificadores como os IDs do TMDB ou do IMDb estiverem incorporados nos nomes ou nos ficheiros NFO, preserve-os para que o novo caminho seja associado à mesma identidade do filme, em vez de criar uma segunda correspondência ambígua.
O fluxo de trabalho de migração de dados NAS da ZimaSpace é a verificação complementar para proteger os dados de origem e validar as permissões antes de remover a cópia antiga.
Distingua dois caminhos de duas versões ou edições
Abra ambas as entradas duplicadas e compare os caminhos dos ficheiros, as informações multimédia, os IDs dos fornecedores, a duração, as etiquetas de edição e a disponibilidade. Duas entradas podem representar o mesmo ficheiro através de dois caminhos, duas cópias físicas ou versões legítimas que foram agrupadas incorretamente.
Os registos obsoletos podem continuar acessíveis depois de um caminho desaparecer. Um relatório do Jellyfin chama-lhes entradas fantasma, que não devem ser confundidas com um segundo ficheiro de filme real.
Se ambas as entradas apontarem para caminhos ativos, remova da área da biblioteca o caminho não pretendido. Se um dos caminhos já não existir, utilize o processo de limpeza suportado e verifique se o registo desaparece. Se os ficheiros forem edições intencionais, aplique as regras de nomenclatura e agrupamento suportadas pelo servidor multimédia, em vez de eliminar uma delas sem verificar.
| Padrão de duplicação | Causa provável | Ação correta |
|---|---|---|
| Duas entradas, dois caminhos ativos | As raízes antiga e nova foram ambas analisadas | Manter um único caminho canónico |
| Duas entradas, um caminho inexistente | Registo obsoleto da base de dados | Limpar a biblioteca depois de fazer uma cópia de segurança |
| Dois ficheiros, o mesmo título | A cópia de migração ainda está presente | Verificar e retirar a cópia antiga |
| Duas edições intencionais | Incompatibilidade de nomenclatura ou agrupamento | Utilizar a nomenclatura de edições suportada |
Esta classificação impede que uma limpeza da base de dados elimine uma versão alternativa legítima ou uma versão de maior qualidade.
Execute uma nova análise controlada e verifique o estado
Reative as análises apenas depois de o caminho canónico estar montado, o caminho antigo ter desaparecido e o utilizador do serviço conseguir ler a nova localização. Inicie uma análise completa e observe os eventos de remoção e adição relacionados com o filme migrado.
Algumas bibliotecas não conseguiram remover ficheiros depois de uma migração de armazenamento, mesmo após o caminho antigo ter sido eliminado das definições. Um relatório do Jellyfin documenta ficheiros removidos que permaneceram na biblioteca, pelo que a verificação final deve comparar as entradas da base de dados com os caminhos reais.
Verifique se cada filme aparece uma única vez, abre a partir do novo caminho, mantém o estado de visualização e as coleções e continua disponível após reiniciar o serviço. Mantenha o armazenamento antigo offline, mas intacto, até esta auditoria ser concluída; depois, retire-o de acordo com o plano de cópia de segurança e migração.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
