bvandeusenandClaude Opus 5 3acac985cd
android / Build + lint + test (push) Successful in 4m8s
feat(home): veil only when content changed; tell the user when it didn't — #2327
The veil raised eagerly: any trigger over a warm cache put it up before
knowing whether the refresh would change anything. So every launch cost
~1-2s of opaque panel even when the pull returned exactly what was already
cached — which, now that the section swap is atomic and the index flow dedups
on ids, produces no visible churn to hide at all. The veil was covering
nothing and only delaying first paint.

The raise is now reactive: it fires when the content key actually differs from
what was already on screen, and never for a no-op refresh. The baseline is the
first state that HAS content, not the first state at all — over a warm cache
the cached rows paint a moment after the session starts, and counting that
first paint as "a change" would veil every launch, which is the thing being
fixed. Cost of reacting rather than anticipating: the veil arrives one emission
after the change, so a single atomic swap shows through. Everything messier
that follows it — tile hydration, then artwork — still lands behind it.

That leaves a hole this closes too: a manual pull where nothing changed would
now produce no veil, no movement, nothing whatsoever, which reads as broken. So
sessions report an outcome — CHANGED / UNCHANGED / FAILED — and Home surfaces
it as "Already up to date" or "Couldn't check for updates".

Only for refreshes a person actually asked for. "Already up to date" on every
launch, every 03:00 rebuild and every reconnect would be worse than silence, so
VeilSessionResult carries a userInitiated bit and background sessions stay
quiet. The bit is tracked separately from the request token because the request
channel is CONFLATED: coalescing drops the older token, and a user's pull must
not be swallowed by a background trigger arriving on its heels.

The surfaced failure is a deliberate narrowing of the earlier "silent on give
up" call, which is now read as being about background refreshes: for a pull the
user deliberately triggered, silence looks broken, and staying silent while the
success case speaks would be incoherent. Recovery is unaffected either way.

Pull-to-refresh now waits for whichever successor actually arrives — the veil,
or the snackbar — via finishedSessions, instead of only ever waiting on the
veil and timing out for 2s on an unchanged pull.

The Error-state Retry goes through the controller as well, so it gets the
retries and reports its outcome; over an empty cache there's no content to
protect, so no veil appears. HomeViewModel.refresh() is gone, replaced by
retry() and refreshFromPull() — the two things that actually exist.

Tests: two changed meaning and are rewritten rather than patched. A failed pull
writes nothing, so the veil no longer stands over the retries — it goes up when
a retry finally lands. And "waits for content to paint" became "cached content
painting is not mistaken for a change", which is the baseline subtlety above.
Added coverage for UNCHANGED, FAILED, the cold-load CHANGED case, and the
conflation of a user request with a background one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-31 23:16:49 -04:00
2026-04-18 17:33:35 +00:00

Minstrel

A self-hosted music server that thinks for you. Smart shuffle, contextual likes, ListenBrainz-aware radio, and Lidarr automation — server-side, so every client (web, mobile, Subsonic third-party) gets the same intelligence.

State and intelligence belong on the server, not the client.

Minstrel home — your library at a glance

Highlights

  • OpenSubsonic-compatible. Existing Subsonic clients (DSub, Symfonium, play:Sub, etc.) connect with no special configuration.
  • Server-side smart shuffle. Track-similarity vectors, dual-like model (general + contextual), and session memory keep mixes coherent across devices.
  • ListenBrainz radio. Session-aware "more like this" pulls from ListenBrainz similarity data, not a static genre tag.
  • Lidarr integration. Triggered scans, request-driven album imports, and a quarantine flow when something doesn't fit.
  • Built-in web SPA. Full-feature library, search, queue, playlists, and admin — no separate frontend container to deploy.
  • Native Android client, shipped with the server. The signed APK is bundled into every image and attached to each release — sideload it once, then the app self-updates straight from your own server (no app store, no separate download to track).

Quickstart

# compose.yaml
services:
  minstrel:
    image: git.fabledsword.com/bvandeusen/minstrel:latest
    ports: ['4533:4533']
    volumes:
      # Your music library. Point ./music at wherever your audio files
      # live. Mounted read-only — Minstrel never writes to your library.
      - ./music:/music:ro
      # Generated data: playlist cover collages, artist art, caches.
      # The path must match MINSTREL_STORAGE_DATA_DIR, which the image
      # sets to /app/data — keep this mount on /app/data or your cache
      # won't survive a container recreate.
      - minstrel-data:/app/data
    environment:
      MINSTREL_DATABASE_URL: postgres://minstrel:minstrel@db:5432/minstrel?sslmode=disable
      # Colon-separated library roots to scan; must match the container
      # path of the read-only music mount above (/music here).
      MINSTREL_LIBRARY_SCAN_PATHS: /music
    depends_on: [db]

  db:
    image: postgres:17
    environment:
      POSTGRES_USER: minstrel
      POSTGRES_PASSWORD: minstrel
      POSTGRES_DB: minstrel
    # Postgres data dir — users, likes, play history, sessions, settings.
    # The one volume you must never lose; back it up with pg_dump.
    volumes: [pgdata:/var/lib/postgresql/data]

