Varför tar det lång tid innan nyligen importerade Immich-foton blir sökbara?

Nya foton blir vanligtvis sökbara när bakgrundsbehandlingen har hunnit ikapp, men jobb som har stannat och sökfilter kan ge liknande symtom med saknade resultat.

En telefon har slutfört uppladdningen av ett semesteralbum till familjens server, men en sökning efter stranden returnerar bara äldre bilder. De saknade resultaten kan vänta på analys, ha misslyckats i ett tidigare behandlingssteg eller ha filtrerats bort av den aktuella sökfrågan. Det är viktigare att skilja mellan dessa tillstånd än att bedöma hela importen utifrån en enda sökning som inte gav några resultat.

Ett uppladdat foto kan fortfarande vänta på att bli sökbart

En godkänd uppladdning, en synlig bild i tidslinjen och en färdig post för semantisk sökning är olika milstolpar. Bakgrundsarbete gör att servern kan ta emot förfrågningar utan att slutföra varje analyssteg synkront. Denna uppdelning ger större flexibilitet, men innebär också att uppladdningsräknaren ensam inte kan tala om för en familj när varje ny bild kommer att matcha en sökning med naturligt språk.

Separata jobbköer gör denna skillnad synlig. En utvecklare som byggde en visualisering av Immich-kön visar väntande, aktiva och slutförda jobb tillsammans med diagram över behandlingstakten. Den viktiga poängen är inte själva extraverktyget, utan att flera behandlingsaktiviteter har oberoende förlopp. Därför behöver en period med lugn överföring inte betyda att biblioteket är färdigbehandlat.

För en illustrativ kö tar 12 000 väntande kvalificerade jobb, som behandlas med en jämn takt på 100 per minut, ungefär 120 minuter efter att inflödet har upphört. Om ytterligare 80 tillkommer varje minut är den faktiska avverkningen bara 20 per minut. Verkliga jobb skiljer sig åt i kostnad, så denna beräkning förklarar köbeteende snarare än förutsäger när Immich blir färdigt.

Tre olika tillstånd kan se ut som samma fördröjning

Skilj mellan tre tillstånd: en kö som medvetet väntar, en kö som gör långsamma framsteg och jobb som upprepade gånger misslyckas innan den nödvändiga utdata finns. Det första tillståndet innebär att kön inte har tillåtelse att köras, det andra att genomströmningen är otillräcklig i förhållande till inflödet och det tredje att tid går förlorad på grund av ett specifikt fel. Ett stort antal väntande jobb kan förekomma i alla tre fallen.

Ett rapporterat tidsgränsöverskridande vid metadataextrahering illustrerar det tredje tillståndet och bevisar inte någon generell begränsning hos maskinvaran. Rapportören såg fel efter 120 sekunder för videor i ett NFS-baserat bibliotek, medan extrahering på värddatorn av samma filer gick snabbt. Den kontrasten pekar på en skillnad i behandlingsvägen; den visar inte att all NAS-lagring eller alla stora importer beter sig så.

Om mängden väntande arbete minskar samtidigt som antalet fel förblir stabilt, är fördröjd täckning förenlig med en kö som håller på att tömmas. Om mängden inte minskar bör du först skilja mellan pausat arbete och aktiva fel innan du kallar systemet överbelastat. Detta är en gränsdragning mellan olika orsaker, inte en rekommendation att rensa köer, starta om alla tjänster eller köra om hela familjesamlingen.

Sökningens omfattning kan efterlikna ofullständig indexering

När behandlingsstatusen är känd bör du hålla konto, albumomfattning, datumfilter och sökfråga oförändrade. Om du söker från ett annat konto i hushållet kan resultaten som får visas ändras även på samma server. En semantisk sökning rangordnar dessutom likhet i stället för att garantera en exakt inventering, så att en saknad visuell träff i sig inte bevisar ofullständig indexering.

Saknade HEIC-förhandsvisningar skapar ytterligare en oklarhet: originalet kan finnas kvar medan den visningsversion som skapats från det saknas. Format, avkodarens beteende eller en viss bildprofil kan påverka den vägen. En saknad bildruta och en saknad sökvektor är olika observationer, även när samma fotografi ger användaren båda problemen.

Förklaringen med en normal kö gäller inte längre när samma lilla delmängd konsekvent misslyckas efter att resten av gruppen har slutförts. Omvänt pekar en lyckad sökning efter en känd tillgång tillsammans med en svag semantisk träff mot sökningens relevans eller modellens beteende. Importera inte originalen igen bara för att den första formuleringen av en sökning inte hittade dem.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Använd en liten grupp för att skilja väntan från att arbetet har stannat

Välj en liten uppsättning nyimporterade tillgångar med identifierbara datum och varierat innehåll, samt en äldre uppsättning som du redan vet fungerar. Anteckna när varje original godkänns, när förhandsvisningen öppnas, när relevanta jobb slutförs och om en fast sökfråga hittar det. Upprepa mätningarna vid noterade tidpunkter utan att ändra modeller eller starta en fullständig ombehandling av biblioteket.

Import schemaläggning kan medvetet skjuta upp bakgrundsarbete. En version av immich-go införde pausning av jobb under uppladdningar för att undvika samtidiga konflikter vid metadatauppdateringar. Det är belägg för en specifik policy vid massimport, inte ett bevis på att den inbyggda mobilappen pausar jobb på samma sätt. Anteckna därför vilken importör och version som faktiskt skapade gruppen.

Tolka stigande antal slutförda jobb tillsammans med stabila resultat för äldre objekt som att systemet håller på att komma ikapp, upprepade fel på samma filer som ett behandlingsproblem och olika resultat mellan konton som en fråga om sökningens omfattning. Eskalera med dessa observationer och versionsuppgifter om framstegen upphör. En användbar diagnos avgränsar det felande steget utan att radera bevisen eller ändra flera variabler samtidigt.