Kan Immich het zoeken naar foto's bruikbaar houden tijdens grote imports vanaf mobiele apparaten?

Ja, Immich kan bestaande fotosuche tijdens imports bruikbaar houden wanneer gedeelde resources voldoende capaciteit overhouden, al kunnen nieuw geüploade foto's pas later doorzoekbaar worden.

Een huishouden importeert jarenlang gemaakte telefoonfoto's terwijl iemand naar een ouder verjaardagsalbum zoekt. Dat bekende album snel terugvinden en elke foto die deze minuut is geüpload kunnen vinden, zijn verschillende beloften. Beoordeel beide afzonderlijk, omdat achtergrondverwerking achterop kan raken zonder bestaande zoekfuncties offline te halen, terwijl resourceconflicten zelfs eerder geïndexeerde resultaten traag kunnen maken.

Bestaande zoekresultaten en nieuwe dekking zijn verschillende beloften

Bestaande geïndexeerde items bevatten al de informatie die nodig is voor de ondersteunde zoekmethode. Nieuw geaccepteerde uploads hebben mogelijk nog metadata-extractie, voorbereiding voor weergave en relevante indexeringstaken nodig. Een geslaagde upload betekent daarom niet dat semantisch zoeken direct mogelijk is en evenmin dat alle zoekfuncties het item al volledig hebben verwerkt.

Uit eerstehands meldingen over grote bibliotheken blijken sterk uiteenlopende importervaringen op kleine boards en grotere machines, waaronder installaties die bruikbaar bleven terwijl de verwerking doorging. Die ervaringen tonen variatie aan en geen minimale RAM-regel. De mediamix, ingeschakelde taken, gelijktijdige services en aanvaardbare wachttijd zijn naast het aantal foto's van belang.

Het voorwaardelijke antwoord is ja wanneer een bekende zoekopdracht nog binnen de tolerantie van het huishouden de verwachte resultaten oplevert en nieuwe items verder worden verwerkt. Voor actualiteit wordt het antwoord nee als de indexering niet meer vordert, zelfs wanneer oude zoekopdrachten werken. Omgekeerd bewijst een groeiende wachtrij op zichzelf niet dat de interactieve service onbeschikbaar is geworden.

Meer importwerk kan interactieve capaciteit verbruiken

Uploads, het genereren van afgeleide bestanden, databasebewerkingen en inferentie verbruiken deels dezelfde resources. Door de gelijktijdigheid van achtergrondtaken te verhogen, kunnen er per minuut meer taken worden voltooid totdat een gedeelde afhankelijkheid verzadigd raakt; daarna kan extra wachttijd interactieve verzoeken juist schaden. Een hogere importsnelheid en een tragere zoekervaring kunnen dus tegelijkertijd op dezelfde host voorkomen.

Een versiegebonden melding over de importtool beschreef dat taakpauzeknoppen niet elke actieve wachtrij dekten bij immich-go 0.28.0 en Immich 2.3.1. De melder stelde niet vast dat dit de waargenomen verbindingsfouten veroorzaakte. De nuttige les is beperkter: een label van een bedieningselement bewijst niet dat al het achtergrondwerk daadwerkelijk is gepauzeerd.

Minder achtergrondwerk inplannen tijdens gezinsgebruik ruilt de voltooiingstijd in voor mogelijk meer interactieve capaciteit; het creëert geen extra capaciteit. Bekijk de actieve wachtrijen en de voor gebruikers zichtbare tijden na een ondersteunde wijziging. Als zoeken traag blijft terwijl die wachtrijen niet actief zijn, onderzoek dan het resterende zoekpad in plaats van elke vertraging aan gelijktijdige import toe te schrijven.

ML-versnelling beschermt niet elke afhankelijkheid

Inferentie verplaatsen naar een versneller of een andere host verandert één servicegrens. Het versnelt PostgreSQL, het lezen van originele media, het genereren van miniaturen of het renderen door de client niet automatisch. Een snelle machine-learningstap kan samengaan met een overbelaste database of opslagpool, en een externe service brengt zijn eigen netwerk- en beschikbaarheidsafhankelijkheid mee.

Een rapport over OCR-resources voor Immich 2.2.0 beschreef snelle verwerking van gezichten en slim zoeken, maar veel zwaarder OCR-gedrag met een bepaald model en in een bepaalde omgeving. Dit is een historisch incident en geen universeel huidig defect. Het laat zien waarom de snelheid of geheugenbehoefte van één ML-taak niet kan gelden als maatstaf voor elke ingeschakelde taak.

De beschikbaarheidsclaim gaat niet op wanneer vereiste services onder geheugendruk opnieuw starten, query's een time-out krijgen, de opslag geen beschrijfbare ruimte meer heeft of een noodzakelijke netwerkverbinding onbereikbaar wordt. Snellere inferentie alleen kan deze grenzen niet oplossen. Houd privacy ook afzonderlijk: lokale verwerking compenseert niet voor te ruime accounts, blootgestelde eindpunten of een ongeschikte back-upafhandeling.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Bepaal wat bruikbaar betekent voor uw huishouden

Kies een kleine reeks oude zoekopdrachten met bekende resultaten en een nieuw importsample met herkenbare onderwerpen. Noteer de voltooiingstijden van zoekopdrachten, fouten en de vertraging totdat het sample via de beoogde functie doorzoekbaar wordt. Herhaal dit tijdens een rustige periode en tijdens een representatieve import zonder het account, de client of de netwerkroute te wijzigen.

Zelfhosting legt verantwoordelijkheden voor het huishouden bij de servereigenaar, waaronder beslissingen over servicebeschikbaarheid, toegang en back-ups. Dat onderscheid is belangrijk bij het definiëren van bruikbaar zoeken: af en toe vertraging bij het indexeren kan aanvaardbaar zijn, maar elke nacht tijdens een import de toegang verliezen misschien niet. Een cloudvergelijking biedt die context over verantwoordelijkheden, geen prestatiegarantie voor Immich.

Stel afzonderlijke acceptatiegrenzen in voor de latentie van bestaande zoekopdrachten en voor de beschikbaarheid van nieuwe foto's, en controleer of de achterstand wegwerkt nadat uploads zijn gestopt. Als beide slagen, ondersteunt dat voortgezet gebruik onder alleen de geteste werklast. Als een van beide faalt, is de volgende vraag welke afhankelijkheid of overlap in de planning die grens overschrijdt — niet de aanname dat alle grote bibliotheken dezelfde hardware nodig hebben.