Troubleshooting

Troubleshooting

Indexing is extremely slow, or stalls on every file

Most likely cause: the reasoning model is thinking on every qualification. Indexing makes thousands of short LLM calls (classify a folder, qualify a document, guess a file's nature) whose answer is a handful of tokens. A "thinking" model reasons before each one. Measured on a real server: 24.4 s with reasoning vs 0.78 s without, same answer — enough to time out in a loop.

Fix: Settings → Indexing → qualify_effort = none (this is the default; check it wasn't changed). Note this is separate from the chat's and the planner's own reasoning settings, which stay on Auto.

Other causes:

• Indexing is paused — check the header.
• The embedding endpoint is down. The log says moteur d'embedding indisponible; the worker retries every 15 s.
• A single huge file. Files above max_file_mb (50 MB) fall back to context instead of extraction; max_chunks_per_file can cap vectors per file if one document is monopolising the queue.
• Model swapping — see below.

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

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

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

What SenseTree already does: failures are classified. A transient one (timeout, busy, 5xx, swap) is retried with a generous 300 s vision timeout — a cold load is waited out, not failed — and only on the last of 3 attempts does the image fall back to contextual sense.

How to reduce it:

• Put reasoning and vision on different machines or GPUs.
• Use a small vision model (moondream, qwen2.5vl:3b, minicpm-v) that co-resides.
• Switch pipeline_mode to batch — all LLM work for a slice of files runs before the embedding phase, cutting swaps by a factor of batch_files.
• Or OLLAMA_MAX_LOADED_MODELS=2 on a box with enough VRAM.

Check what's loaded from Settings (it reads /api/ps), or curl http://<host>:11434/api/ps.

Ollama "model not found" after pulling

A stale ollama serve hasn't picked up the new model — its /api/tags still returns the old list. Make sure only one instance runs, restart it, then refresh the model list in Settings.

Vision returns nothing / times out on every image

Confirm the model really supports vision:

curl -s http://<host>:11434/api/show -d "{\"name\":\"<model>\"}"

capabilities must include vision, and the model must have a projector. A plain text GGUF pulled from hf.co/... will not do vision, whatever its name suggests.

Also: .svg, .ico and .cur are never sent to vision — they're indexed by context on purpose.

Search returns nothing, or files have no "sense"

Vectors and senses are written only after a successful embedding. If the embedding endpoint was down or misconfigured while a file was processed, that file has none.

1. Check AI health in the header, and Test connection on the embedding slot.
2. Verify dimensions matches your model — Test connection reports the real vector length.
3. Once healthy, re-index the path (or everything).

Also check the file isn't inside a block folder, whose contents are deliberately not indexed individually.

A dimension mismatch error when indexing

embedding.dimensions doesn't match what the model actually produces. The LanceDB table is built from that field. Fix the value; if the table was already created at the wrong size, changing dimensions triggers a full re-index which recreates it.

I changed the embedding model and everything is re-processing

Expected. Different embedding models produce incompatible vector spaces, so the store is cleared and everything re-indexed. Let it finish.

I changed the block/recursive slider but nothing changed

The slider (and the folder_classify prompt) apply to folders classified afterwards. Changing them makes SenseTree forget prior classifications, but a scan is still needed to redo them: Save, then Re-index.

You can also force a single folder's mode by hand from the Explorer.

Folders are stuck "pending"

The crawler never blocks on the LLM: a folder that needs an AI decision is deferred and picked up later by a background classifier. If folders stay pending, the reasoning slot is disabled or unreachable — fix it and they resolve on the next pass (within ~20 s).

Transcription fails on every file

• Ollama does not transcribe. If transcription.base_url points at :11434, that's the problem.
• Check endpoint_path — some servers deviate from /audio/transcriptions.
• Check the model id is what your server serves. whisper-1 only works against hosted OpenAI.
• If the server rejects the request with a 4xx, that's a permanent error: the file falls back to context and isn't retried. The log carries the server's message.
• Some servers require response_format; leave it empty first, then set it if the server complains.

The chat answers but never searches or acts

The reasoning model probably doesn't support tool calling. SenseTree degrades gracefully — the pre-RAG excerpts still ground the answer — but search_files, read_file and propose_actions are never invoked.

Pick a model whose Ollama catalog entry advertises tools. If it does support them and still doesn't act, tighten prompts.chat_system or raise the reasoning slot's effort.

Action plans are malformed or invent paths

Strict-JSON, path-faithful output is demanding. Try a stronger instruction-following model, raise reasoning_effort for the reasoning slot, or edit the reorganize prompt — but keep its output contract intact (Prompts).

Out-of-root paths are refused by the backend regardless; an invented in-root path simply fails at apply time, and the plan rolls back.

An MCP server's tools never appear

Discovery is best-effort and silent by design. Run the app from a terminal: you'll see either MCP <name>: N tool(s) exposed or MCP <name> unavailable: <error>. Check the URL and auth header, or for stdio, that the command resolves on PATH. Discovery is cached for 120 s, but editing the server config invalidates it immediately.

The CI release build fails on protoc

LanceDB compiles .proto files at build time and needs the Protocol Buffers compiler. The release workflow installs it (arduino/setup-protoc). Locally: choco install protoc or winget install protobuf. See Building from Source.

Duplicate log lines / actions firing twice (dev only)

React 19 StrictMode double-invokes some functions in npm run tauri dev to surface impurity. Keep side effects (IPC calls) out of setState updaters. Dev only.

High CPU when idle

ONNX Runtime keeps an intra-op thread pool that spins while a session exists. SenseTree unloads the local embedder when indexing is paused and after ~15 s with an empty queue, so idle CPU should drop to nothing. If it doesn't, indexing probably isn't actually idle — check the queue modal.

Where are the logs?

Structured tracing output goes to the console. In development that's the npm run tauri dev terminal; for a packaged build, launch the exe from a terminal. Raise verbosity with RUST_LOG=sensetree_lib=debug.