volumes:
  minstrel-data:
  pgdata:
docker compose up -d

First run

With the stack up, a handful of in-app steps get you to a working library. Use your own host in place of localhost if you're reaching the server over a LAN/VPN address (plain http:// is fine — no TLS required).

1. Create your admin account. Visit http://localhost:4533/register. The first account on a fresh instance is automatically the administrator; later users join through the same form or an invite token (step 5).

Creating the first (admin) account on a fresh instance

2. Let the first library scan finish. scan_on_startup is on by default, so Minstrel walks your mounted library on boot and imports artists, albums, and tracks — no button to press. Watch progress (and re-scan any time) on the Admin page (/admin); the scan runs in stages and is incremental, so later restarts only pick up what changed.

The Admin page, where the library scan runs and reports progress

3. (Optional) Name the instance and wire up integrations. In admin Settings → Integrations (/admin/integrations), add a ListenBrainz token (scrobbling + similarity radio) and/or a Lidarr URL + API key (the request flow). These live in the UI and apply without a restart; the display name can also be set via MINSTREL_BRANDING_APP_NAME.

ListenBrainz and Lidarr integration cards in admin Settings

4. Install the Android app. Open Settings (/settings) and use the Install the Android app card to download the APK that ships inside this server image, then sign in with the same account. From then on the app self-updates straight from your server.

The "Install the Android app" download card in Settings

5. Invite the rest of the household. From admin Users (/admin/users), generate an invite token (or enable open registration). Each person gets their own account, so likes, play history, and recommendations stay per-user.

Generating an invite token in admin Users

For the full configuration surface, see config.example.yaml.

Configuration

Most operators only need the env vars in the quickstart above. A few extras worth knowing:

  • MINSTREL_BRANDING_APP_NAME — rename the instance ("Family Jukebox", "Office Music"). Surfaces in the header, browser tab, and OG share previews.
  • MINSTREL_STORAGE_DATA_DIR — where generated artefacts (playlist cover collages, artist art, caches) are written. The container image sets this to /app/data, which is why the quickstart mounts the minstrel-data volume there.
  • MINSTREL_LIBRARY_SCAN_PATHS — colon-separated list of music library roots to scan. Supports multiple roots (/music:/podcasts).

ListenBrainz integration (per-user scrobble + similarity tokens) and Lidarr integration (URL + API key) are configured through the admin Settings UI rather than env vars or yaml — per Minstrel's "config in UI" rule, integration settings live where operators can edit them without restarting.

Most operational keys have a MINSTREL_<SECTION>_<FIELD> env override. Recommendation and events tuning are yaml-only. See config.example.yaml for the authoritative surface.

Updating

Image tags (git.fabledsword.com/bvandeusen/minstrel:<tag>):

  • :latest — the newest blessed image. Moves on every main push and every release. Recommended for most operators.
  • :vYYYY.MM.DD — immutable per-day release tags. Pin one of these for a deployment you don't want moving under you. (Per-day CalVer — no trailing patch digit; a same-day re-cut moves the tag forward.)
  • :main — the rolling post-merge tip. Same image as :latest at push time; choose it if you want to track main explicitly rather than the release line.

Every :latest and every :vYYYY.MM.DD bundles the current signed Android APK, so the in-app update channel is always live. Database migrations run automatically at startup; rollbacks require restoring a Postgres dump.

Specs

Authoritative scope lives under docs/:

Development

Two concurrent dev processes:

  1. Backend: docker compose up — Postgres + Minstrel on :4533.
  2. Frontend: cd web && npm install && npm run dev — Vite dev server on :5173 with HMR. The Vite server proxies /api/* and /rest/* to :4533 so session cookies work.

Testing

  • Unit + race (no DB): make test-short.
  • Full suite incl. integration tests: make test-integration. This runs against a dedicated minstrel_test database so a test run never truncates your dev minstrel data (admin user, library, likes). It brings up the compose Postgres and creates the test DB if missing.
  • CI runs both: a fast go test -short -race gate plus an integration job with its own ephemeral Postgres (.gitea/workflows/test-go.yml).

Production build

docker build -t minstrel . runs the SvelteKit build inside a node stage, copies the output into the golang stage, and //go:embeds it into the final binary. The container serves the SPA from / alongside the API surfaces; no separate static-file server is required.

Branches

  • Day-to-day work happens on dev (or feature branches merged into dev).
  • main is protected — changes land via PR from dev.
  • Releases are cut by tagging v* off main; the release workflow builds and pushes the container image to the Gitea registry.

Task and milestone tracking: Fable (Minstrel project, id 12).

License

See LICENSE.

S
Description
Self-hosted music server with OpenSubsonic compatibility, server-side smart shuffle, dual-like model, session-aware radio, and Lidarr integration. Go + Postgres.
Readme MIT
61 MiB
Languages
Go 39.7%
Kotlin 25.5%
Dart 13.6%
TypeScript 11.7%
Svelte 9.2%
Other 0.1%