bvandeusen
c265b871c3
Persists the operator's metadata-profile choice alongside quality profile + root folder. Defaults to the first profile Lidarr returns (usually 'Standard' on a vanilla install) so the common case is zero-click; operators with custom profiles like 'Singles only' can pick explicitly. Backend: - Migration 0013: adds nullable default_metadata_profile_id to lidarr_config. Existing rows get NULL and the service falls back to fetch-and-pick-first until they save. - Updated lidarr_config queries + sqlc + lidarrconfig.Config + admin view/put body to round-trip the new field. - handlePutLidarrConfig requires it (along with QP and root folder) when enabled=true — matches the existing missing_defaults gate. - New GET /api/admin/lidarr/metadata-profiles handler + lidarr.Client ListMetadataProfiles (GET /api/v1/metadataprofile, same shape as the quality-profile endpoint). - lidarrrequests.Approve prefers cfg.DefaultMetadataProfileID; falls back to the fetch-list path only when 0 (back-compat for upgraders). Frontend: - LidarrConfig type + LidarrMetadataProfile type + qk.lidarrMetadataProfiles. - listMetadataProfiles + createMetadataProfilesQuery client helpers. - Integrations page: third <select> picker, auto-defaults to first profile when the saved value is 0, sends the new field on save and clears it on disconnect. - Updated test fixtures + the duplicate 'Standard' option string in the dropdown-populates assertion. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Minstrel
Self-hosted music server with OpenSubsonic compatibility plus an extended API for server-side smart shuffle, a dual-like model (general + contextual), session-aware radio, ListenBrainz scrobble/similarity, and Lidarr integration. Go + Postgres, packaged as a Docker container.
State and intelligence belong on the server, not the client.
Specs
Authoritative v1 scope lives under docs/:
- Server spec — current implementation focus.
- Client spec — Flutter companion app; work starts once the server reaches its Subsonic-compatible baseline.
Development workflow
- Day-to-day work happens on the
devbranch (or feature branches merged intodev). mainis protected — changes land only via pull request fromdev.- Production builds are cut by tagging a release (
v*) offmain.
CI / container image
Forgejo Actions handles:
- Tests on push to
devand on PRs intomain. - Container image build + push to the Forgejo registry on merge to
main(:main) and onv*tags (:<version>).
Task and milestone tracking: Fable (Minstrel project, id 12).
Development
Minstrel has two concurrent dev processes:
- Backend:
docker compose up— starts Postgres and Minstrel on:4533. - Frontend:
cd web && npm install && npm run dev— Vite dev server on:5173with HMR.
The Vite dev server proxies /api/* and /rest/* to the backend on :4533,
so session cookies work correctly when the SPA is loaded from the Vite origin.
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 resulting container serves the SPA from / alongside the
API surfaces. No separate static-file server is required.