So verhindern Sie doppelte Jobs oder Importe in Immich

Eva Wong

IceWhale author

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.

How to Prevent Duplicate Jobs or Imports in Immich - Zima Store Online

Verhindern Sie doppelte Immich-Aufträge oder -Importe, indem Sie zunächst zwei unterschiedliche Symptome auseinanderhalten: dieselbe Hintergrundarbeit, die erneut ausgeführt zu werden scheint, und dasselbe Foto, das zu mehr als einem Asset wird. Ermitteln Sie anschließend, welcher Client, Importer, Bibliotheksscan, welche Pfadänderung oder welcher erneute Versuch das zweite Ereignis ausgelöst hat, bevor Sie etwas löschen.

Das sicherste Konzept weist jeder Asset-Gruppe einen kanonischen Aufnahmeweg zu. Ein historisches Cloud-Archiv, eine externe Bibliothek und ein aktives Telefon-Backup können alle sinnvoll sein, doch eine überlappende Zuständigkeit für dieselben Dateien kann doppelte Datensätze oder Schleifen durch erneute Uploads erzeugen, die sich nach dem Import nicht zuverlässig bereinigen lassen.

Ermitteln Sie, ob sich Vorgänge wiederholen oder Assets doppelt vorhanden sind

Halten Sie bei wiederholten Aufträgen den Namen der Warteschlange, die Asset-ID, die Startzeit, den Abschluss-/Fehlerstatus und das Ereignis fest, das dem neuen Auftrag vorausging. Ein legitimer nachgelagerter Auftrag nach einer Metadatenverarbeitung unterscheidet sich davon, dass derselbe fehlgeschlagene Auftrag endlos wiederholt wird. Leeren Sie nicht alle Warteschlangen, bevor Sie wissen, welches Muster vorliegt.

Vergleichen Sie bei doppelten Assets die Quellbibliothek, den ursprünglichen Pfad, das Verhalten der Prüfsumme, sofern verfügbar, den Status des Geräte-Backups, den Aufnahmezeitpunkt und die Dateigröße. Dasselbe sichtbare Bild kann nach einem Cloud-Export, Metadatenänderungen, einer Transkodierung oder durch die pfadbasierte Verarbeitung externer Bibliotheken als zwei unterschiedliche Dateien vorliegen, während byteidentische Dateien auch in verschiedenen Immich-Bibliotheksquellen vorhanden sein können.

Wenn bei gewöhnlichen Uploads wiederholt Prüfsummen- oder Unique-Constraint-Fehler auftreten, bewahren Sie die Datenbank und prüfen Sie zunächst den Status von Migrationen und Schema, statt das Symptom als Problem der Importquelle zu behandeln. Doppelte Assets in zwei legitimen Quelltypen und ein Fehler aufgrund einer Datenbankbeschränkung sind unterschiedliche Fälle und sollten nicht auf dieselbe Weise bereinigt werden.

Der ZimaSpace-Leitfaden zum Status des Telefon-Backups und zur mobilen Zeitplanung ist hilfreich, weil ein mobiler Client eine eigene Ansicht davon hat, welche Dateien noch gesichert werden müssen. Eine serverseitige Bereinigung, die den Clientstatus ignoriert, kann dazu führen, dass die nächste Telefonsitzung die Dateien erneut sendet.

Verwenden Sie für jede vorhandene Fotogruppe einen einzigen kanonischen Aufnahmeweg

Legen Sie fest, wie alte Fotos in Immich gelangen, bevor Sie das kontinuierliche Telefon-Backup aktivieren: Importieren Sie beispielsweise das historische Archiv einmal, überprüfen Sie es und lassen Sie das Telefon anschließend nur neue Aufnahmen beisteuern. Wenn dieselben historischen Dateien sowohl als externe Bibliothek eingebunden als auch über die normale Upload-Bibliothek hochgeladen werden, sollten Sie nicht davon ausgehen, dass eine globale Deduplizierung die beiden Quellen miteinander abgleicht.

