Perché Immich smette di restituire le foto private ricercabili dopo un riavvio?

Immich di solito smette di restituire foto private ricercabili dopo un riavvio perché Smart Search ha perso il percorso di machine learning, non ha finito di preparare il modello oppure non riesce a completare i processi e le letture dello spazio di archiviazione che creano gli incorporamenti di ricerca.

Se la cronologia mostra ancora gli originali, probabilmente le foto non sono mancanti; è il livello di ricerca a essere incompleto. Considera innanzitutto un risultato vuoto come un problema del percorso del servizio, conserva il database e la libreria di caricamento, poi distingui un container di machine learning non disponibile dai processi ritardati, da un endpoint non corrispondente o da un problema di autorizzazioni del percorso persistente prima di ricostruire qualsiasi elemento.

Distinguere i risultati di ricerca mancanti dalle foto mancanti

Apri direttamente diversi elementi noti dalla cronologia, dagli album e da una libreria privata prima di testare la ricerca. Se funzionano, il database riesce a individuare i record e Immich può leggere i file; se non funzionano, si tratta di un incidente più ampio della libreria o dello spazio di archiviazione, quindi interrompi le modifiche specifiche alla ricerca e proteggi i percorsi interessati.

Esegui tre ricerche ripetibili: un termine che funzionava in precedenza, un termine visivamente evidente e un elemento caricato di recente dopo il completamento previsto delle attività in background. Registra se i risultati sono vuoti, obsoleti o limitati alle foto più vecchie. Questi esiti distinguono un guasto totale dell'endpoint da un arretrato di indicizzazione.

Una discussione della community raccoglie controlli di Smart Search relativi ai riavvii, inclusi la raggiungibilità dell'endpoint e la riesecuzione dei processi. Usa la sua sequenza diagnostica del livello di ricerca come prova del caso, non come motivo per eliminare il database o rigenerare ogni elemento.

Controllare il percorso di machine learning dopo il riavvio

Controlla lo stato del server e del container di machine learning, quindi testa l'URL configurato per il machine learning dallo spazio dei nomi di rete che lo richiama. Un endpoint raggiungibile con richieste al modello completate correttamente supera questo ramo; il rifiuto della connessione, il mancato rilevamento del nome o un container non integro identificano il percorso del servizio da riparare.

Confronta il nome del servizio distribuito, la porta, il valore dell'ambiente, la versione dell'immagine e l'appartenenza alla rete con l'ultima definizione Compose funzionante. Ricrea solo il container interessato dopo aver corretto la discrepanza. Un semplice riavvio non sostituisce un ambiente obsoleto del container, quindi conferma il valore effettivo nel carico di lavoro ricreato.

Un caso segnalato di Immich v2.6.1 ha collegato il malfunzionamento di Smart Search a un container di machine learning non integro. Il rapporto sul malfunzionamento relativo alla versione supporta il controllo dello stato e dei log; non dimostra che ogni guasto dopo un riavvio sia dovuto a quella regressione.

Controllare la preparazione del modello, i processi e i percorsi persistenti

Controlla i log del machine learning mentre invii una ricerca nota. La prima richiesta potrebbe caricare o scaricare un modello e usare temporaneamente più memoria; un avanzamento seguito da una risposta corretta supera il test. Espulsioni ripetute, terminazioni per esaurimento della memoria o errori di download indicano la necessità di intervenire sulla memoria, sulla persistenza della cache o sulla rete.

Controlla il numero di processi di Smart Search e gli errori recenti senza cancellarli. Se l'endpoint è integro ma i processi rimangono falliti o in coda, ritenta un piccolo lotto controllato e osserva se il numero diminuisce. Se un elemento viene elaborato correttamente, ripara la concorrenza dei worker o la dipendenza non funzionante prima di pianificare una reindicizzazione completa.

Conferma che il database, la libreria di caricamento e la cache del modello montino i percorsi persistenti previsti con l'identità corretta. La guida correlata di ZimaSpace sul comportamento del riconoscimento di Immich aiuta a distinguere l'accesso e l'ambito dell'indicizzazione da un originale mancante.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Applicare la correzione appropriata e ripetere il test dopo due riavvii

Correggi solo la causa confermata: ripristina il nome dell'endpoint, ricrea il container con l'ambiente corretto, rendi persistente la cache del modello, riduci la concorrenza misurata, correggi la proprietà oppure ritenta i processi di Smart Search falliti. Conserva la versione precedente del file Compose e il backup del database; non eliminare gli incorporamenti come prima risposta.

Ripeti il test con le stesse tre query, un elemento vecchio e un nuovo caricamento. Per superare il test sono necessari risultati utili, code di processi in diminuzione, originali leggibili e uno stato stabile del machine learning. Riavvia lo stack nel normale ordine delle dipendenze e ripeti il test, quindi riavvia una volta l'host per verificare che i montaggi e la risoluzione dei nomi sopravvivano all'avvio.

Esegui il rollback se i risultati diminuiscono, gli originali diventano illeggibili o il database segnala errori di coerenza. Se lo stesso guasto ritorna dopo due riavvii, segnala la versione di Immich, l'endpoint effettivo, lo stato del container, i log pertinenti, il numero di processi, il nome del modello e le mappature dei montaggi; mantieni isolata ma recuperabile la vecchia istanza con la ricerca funzionante.