Why Are Newly Imported Immich Photos Slow to Become Searchable?
New photos usually become searchable after background processing catches up, but stalled jobs and search filters can produce similar missing-result symptoms.
A phone has finished uploading a holiday album to the family server, yet a search for the beach returns only older pictures. The missing results might be waiting for analysis, failing at an earlier processing stage, or excluded by the current query. Separating those states matters more than judging the entire import from one search that returned nothing.
An Uploaded Photo Can Still Be Waiting for Search
An accepted upload, a visible timeline tile, and a completed semantic-search record are different milestones. Background work allows the server to accept requests without completing every analysis step synchronously. That separation improves flexibility, but it also means the upload counter alone cannot tell a family when every new image will match a natural-language query.
Separate job queues make this distinction observable. A developer who built an Immich queue visualizer exposes pending, active, and completed work alongside processing-rate graphs. The useful idea is not the additional tool itself: it is that several processing activities have independent progress, so a quiet transfer window need not mean a finished library.
For an illustrative queue, 12,000 pending eligible jobs processed at a steady 100 per minute take about 120 minutes after arrivals stop. If another 80 arrive each minute, the net drain is only 20. Real jobs differ in cost, so this arithmetic explains backlog behavior rather than forecasting an Immich completion time.
Three Different States Can Look Like the Same Delay
Distinguish three states: a queue intentionally waiting, a queue making slow progress, and jobs repeatedly failing before the required output exists. The first has no permission to run; the second has insufficient throughput for the arrival rate; the third loses time to a specific error. A large pending count can occur in all three.
A reported metadata timeout illustrates the third state rather than proving a general hardware limit. The reporter saw 120-second failures for videos on an NFS-backed library while host-side extraction of the same files was fast. That contrast locates a processing-path discrepancy; it does not establish that all NAS storage or all large imports behave that way.
If pending work falls and failures remain stable, delayed coverage is consistent with a draining backlog. If it does not fall, first distinguish paused work from active errors before calling the system overloaded. This is a classification boundary, not a recommendation to clear queues, restart all services, or rerun the entire family collection.
Search Scope Can Mimic Unfinished Indexing
Once the processing state is known, keep the account, album scope, date filter, and query fixed. Searching from a different household account can change the eligible results even on the same server. A semantic query also ranks similarity rather than guaranteeing an exact inventory, so one missing visual match does not by itself prove unfinished indexing.
Missing HEIC previews introduce another ambiguity: an original can be present while its display derivative is unavailable. Format, decoder behavior, or a particular image profile can affect that path. A missing tile and a missing search vector are different observations, even when the same photograph exposes both problems to the user.
The normal-backlog explanation stops applying when the same small subset consistently fails after the rest of the cohort completes. Conversely, a successful known-asset lookup with a weak semantic match points toward query relevance or model behavior. Do not reimport originals merely because the first wording of a search failed to retrieve them.
Use a Small Cohort to Distinguish Waiting From Stalling
Choose a small set of newly imported assets with identifiable dates and varied content, plus an older set already known to work. Record when each original is accepted, when its preview opens, when relevant jobs complete, and whether a fixed query retrieves it. Repeat at recorded intervals without changing models or starting a full-library reprocessing job.
Import scheduling can deliberately defer background work. An immich-go release introduced job pausing during uploads to avoid concurrent metadata-update conflicts. That is evidence of a specific bulk-import policy, not proof that the native mobile app pauses jobs the same way; record which importer and version actually produced the cohort.
Interpret rising completion counts with stable older results as catch-up, repeated failures on the same files as a processing problem, and different results across accounts as a scope question. Escalate with those observations and version details if progress stops. A useful diagnosis narrows the failing stage without deleting the evidence or changing several variables together.
Recommended products
Tech & AI HUB
More to Read
Open Models Are Catching Frontier AIโIs 2026 the Year Local AI Becomes Good Enough?
Open models are getting good enough for more local AI workloads, while frontier cloud models remain useful for the hardest reasoning and agent tasks.
NVIDIA PAIR Turns Your Home Network Into a Local AI ClusterโDo You Still Need One Big GPU Server?
NVIDIA PAIR spreads local AI requests across multiple PCs, making compute more elastic while one home server can keep data and state persistent.
Why Does Immich Feel Faster on LAN Than on Remote Connections?
LAN requests usually take a shorter, lower-latency path. Remote access adds WAN capacity limits and may add DNS, TLS, proxy, VPN, or relay hops.
