Come impedire la duplicazione di processi o importazioni in Jellyfin

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Previeni la duplicazione dei processi e delle importazioni di Jellyfin assegnando a ogni operazione un solo pianificatore, un solo processo di scrittura, un solo percorso monitorato e un solo segnale di completamento.

Le scansioni, le importazioni o i processi dei metadati vengono duplicati dopo un riavvio, la ricreazione di un container o una nuova automazione? Prima di disabilitare qualsiasi elemento, annota il nome dell'attività, l'ora di avvio, l'ID del container, il pianificatore, la directory monitorata e l'output. La soluzione sicura consiste nel rimuovere le responsabilità sovrapposte, non nel nascondere una voce duplicata.

Individua ogni pianificatore che può avviare la stessa attività

Controlla le attività pianificate di Jellyfin, gli hook di riavvio dei container, i cron o i timer systemd dell'host, la post-elaborazione del gestore dei download e qualsiasi sidecar che chiami l'API. Confronta i timestamp e gli ID dei processi di due esecuzioni. Se entrambe le attività iniziano in corrispondenza dello stesso evento, disabilita il trigger secondario e lascia invariata l'attività principale.

Le attività di Jellyfin possono essere eseguite periodicamente o manualmente, mentre le attività di avvio potrebbero essere eseguite prima che una condivisione di rete sia pronta (riferimento sulla temporizzazione delle attività). Considera la disponibilità del mount un prerequisito, invece di consentire una seconda importazione compensativa.

Verifica se il duplicato compare dopo l'avvio, un webhook o un nuovo tentativo manuale. Il trigger restringe l'ambito del responsabile da disabilitare; disattivare tutte le attività pianificate nasconde la causa senza impedirne il ripetersi.

Assegna a ogni percorso un solo processo di scrittura e un'identità stabile

Assicurati che un solo downloader o importatore sposti i file nella libreria e che ogni container veda lo stesso percorso canonico. Due container con mappature diverse possono importare lo stesso file come due identità. Confronta inode, checksum, percorso e proprietario di una coppia duplicata prima di eliminare qualsiasi elemento.

Se il file sorgente viene rinominato o riformattato, Jellyfin potrebbe rilevare un nuovo elemento invece di un aggiornamento. Completa uno spostamento controllato, esegui una sola scansione e verifica il numero previsto di elementi prima di riattivare l'automazione.

Confronta le etichette dei container attivi e i percorsi monitorati, non solo il file di configurazione presente sul disco. Un vecchio container potrebbe mantenere attivo un watcher obsoleto dopo una nuova distribuzione.

Convalida la prevenzione dopo un riavvio e un nuovo tentativo

Dopo aver modificato un trigger, riavvia lo stack e attendi che si verifichi una sola volta la finestra pianificata. Conferma un solo processo, un solo evento di importazione, una sola modifica al database e un solo file finale. Quindi ripeti un'esecuzione non riuscita o interrotta per verificare che il nuovo tentativo non avvii una seconda copia.

Procedi con un'escalation quando i duplicati persistono con un solo pianificatore e un solo percorso, il database contiene identità in conflitto oppure un plugin ricrea ripetutamente le attività. Conserva i file multimediali originali e il backup del database finché la pulizia e il test di prevenzione non sono completati con esito positivo.

Dopo aver rimosso il processo di scrittura secondario, esegui una normale importazione e un nuovo tentativo interrotto. Il risultato atteso è un solo evento nel database e un solo file finale per ogni elemento sorgente.

Conferma la regola di prevenzione dopo il riavvio

Riavvia lo stack e attendi una finestra pianificata completa lasciando abilitato solo il pianificatore scelto. Registra il processo, il percorso e l'evento del database, in modo che il confine delle responsabilità sia osservabile.

Mantieni la configurazione quando un nuovo tentativo non avvia una seconda importazione e la libreria contiene un solo elemento valido. Riattiva un'automazione alla volta se è necessario un altro servizio.

Procedi con un'escalation quando i duplicati ricompaiono con un solo processo di scrittura, quando il database contiene identità in conflitto o quando un plugin ricrea le attività disabilitate.

Supporto e consigli

Altro da leggere

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.