Waarom verwerkt Immich bestaande gegevens opnieuw na een upgrade?

Immich kan bestaande assets opnieuw verwerken wanneer een upgrade de code, modellen, metadata of regels voor afgeleide gegevens wijzigt die bepalen wat als actuele uitvoer geldt.

De oorspronkelijke foto's zijn niet gewijzigd, maar miniaturen, embeddings, gezichten, voorbeelden of databasegegevens voldoen mogelijk niet langer aan de nieuwe versie. Hieronder volgt een afgebakende uitleg van welke uitvoer ongeldig is verklaard, welke wachtrij deze opnieuw genereert en of het werk eenmalig wordt voltooid of zich abnormaal herhaalt.

Een upgrade kan veranderen wat als actuele uitvoer geldt

Gegenereerde gegevens zijn geldig in relatie tot de code, het model, de instellingen en het schema waarmee ze zijn geproduceerd. Wanneer die verwachtingen veranderen, worden bestaande miniaturen, embeddings, gezichtsresultaten of metagegevens mogelijk niet langer als actueel beschouwd. De asset blijft de invoer, ook al hoeft alleen de afgeleide weergave opnieuw te worden verwerkt.

Het Immich-back-upartikel van ZimaSpace maakt onderscheid tussen essentiële originelen en de databasestatus enerzijds en afgeleide gegevens die opnieuw kunnen worden gegenereerd anderzijds. Dat onderscheid verklaart waarom werk na een upgrade omvangrijk kan zijn zonder dat dit betekent dat oorspronkelijke bestanden zijn gedupliceerd: de applicatie kan afgeleide gegevens rond ongewijzigde media opnieuw opbouwen.

Noteer welke wachtrijen direct na de upgrade groeien en welke mappen of databasegroottes veranderen. Een miniaturenwachtrij, een machinelearningwachtrij en een databasemigratie vertegenwoordigen verschillende mechanismen. Door ze allemaal “herindexeren” te noemen, verdwijnt het bewijs dat nodig is om de duur en de druk op bronnen in te schatten.

Wijzigingen in afhankelijkheden en modellen kunnen eerder werk ongeldig maken

Immich omvat applicatiecode, databasegedrag, coördinatie van wachtrijen, machinelearningmodellen en media-afgeleiden. Een upgrade kan interfaces of verwachtingen over de opgeslagen weergave tussen deze componenten wijzigen. Een migratie kan records snel bijwerken, waarna achtergrondwerkers later voor elke getroffen asset kostbare uitvoer opnieuw genereren.

Een communitydiscussie over de voorbereiding op Immich v3 benadrukt de onzekerheid rond PostgreSQL, Redis, vectoruitbreidingen en applicatieversies. De discussie bewijst geen specifieke upgradeactie, maar laat wel zien dat compatibiliteit van afhankelijkheden deel uitmaakt van de statusovergang en geen losstaand onderhoudsdetail is.

Bewaar de versies van de componenten vóór de upgrade en een momentopname van de wachtrijen na de upgrade. Als slechts één uitvoerklasse wordt ingepland en één keer wordt voltooid, komt dat overeen met afgebakende regeneratie. Als componenten het niet eens zijn over schema's of uitbreidingen, kunnen zich herhaalde fouten voordoen voordat nuttige herverwerking überhaupt begint.

Herverwerking zet compatibiliteitswerk om in druk op bronnen

Een grote bibliotheek kan één gewijzigde regel omzetten in duizenden taken. Het genereren van miniaturen en media-analyse verbruiken CPU of versnellers, terwijl het lezen van originelen en schrijven van afgeleide gegevens opslagbandbreedte verbruiken. Database-updates en wachtrijactiviteit gaan gelijktijdig door, waardoor bladeren kan vertragen, zelfs wanneer de herverwerking gezond verloopt.

Een ondersteuningsthread over Immich meldt een hoge nachtelijke CPU-belasting en het opnieuw genereren van miniaturen na een update op twee servers. Het gaat om een praktijkrapport en niet om bewijs van bedoeld gedrag, maar het levert wel precies het waarnemingspatroon dat moet worden gecontroleerd aan de hand van de voortgang van wachtrijen, logboeken en de vraag of het proces opnieuw begint.

Volg het aantal voltooide items per minuut, de beschikbare opslagruimte, de apparaatlatentie, de geheugendruk en een vaste interactieve aanvraag. Gezonde herverwerking moet een eindige achterstand verkleinen. Door de gelijktijdigheid te verlagen, kan huishoudelijk gebruik worden beschermd, maar duurt het proces langer; extra werkers kunnen de druk op opslag of database vergroten wanneer die fasen de limiet al bepalen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Maak onderscheid tussen eenmalige regeneratie en een terugkerende fout

Sla vóór de upgrade aantallen taken, versies, beschikbare opslagruimte en de identificatiegegevens van enkele bekende assets op. Neem daarna steekproeven van dezelfde identificatiegegevens en noteer welke uitvoer opnieuw wordt opgebouwd, of de aantallen in de wachtrij dalen en of het werk terugkeert na een herstart of tijdens het volgende geplande onderhoudsvenster.

Een discussie over het herstellen van miniaturen meldt dat ontbrekende afbeeldingen zichtbaar werden nadat de verwerking uiteindelijk was voltooid, terwijl handmatig vernieuwen bij sommige afzonderlijke assets hielp. De gemengde meldingen benadrukken de grens: alleen verstreken tijd is onvoldoende om het gedrag te classificeren; eindige voortgang in een wachtrij verschilt van dezelfde assets die herhaaldelijk falen of opnieuw aan de wachtrij worden toegevoegd.

Beschouw gestaag dalende wachtrijen met stabiele uitvoer als eenmalige regeneratie. Schaal op wanneer het aantal voltooide items wordt teruggezet, dezelfde assets terugkeren, fouten zich herhalen, de beschikbare opslagruimte instort of er geen nuttige verwerkingscapaciteit zichtbaar is. Bewaar back-ups en logboeken voordat je de taakstatus wijzigt, omdat het verwijderen van bewijs kan verhullen of de upgrade of de omgeving de lus heeft veroorzaakt.