Recover After the Local Service Crashes
Distinguish a page reload from a stopped service, restart when instructed, check interrupted tasks and package logs for repeated failures.
Distinguish a page reload from a stopped service, restart when instructed, check interrupted tasks and package logs for repeated failures.
The “internal brain” is the local background service that handles imports, image and face search, pose recognition, semantic search, OCR and color analysis. If it unexpectedly exits, the app may ask you to restart.
Search and parsing are unavailable while the service is stopped. Repeatedly clicking Search or Refresh will not restore it.
1. Preserve evidence, then restart
Record the message, time, and action. If the menu responds, use Help → Package Logs before closing the app. If the interface is unusable, restart first and collect logs as soon as it recovers. Reopen the app and select Start Searching. Wait for the local service to connect. If the workspace opens, check the task outcome, actual files, and relevant search data before repeating work. Completed writes are not automatically rolled back.
If the app remains stuck connecting or shows the crash message again, collect logs as described below.
2. Check interrupted work
Adding folders, refreshing or repairing the database, face clustering and batch search can be interrupted by a service crash. Review folder contents, database statistics and task status before deciding what to run again.
If a search was interrupted, enter the workspace and repeat the search. Searching does not delete the original files. Incomplete parsing may need a refresh or repair to fill in missing data.
3. Package logs for support
If the same action repeatedly causes a crash, use Help → Package Logs and send the generated archive to support.
Include the time of the failure, the action, file type, whether large images or many faces were involved, and whether the problem began after an update.
4. Distinguish connecting from crashing
“Connecting” or “Starting in compatibility mode” means the app is still trying to establish the local connection; it does not by itself prove a crash. Wait for the stated operation or use Retry. Follow the restart procedure when the app reports that the service has exited. Persistent connection failures also warrant collecting logs and following the specific error’s retry or restart guidance; do not wait for one exact crash message.
Page reload, memory pressure and blocked startup
A page reload can leave the local service running. From 3.13.30, the interface retrieves tasks that are still running in that service. Check task progress before submitting the same work again. Closing the whole app or a stopped service is different: the old task is no longer running.
If the app explicitly reports insufficient memory, close unnecessary demanding applications, reduce concurrent work and retry a smaller batch. If it reports a system policy or security-software block, review that specific message and the blocking record. Neither condition should automatically be treated as a damaged image.
Repeated failures still need logs, the operation and its timestamp. A successful restart restores availability but does not establish why the original failure happened.