Ein Bericht über quellenübergreifende Duplikate in Immich dokumentiert, dass identische Inhalte nebeneinander bestehen können, wenn sie aus einer externen Bibliothek und der Upload-Bibliothek stammen. Betrachten Sie dies als Grenze des Projektverhaltens: Die Quellzugehörigkeit ist entscheidend, daher ist Vorbeugung zuverlässiger, als darauf zu hoffen, dass ein späteres Duplikatwerkzeug Ihre bevorzugte Kopie erkennt.

Vermeiden Sie es, Dateien, die Immich intern hochgeladen hat, hinter seinem Rücken in eine externe Bibliothek zu verschieben, während das Telefon sie weiterhin als Teil seiner Backup-Menge betrachtet. Wenn die Speicherarchitektur geändert werden muss, führen Sie die Migration über einen dokumentierten Weg mit Backups und einer kleinen Testgruppe durch. Vergewissern Sie sich anschließend, dass die mobile App und der Server übereinstimmen, bevor Sie die alte Kopie löschen.

Kontrollieren Sie Wiederholungen und den Clientstatus, bevor Sie den Import skalieren

Verwenden Sie für einen großen manuellen Import ein Staging-Manifest: Erfassen Sie Quellpfad, Dateianzahl, Gesamtgröße und nach Möglichkeit eine stabile Prüfsumme oder das Ergebnis des Importers. Wenn ein Import unterbrochen wird, setzen Sie ihn mit demselben Werkzeug und Ziel fort, anstatt einen zweiten unabhängigen Importer gegen dieselbe Quelle zu starten, solange der Status des ersten Auftrags unklar ist.

Ein aktueller Bericht über wiederholte Uploads zu Immich zeigte, dass ein mobiler Client Assets, die bereits auf dem Server vorhanden waren, kontinuierlich erneut versuchte und auf dem Server Unique-Constraint-Fehler auftraten. Betrachten Sie dies als versionsbezogenen Hinweis darauf, dass der Status des Client-Backups der Verursacher der Schleife sein kann; verallgemeinern Sie es nicht zu einem universellen Verhalten der mobilen App. Pfadänderungen bleiben ein separates Risiko. Halten Sie die in Containern sichtbaren Pfade externer Bibliotheken während eines großen Imports stabil. Wenn ein Speicherumzug erforderlich ist, migrieren Sie zunächst eine kleine Gruppe. Wenn die zweite Kopie erst nach einer Pfadänderung erscheint, folgen Sie dem Pfadidentitäts-Zweig, statt den Status des Telefon-Backups zurückzusetzen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Testen Sie Unterbrechung, Wiederholung und ein tatsächlich neues Asset

Erstellen Sie eine kleine repräsentative Gruppe mit gewöhnlichen Fotos, Videos, einem bearbeiteten Bild und mindestens einer Datei, die am Zielpfad bereits vorhanden ist. Importieren Sie sie einmal, erfassen Sie anschließend Asset-Anzahlen und IDs und unterbrechen Sie dann einen zweiten kontrollierten Versuch oder Scan gemäß dem Workflow, den Sie in der Produktion verwenden möchten.

Der Test ist erfolgreich, wenn für dasselbe beabsichtigte Quellobjekt kein unerklärliches zweites Asset entsteht, sich Wiederholungen einpendeln, ohne dass die Warteschlange dauerhaft wächst, und ein tatsächlich neues Foto weiterhin erfolgreich importiert wird. Öffnen Sie nach dem Test außerdem den mobilen Client erneut, damit sein Backupstatus nicht unbemerkt vom Server abweicht.

Wenn Duplikate nur zwischen Upload- und externen Bibliotheksquellen zurückkehren, gestalten Sie die Zuständigkeitsgrenze neu, anstatt sie wiederholt zusammenzuführen. Wenn dieselbe Asset-ID einen fehlgeschlagenen Auftrag endlos erhält, isolieren Sie diesen Auftrag und die betreffende Datei. Eskalieren Sie den Fall mit Quelltyp, Pfaden, gegebenenfalls Hashes, Versionen, dem Backupstatus des Clients und der kleinsten reproduzierbaren Gruppe.