Skip to content

Troubleshooting

Virgile Thonnier edited this page Jul 17, 2026 · 3 revisions

Troubleshooting

Vision is "unavailable", then works again (swap thrash)

Symptom: logs show vision indisponible … repli contextuel for one image, then the next image indexes fine — seemingly at random.

Cause: you're running the reasoning and vision models on the same GPU, and it can't hold both at once. The runner unloads one to load the other on every alternation; the first vision call after a swap can exceed the timeout.

What SenseTree does: vision failures are classified. A transient failure (timeout, server busy, 5xx, model swap) is retried — with a generous, vision-specific timeout so a cold load is waited out rather than failed — and only on the last retry does the image fall back to contextual sense. So an image is no longer permanently downgraded by one swap.

How to reduce it:

  • Put reasoning and vision on different machines/GPUs, or
  • Use a small vision model (moondream, qwen2.5vl:3b, minicpm-v) that co-resides with the reasoning model, or
  • Set OLLAMA_MAX_LOADED_MODELS=2 on a box with enough VRAM to hold both.

Check what's loaded: curl http://<host>:11434/api/ps.

Ollama "model not found" after pulling

Symptom: you just pulled a model but a request returns 404 … model not found, even though the files exist on disk.

Cause: a stale ollama serve instance that hasn't picked up the new model (its /api/tags returns an old list).

Fix: ensure only one Ollama instance runs; restart ollama serve, then re-scan the model list in Settings.

Vision returns nothing / times out on every image

Confirm the model actually supports vision in Ollama:

curl -s http://<host>:11434/api/show -d '{"name":"<model>"}' | grep -o '"capabilities":\[[^]]*\]'

It must include "vision" and have a projector. A plain text GGUF pulled via hf.co/... won't do vision — use a real multimodal model.

Search returns nothing, or files have no "sense"

Summaries and vectors are written only after a successful embedding. If the embedding endpoint was down/misconfigured while a file was processed, it has no sense yet.

  • Check AI health in the header and Test connection for the embedding slot.
  • Verify dimensions matches the model.
  • Re-index (Settings) once embedding is healthy.

I changed the embedding model and everything seems re-processing

That's expected. Different embedding models produce incompatible vector spaces, so changing the model (or its dimensions) forces a full re-index. Let it finish.

I changed the block/recursive slider but nothing changed

The slider (and the folder_classify prompt) apply to folders classified afterward. SenseTree forgets prior classifications on such a change, but you still need a scan to reclassify: Save, then Re-index. See Indexing Pipeline.

Indexing seems stuck / progress bar doesn't appear

  • Make sure indexing isn't paused.
  • One crawler runs per root; a scan requested during another is scheduled, not lost — it runs at the end of the current pass.
  • Check the logs for the embedding engine; if it's moteur d'embedding indisponible, fix the embedding endpoint.

The CI release build fails on protoc

Symptom: GitHub Actions build fails with Could not find protoc while building lance-encoding.

Cause: LanceDB compiles .proto files at build time and needs the Protocol Buffers compiler, which isn't preinstalled on the runner.

Fix: the release workflow installs it (arduino/setup-protoc). Building locally? Install protoc (choco install protoc / winget install protobuf). See Building from Source.

Duplicate log lines / actions firing twice (dev)

In npm run tauri dev, React 19 StrictMode double-invokes some functions to surface impurity. Keep side effects (IPC calls) out of setState updaters; run them in the callback body. This only affects dev.

Where are the logs?

SenseTree uses structured tracing logs to the console of npm run tauri dev. For a packaged build, run it from a terminal to see them.

Clone this wiki locally