Varför bearbetar Immich befintliga data igen efter en uppgradering?
Immich kan bearbeta befintliga tillgångar på nytt när en uppgradering ändrar koden, modellerna, metadata eller reglerna för härledda data som definierar ett aktuellt resultat.
Originalfotona har inte ändrats, men miniatyrbilder, embeddingar, ansikten, förhandsvisningar eller databasposter kanske inte längre uppfyller kraven i den nya versionen. Här följer en avgränsad förklaring av vilket resultat som ogiltigförklarades, vilken kö som återskapar det och om arbetet slutförs en gång eller upprepas onormalt.
En uppgradering kan ändra vad som räknas som ett aktuellt resultat
Genererade data är giltiga i relation till koden, modellen, inställningarna och schemat som skapade dem. När dessa förväntningar ändras kanske en befintlig miniatyrbild, embedding, ansiktsidentifiering eller metadata-post inte längre anses vara aktuell. Tillgången förblir indata, även om endast den härledda representationen behöver bearbetas.
ZimaSpaces Immich-artikel om säkerhetskopiering skiljer mellan viktiga original och databasstatus samt härledda data som kan återskapas. Den skillnaden förklarar varför uppgraderingsarbete kan bli omfattande utan att innebära att originalfilerna har duplicerats: programmet kan bygga om härledd status kring oförändrade medier.
Notera vilka köer som växer direkt efter uppgraderingen och vilka kataloger eller databasstorlekar som ändras. En miniatyrbildskö, en maskininlärningskö och en datasmigrering representerar olika mekanismer. Om alla kallas ”indexering” försvinner den information som behövs för att uppskatta tidsåtgång och resursbelastning.
Ändringar i beroenden och modeller kan ogiltigförklara tidigare arbete
Immich omfattar programkod, databashantering, kökoordinering, maskininlärningsmodeller och härledda mediedata. En uppgradering kan ändra gränssnitt eller förväntningar på lagrade representationer mellan dessa komponenter. En migrering kan uppdatera poster snabbt, medan bakgrundsarbetare senare återskapar resurskrävande resultat för varje berörd tillgång.
En communitydiskussion om förberedelser inför Immich v3 lyfter osäkerhet kring PostgreSQL, Redis, vektortillägg och programversioner. Diskussionen bevisar inte att någon viss uppgraderingsåtgärd krävs, men visar att kompatibilitet mellan beroenden är en del av statusövergången och inte en orelaterad underhållsdetalj.
Spara komponentversionerna före uppgraderingen och en ögonblicksbild av köerna efteråt. Om endast en resultatklass schemaläggs och slutförs en gång stämmer beteendet med avgränsad återskapning. Om komponenterna inte är överens om schema eller tillägg kan upprepade fel uppstå innan någon användbar ombearbetning ens hinner börja.
Ombearbetning förvandlar kompatibilitetsarbete till resursbelastning
Ett stort bibliotek kan förvandla en enda ändrad regel till tusentals jobb. Skapande av miniatyrbilder och medieanalys använder CPU eller acceleratorer, medan läsning av original och skrivning av härledda data belastar lagringsbandbredden. Databasuppdateringar och köaktivitet fortsätter samtidigt, så interaktiv användning kan bli långsammare även när ombearbetningen fungerar som den ska.
En Immich-supporttråd rapporterar hög CPU-belastning nattetid och förnyad generering av miniatyrbilder efter en uppdatering på två servrar. Det är en fältrapport och inte ett bevis på avsett beteende, men den visar exakt vilket observationsmönster som bör jämföras med köernas framsteg, loggarna och om arbetet slutförs eller upprepas.
Följ antalet slutförda objekt per minut, ledigt lagringsutrymme, enhetsfördröjning, minnesbelastning och en fast interaktiv begäran. En hälsosam ombearbetning bör minska en ändlig arbetskö. Om samtidigheten sänks kan användningen i hemmet skyddas på bekostnad av tidsåtgången; fler arbetare kan förvärra belastningen på lagring eller databas när dessa steg redan sätter gränsen.
Skilj engångsvis återskapning från ett återkommande fel
Före uppgraderingen bör du spara jobbantal, versioner, ledigt utrymme och identifierare för flera kända tillgångar. Efteråt kontrollerar du samma identifierare och noterar vilket resultat som byggs om, om köerna minskar och om arbetet återkommer efter en omstart eller vid nästa schemalagda underhållstillfälle.
En diskussion om återställning av miniatyrbilder rapporterar att saknade bilder blev tillgängliga när bearbetningen till slut slutfördes, medan manuell uppdatering hjälpte för vissa enskilda tillgångar. De blandade rapporterna understryker gränsdragningen: enbart förfluten tid räcker inte för att klassificera beteendet; en kö som minskar ändligt skiljer sig från att samma tillgångar upprepade gånger misslyckas eller läggs tillbaka i kön.
Betrakta köer som sjunker kontinuerligt och stabila resultat som engångsvis återskapning. Eskalera när antalet slutförda objekt återställs, identiska tillgångar återkommer, fel upprepas, det lediga utrymmet snabbt försvinner eller ingen användbar genomströmning uppstår. Bevara säkerhetskopior och loggar innan du ändrar jobbstatus, eftersom raderade bevis kan dölja om uppgraderingen eller miljön utlöste loopen.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vilka beroenden sätter oftast den verkliga prestandagränsen för Immich?
Immich begränsas av den långsammaste beroendekomponenten på varje uppmätt sökväg, så uppladdning, sökning, bläddring och uppspelning kan ha olika tak.
Immich-nätverk: Hur upptäckt, DNS och routing skapar åtkomlighet
Immich är endast åtkomligt när val av slutpunkt, DNS, routing, NAT- eller proxyhantering, TLS och applikationssvar bildar en giltig sökväg.
Immich för familjer: Hur identitet och behörigheter formar upplevelsen
Familjeanvändning av Immich bygger på separata identiteter, ägande av material, avsiktlig delning, begränsad administration och testad återkallelse.
