Intermitterende Immich-fouten tijdens een grote mobiele import betekenen meestal dat één laag problemen ondervindt door overlappende belasting, niet dat de hele bibliotheek of elk geüpload bestand beschadigd is.
Grote imports combineren gedrag van mobiele achtergrondprocessen, langdurige verzoeken, limieten van reverse proxies of tunnels, databasebewerkingen, opslag-I/O, verwerking van miniaturen en video’s, en wachtrijen voor machine learning. Verzamel eerst een kleine groep mislukte items en de bijbehorende tijdstippen. Bepaal vervolgens of de fout begint op de telefoon, in het netwerkpad, op de applicatieserver of bij een overbelaste afhankelijkheid.
Classificeer de foutgroep voordat je alles opnieuw probeert
Groepeer fouten op mediatype, bestandsgrootte, bronapparaat, netwerkpad en tijdstip. Als alleen grote video’s mislukken, onderzoek dan eerst de verzoekduur en uploadlimieten voordat je naar de CPU kijkt. Als willekeurige foto’s en video’s tijdens dezelfde drukke intervallen mislukken, worden gedeelde serverbronnen of netwerkinstabiliteit waarschijnlijkere oorzaken.
Een rapport uit 2026 van een Immich-gebruiker over veel mobiele uploadfouten is nuttig omdat het laat zien hoe een grote achterstand op een telefoon herhaalde fouten kan veroorzaken waarvoor diagnose per item en per netwerkpad nodig is. Het bewijst niet dat er één universele fout in de mobiele client zit.
Kies niet meteen “alles opnieuw proberen” als eerste diagnostische actie. Bewaar tien namen of ID’s van mislukte items, één succesvol controle-item en de bijbehorende vensters in de client- en serverlogboeken. Met een kleine, bekende groep kun je wijzigingen testen zonder een nieuwe foutgolf te veroorzaken die het oorspronkelijke bewijs verbergt.
Vergelijk lokale uploads met het normale externe pad
Upload dezelfde kleine en grote testbestanden via stabiele lokale wifi rechtstreeks naar het vertrouwde lokale eindpunt en herhaal dit vervolgens via de gebruikelijke externe hostnaam, VPN, tunnel of reverse proxy. Houd het account en het bestand gelijk, zodat de route de belangrijkste variabele blijft.
Een rapport over fouten bij back-ups van grote bestanden laat zien waarom limieten voor verzoeken in proxies of tunnels in deze onderzoekstak thuishoren. De genoemde service en drempelwaarden zijn specifiek voor die implementatie; de algemene test is of een directe lokale overdracht slaagt terwijl het externe pad consequent faalt.
Als beide paden bij dezelfde bestanden falen, volg dan het bewijs uit de server- en opslaglagen. Als alleen het externe pad faalt, controleer dan de maximale bodygrootte, buffering van verzoeken, time-outs voor inactiviteit en lezen, TLS-beëindiging, overgangen tussen mobiele netwerken en hertransmissies. Het aanpassen van de gelijktijdigheid van miniaturen herstelt geen verzoek dat Immich nooit volledig bereikt.
Breng fouten in verband met groeiende wachtrijen en overbelasting van bronnen
Grote imports kunnen uploads blijven accepteren terwijl achtergrondtaken zich opstapelen. Observeer CPU-gebruik, geheugendruk, I/O-latentie van blokapparaten, database-responsiviteit, herstarts van containers en voltooide taken tijdens het foutvenster. Hoog gebruik alleen is geen bewijs; de metriek moet tegelijk met de fouten veranderen.
Het Docker-artikel over CPU-, geheugen-, netwerk- en schijfmetingen van containers laat zien waarom het nuttig is containers onderling te vergelijken in plaats van één gemiddelde voor de hele host te bekijken. Combineer op Linux containerstatistieken met gegevens over opslag en geheugendruk op de host voor dezelfde tijdstippen.
Als geheugendruk ervoor zorgt dat containers afsluiten, de opslaglatentie stijgt samen met uploadfouten of de reactietijd van de database piekt terwijl de wachtrij niet meer vordert, verlaag dan alleen de verantwoordelijke belasting of gelijktijdigheid en herhaal de vaste groep. Als de bronmetingen stabiel blijven, ga dan verder met de applicatielogboeken en de diagnose van het netwerkpad.
Beschouw het foutpercentage en de staartlatentie als signalen van belasting
Een systeem kan op basis van de gemiddelde responstijd gezond lijken, terwijl een klein percentage verzoeken tijdens pieken een time-out krijgt. Noteer het aantal pogingen, het aantal mislukte uploads, de mediane responstijd en de tragere verzoeken in een gecontroleerd tijdvenster. Zo wordt “intermitterend” meetbaar in plaats van anekdotisch.
Het raamwerk voor belastingtests in fout- en latent analyse adviseert om statusklassen, verbindingsproblemen, verdelingen en correlaties in tijdreeksen te analyseren. Je hoeft de familiebibliotheek niet agressief te belasten; gebruik dezelfde analysemethode voor de werkelijke importsnelheid.
Als het aantal fouten sterk afneemt wanneer je de aankomstsnelheid verlaagt en elk afzonderlijk bestand slaagt, heeft de huidige stack onvoldoende capaciteit voor die intensiteit van importeren. Als dezelfde bestanden zelfs één voor één mislukken, is het probleem bestandsspecifiek, pad specifiek of een deterministische softwarefout, en geen algemene overbelasting.
Verminder één bron van druk en test hetzelfde importpatroon opnieuw
Kies de veiligste wijziging die door het bewijs wordt ondersteund: verlaag één achtergrondconcurrentie, pauzeer een andere zware container, gebruik de lokale route, verplaats de import buiten een back-upvenster of corrigeer een proxy-time-out. Wijzig niet tegelijk CPU-limieten, opslag, proxyregels en appversies.
De ZimaSpace-werkwijze voor onderbrekingen bij het maken van back-ups van telefoonfoto’s biedt de mobiele onderzoekstak: planning van achtergrondtaken, originelen die alleen in de cloud staan en veranderende netwerkomstandigheden kunnen uploads onderbreken, zelfs wanneer de server gezond is.
De test is geslaagd wanneer de vaste groep succesvol wordt verwerkt en dezelfde grotere import draait met een stabiel foutpercentage, voortschrijdende wachtrijen en acceptabele interactieve prestaties. Schakel hulp in wanneer fouten bij lage belasting blijven optreden of zich bij dezelfde bestanden herhalen; voeg clientlogboeken, serverlogboeken, proxystatus, grafieken van bronnen, bestandstype en -grootte en het eerste mislukte verzoek toe.
Ondersteuning & Tips
Meer om te lezen

Hoe optimaliseer je Immich-databaseverbindingen voor gelijktijdige containers?
Verhoog max_connections niet als eerste. Meet de Immich-sessies, tel de vraag van elke container bij elkaar op, behoud ruimte voor beheerders en stem alleen...

Dubbele taken of imports in Immich voorkomen
Scheid herhaalde taken van dubbele assets. Gebruik één canoniek ingestiepad, beheer retries en padwijzigingen en test vervolgens opnieuw invoeren op een kleine groep.

Immich herstellen nadat het databasevolume vol raakt
Verwijder nooit PostgreSQL-WAL om ruimte vrij te maken. Stop schrijfbewerkingen van Immich, behoud de databasestatus, voeg veilig extra opslagcapaciteit toe, herstel PostgreSQL en voorkom...

