S.H.O.N.A.R._Desktop_Companion/STATUS.md

6 KiB
Raw Permalink Blame History

SHONAR Desktop — Status

Checkpoint for the standalone desktop app. Prepend a new dated section per material change; keep history below.

2026-09-22 — open-item audit closed; Large v3 quiet benchmark; in-app update check

  • pump-error.log (open item 1, Sep 16): CLOSED — already gone. Nothing named pump-error.log exists under ~/.config/shonar-desktop/ anymore (only logs/engine.log). The code path that writes it (DesktopState.kt pump failure logger) is current and legitimate.
  • Large v3 full-length timing (open item 2, Sep 16): MEASURED. Quiet machine (app + engine stopped), CPU int8, same args as the engine (beam_size=5), clips cut from a real 2 h 09 m recording:
    • 300 s audio → 1107 s wall (0.27× real-time), first segment 37 s, model load 8.7 s.
    • 1200 s audio → 2768 s wall (0.43× real-time), first segment 52 s. The earlier note ("300 s clip ran well under 7 min") was optimistic — under real quiet-CPU conditions Large v3 is ~4–8× slower than that. Practical read: a 2-hour recording ≈ 4–8 h of CPU transcription; Base (~7× real-time) stays the sensible default, Large v3 is for shorter, quality-critical clips.
  • In-app update check (7195aa1, pushed): Settings gains "About & updates" — build commit baked into the jar (generateBuildInfo → shonar-build.properties), a Check-for-updates button against the Forgejo commits API (up to date / update available with Open-repo link / newer-than-remote for dev builds), verified live on-device.

2026-09-16 — open-item audit; Large v3 provisioning verified

  • Large v3 first-use download verified end-to-end in an isolated HF_HUB_CACHE: snapshot_download fetched 2.9 GB in ~2.5 min, is_model_downloaded('large-v3') → True, model loaded in 4.6 s (CPU int8) and transcribed a real clip. Note: setup-standalone.sh vendors only Base; Large v3 is deliberately a first-use auto-download into the models/hf-cache the app exports — the registry's download_instructions() already covers the manual path. No defect.
  • Skipped backend test resolved: intentional (test_ai_adapters.py:55 skips when faster-whisper IS installed — the missing-dep path can't be exercised then). Not a Postgres test. Current count: 80 passed, 1 skipped.
  • Earlier open items 1–2 (startup job adoption, upload-mapping reuse) were closed by ba54cb8 + the .shonar.json sidecar.

2026-09-15 (evening) — summarize progress bar, job adoption

Committed: 7fa99e8 streaming summarize progress, ba54cb8 job adoption.

  • Summarize now shows a real determinate bar + Summarizing… N% (same look as the main screen). Backend: both LLM adapters stream (SSE / NDJSON) and report 0–99% as tokens arrive; 100 only on success. No fake movement — before the first token the label reads "Summarizing… waiting for model" (cold LLM / server queueing was indistinguishable from a dead app).
  • Adoption of engine jobs across app restarts: startup scan no longer skips files that have a report (re-summarize was orphaned), a reprocess that hits 409 "already running" attaches to the running job instead of erroring, and live work outranks a saved report in library status.
  • Verified live: screencap 19:41 — library row shows the bar + waiting label mid re-summarize; job settled to succeeded 100 with the % racing 48→99→100 once tokens flowed (H200 queueing caused the earlier "nothing happens"). pytest 79 passed/1 skipped · ruff clean · gradle green.
  • Note: the dev loop died once (~19:35, cause unclear — gradle run exit 143 chain); relaunched via background ./desktop-dev.sh.

Done earlier (Sep 15 morning): see below.

2026-09-15 — standalone desktop, Android fully removed

Verified state (live this session):

  • HEAD 6599935, clean tree, single branch master, no stashes
  • Backend tests: 78 passed, 1 skipped (pytest, SQLite) · ruff check clean
  • Frontend tests: 39 passed across 7 gradle suites
  • Engine runs locally on 127.0.0.1:8000 (healthz ok); runtime state in ~/.config/shonar-desktop/ (engine.db, settings.json)

What the app is: Compose Desktop (Kotlin) UI + bundled FastAPI engine (SQLite + in-process queue, self-migrating on boot). No Postgres/Redis/Docker, no server, no phone component. faster-whisper (Base vendored under models/hf-cache/, Large v3 downloadable) + an LLM for summaries (openai_compat or ollama).

Architecture decisions worth keeping:

  • All Android/phone code deleted (71b5571) — desktop is the product. The old server-era source lives on the main repo's deferred/desktop-server branch for reference only.
  • Shared code sits at shared/com/shonar (no src/), pulled in via srcDir("../shared") in app/build.gradle.kts.
  • Search picks its path by SQL dialect inside services/search.py (SQLite substring scan / Postgres tsvector) — intentionally no search_backend config knob (removed 6599935; nothing ever read it).
  • Engine endpoint root is /api/v1 (/healthz, /system/status, …).
  • Dev loop: ./desktop-dev.sh (inotifywait restarts app on .kt; uvicorn --reload for backend). Debian path: INSTALL-debian.md.

Done this cycle (Sep 14–15): batch transcribe-all with overall + per-file stage progress; library multi-select/bulk delete (single delete path); queued-file delete/rename; folder picker in-app + path in Settings; zoom keys; search-within-recording; click-hit-to-playback; model choice narrowed to Base + Large v3; Debian packaging + install guide; standalone provisioning with vendored base model.

Open items / candidates:

  1. Stale-noise cleanup: ~/.config/shonar-desktop/pump-error.log holds old Android→server upload 404s (pre-desktop pivot); no action taken.
  2. Optional: full-length Large v3 transcription timing (300 s clip ran well under 7 min on CPU int8 while the app + LLM were also active; a quiet benchmark would pin the number).

Known debt: none blocking. No dead stubs; one former TODO (search backend) resolved by deletion.