So verhinderst du doppelte Jobs oder Importe in Jellyfin

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Verhindern Sie doppelte Jellyfin-Aufgaben und -Importe, indem Sie jeder Operation genau einen Scheduler, einen Schreibprozess, einen überwachten Pfad und ein Abschlusssignal zuweisen.

Werden Scans, Importe oder Metadatenaufgaben nach einem Neustart, der Neuerstellung eines Containers oder einer neuen Automatisierung dupliziert? Notieren Sie Aufgabenname, Startzeit, Container-ID, Scheduler, überwachten Ordner und Ausgabe, bevor Sie etwas deaktivieren. Die sichere Lösung besteht darin, sich überschneidende Zuständigkeiten zu entfernen, statt einen doppelten Eintrag zu verbergen.

Finden Sie jeden Scheduler, der dieselbe Aufgabe starten kann

Prüfen Sie geplante Jellyfin-Aufgaben, Neustart-Hooks des Containers, Cron- oder systemd-Timer auf dem Host, die Nachverarbeitung des Download-Managers und alle Sidecars, die die API aufrufen. Vergleichen Sie Zeitstempel und Prozess-IDs zweier Durchläufe. Wenn beide Aufgaben beim selben Ereignis starten, deaktivieren Sie den sekundären Auslöser und lassen Sie die primäre Aufgabe unverändert.

Jellyfin-Aufgaben können regelmäßig oder manuell ausgeführt werden, und Startaufgaben können ausgeführt werden, bevor eine Netzwerkfreigabe bereit ist (Referenz zur Aufgabenterminierung). Behandeln Sie die Bereitschaft des Mounts als Voraussetzung, statt einen zweiten Import als Ausgleich zuzulassen.

Prüfen Sie, ob das Duplikat nach dem Start, einem Webhook oder einem manuellen Wiederholungsversuch erscheint. Der Auslöser grenzt den Verantwortlichen ein, der deaktiviert werden muss. Alle geplanten Aufgaben abzuschalten, verbirgt die Ursache, verhindert aber keine erneute Wiederholung.

Geben Sie jedem Pfad genau einen Schreibprozess und eine stabile Identität

Stellen Sie sicher, dass nur ein Downloader oder Importer Dateien in die Bibliothek verschiebt, und dass jeder Container denselben kanonischen Pfad sieht. Zwei Container mit unterschiedlichen Zuordnungen können dieselbe Datei als zwei Identitäten importieren. Vergleichen Sie vor dem Löschen von Daten Inode, Prüfsumme, Pfad und Besitzrechte eines Duplikatpaars.

Wenn die Quelldatei umbenannt oder neu formatiert wird, kann Jellyfin sie als neues Element statt als Aktualisierung erkennen. Führen Sie einen kontrollierten Verschiebevorgang durch, starten Sie genau einen Scan und überprüfen Sie die erwartete Anzahl der Elemente, bevor Sie die Automatisierung wieder aktivieren.

Vergleichen Sie die Labels und überwachten Pfade der tatsächlich laufenden Container, nicht nur die Konfigurationsdatei auf dem Datenträger. Ein alter Container kann nach einer neuen Bereitstellung weiterhin einen veralteten Überwacher aktiv halten.

Überprüfen Sie die Vermeidung von Duplikaten nach Neustarts und Wiederholungen

Starten Sie den Stack nach der Änderung eines Auslösers neu und lassen Sie das geplante Zeitfenster einmal eintreten. Bestätigen Sie einen Prozess, ein Importereignis, eine Datenbankänderung und eine endgültige Datei. Wiederholen Sie anschließend einen fehlgeschlagenen oder unterbrochenen Durchlauf, um zu überprüfen, dass der Wiederholungsversuch keine zweite Kopie startet.

Leiten Sie den Fall weiter, wenn Duplikate trotz eines Schedulers und eines Pfads bestehen bleiben, die Datenbank widersprüchliche Identitäten enthält oder ein Plugin Aufgaben wiederholt neu erstellt. Bewahren Sie die ursprünglichen Medien und die Datenbanksicherung auf, bis die Bereinigung und der Präventionstest erfolgreich abgeschlossen sind.

Führen Sie nach dem Entfernen des sekundären Schreibprozesses einen normalen Import und einen unterbrochenen Wiederholungsversuch durch. Das erwartete Ergebnis ist ein Datenbankereignis und eine endgültige Datei für jedes Quellelement.

Bestätigen Sie die Präventionsregel nach dem Neustart

Starten Sie den Stack neu und warten Sie ein geplantes Zeitfenster lang, während nur der ausgewählte Scheduler aktiviert ist. Protokollieren Sie Prozess, Pfad und Datenbankereignis, damit die Zuständigkeitsgrenze nachvollziehbar bleibt.

Behalten Sie die Konfiguration bei, wenn ein Wiederholungsversuch keinen zweiten Import startet und die Bibliothek ein gültiges Element enthält. Aktivieren Sie jeweils nur eine Automatisierung erneut, wenn ein weiterer Dienst erforderlich ist.

Leiten Sie den Fall weiter, wenn Duplikate trotz eines Schreibprozesses zurückkehren, die Datenbank widersprüchliche Identitäten enthält oder ein Plugin deaktivierte Aufgaben erneut erstellt.

Support & Tipps

Mehr zum Lesen

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.