Dubbele taken of imports in Immich voorkomen

Voorkom dubbele Immich-taken of imports door eerst twee verschillende symptomen uit elkaar te houden: hetzelfde achtergrondwerk dat opnieuw lijkt te worden uitgevoerd en dezelfde foto die meer dan één asset wordt. Bepaal vervolgens welke client, importer, bibliotheeks scan, padwijziging of nieuwe poging de tweede gebeurtenis heeft veroorzaakt voordat je iets verwijdert.

Het veiligste ontwerp geeft elke assetgroep één canoniek ingestiepad. Een historisch cloudarchief, een externe bibliotheek en een actieve telefoonback-up kunnen allemaal geldig zijn, maar overlappend eigenaarschap van dezelfde bestanden kan dubbele records of herhaalde uploadlussen veroorzaken die je achteraf niet betrouwbaar kunt opruimen.

Bepaal of je te maken hebt met herhaald werk of dubbele assets

Leg bij herhaalde taken de wachtrijnaam, asset-ID, starttijd, voltooiings- of foutstatus en de gebeurtenis vóór de nieuwe taak vast. Een legitieme vervolgt taak die na metadataverwerking wordt aangemaakt, verschilt van dezelfde mislukte taak die eindeloos opnieuw wordt geprobeerd. Wis niet alle wachtrijen voordat je weet welk patroon aanwezig is.

Vergelijk bij dubbele assets de bronbibliotheek, het oorspronkelijke pad, het checksumgedrag waar beschikbaar, de status van de apparaatback-up, de opnametijd en de bestandsgrootte. Dezelfde zichtbare afbeelding kan als twee verschillende bestanden bestaan na een cloudeksport, metadatabewerkingen, transcodering of padgebaseerde verwerking door een externe bibliotheek, terwijl byte-identieke bestanden ook in verschillende Immich-bibliotheekbronnen kunnen bestaan.

Als gewone uploads herhaaldelijk checksum- of unique-constraint-fouten veroorzaken, bewaar dan de database en controleer eerst de migratie- en schemastatus voordat je het symptoom als een probleem met de importbron behandelt. Dubbele assets uit twee legitieme brontypen en een fout met een databaseconstraint zijn verschillende scenario's en mogen niet dezelfde opschoonactie krijgen.

De ZimaSpace-gids over de status van telefoonback-ups en mobiele planning is nuttig omdat een mobiele client zelf bijhoudt wat nog moet worden geback-upt. Opschoning aan de serverzijde die geen rekening houdt met de clientstatus kan ertoe leiden dat de volgende telefoonsessie bestanden opnieuw verzendt.

Gebruik één canoniek ingestiepad voor elke bestaande fotogroep

Kies hoe oude foto's Immich binnenkomen voordat je doorlopende telefoonback-ups inschakelt: importeer bijvoorbeeld het historische archief één keer, controleer het en laat de telefoon daarna alleen nieuwe opnamen aanleveren. Als dezelfde historische bestanden zowel als externe bibliotheek zijn gekoppeld als via de normale uploadbibliotheek worden geüpload, ga er dan niet van uit dat globale deduplicatie de twee bronnen met elkaar in overeenstemming brengt.

Een Immich-rapport over dubbele bestanden tussen bronnen documenteert dat identieke inhoud naast elkaar kan bestaan wanneer die uit een externe bibliotheek en de uploadbibliotheek afkomstig is. Beschouw dit als een grens van het projectgedrag: het bron-eigenaarschap is belangrijk, dus voorkomen is betrouwbaarder dan verwachten dat een latere duplicaatfunctie jouw voorkeurskopie kan afleiden.

Verplaats bestanden die Immich intern heeft geüpload niet buiten de applicatie om naar een externe bibliotheek terwijl de telefoon ze nog als onderdeel van de back-upset beschouwt. Als de opslagarchitectuur moet veranderen, migreer dan via een gedocumenteerd pad met back-ups en een kleine testgroep, en controleer vervolgens of de mobiele app en de server het eens zijn voordat je de oude kopie verwijdert.

Beperk nieuwe pogingen en controleer de clientstatus voordat je de import opschaalt

Gebruik voor een grote handmatige import een stagingmanifest: leg waar praktisch het bronpad, het aantal bestanden, het totale aantal bytes en een stabiele checksum of het resultaat van de importer vast. Als een import wordt onderbroken, hervat je die via hetzelfde hulpprogramma en dezelfde bestemming in plaats van een tweede onafhankelijke importer op dezelfde bron te starten terwijl de status van de eerste taak onzeker is.

Een recent Immich-rapport over herhaalde uploads liet zien dat een mobiele client assets die al op de server stonden voortdurend opnieuw probeerde te uploaden, met unique-constraint-fouten op de server. Beschouw dit als versiegebonden bewijs dat de back-upstatus van de client de lus kan veroorzaken; generaliseer dit niet tot universeel gedrag van mobiele apps. Padwijzigingen vormen een afzonderlijk risico. Houd paden naar externe bibliotheken die in containers zichtbaar zijn stabiel tijdens een grote import en migreer, als een opslagverplaatsing noodzakelijk is, eerst een kleine groep. Als de tweede kopie pas na een padwijziging verschijnt, volg dan het scenario rond padidentiteit in plaats van de telefoonback-upstatus opnieuw in te stellen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Test onderbreking, nieuwe pogingen en een echt nieuwe asset

Maak een kleine representatieve groep met gewone foto's, video's, een bewerkte afbeelding en ten minste één bestand dat al op het bestemmingspad bestaat. Importeer deze één keer, leg de aantallen en ID's van de assets vast en onderbreek daarna een tweede gecontroleerde poging of scan opnieuw volgens de workflow die je in productie wilt gebruiken.

De test is geslaagd als er geen onverklaarde tweede asset voor hetzelfde bedoelde bronobject ontstaat, nieuwe pogingen tot rust komen zonder een permanent groeiende wachtrij en een echt nieuwe foto nog steeds succesvol wordt geïmporteerd. Open na de test ook de mobiele client opnieuw, zodat de back-upstatus niet ongemerkt afwijkt van die op de server.

Als duplicaten alleen terugkomen tussen upload- en externebibliotheekbronnen, herontwerp dan de eigendomsgrens in plaats van ze steeds opnieuw samen te voegen. Als dezelfde asset-ID een eindeloos mislukte taak ontvangt, isoleer die taak en dat bestand. Escaleer met het brontype, paden, hashes waar relevant, versies, de back-upstatus van de client en de kleinst reproduceerbare groep.