81 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	f34423a0e0	feat: leveled FLAC stream for Sonos/UPnP speakers (M464 #5001) ... Speakers fetch their own audio, so the phone cannot level it. A cast token minted with level=true (and the client's asAlbum, which only the queue holder knows) now returns GET /api/tracks/{id}/leveled.flac: the track rendered by ffmpeg at the user's gain (volume=XdB, plus alimiter at -1 dBFS for a limiter-mode boost), metadata stripped, FLAC at 16 or 24 bits and at most 48 kHz. The gain is computed server-side from the user's preference and the stored loudness, carried as ?g=<centi-dB>&lim=0|1 and signed into the token, so an edited URL does not verify. Unity gains get the plain stream. Renders are written beside the cache file and renamed in, keyed by the source's size and mtime, coalesced per file (singleflight, detached from the requesting speaker so a retry finds the render running), started at mint time so the fetch finds them ready, and evicted least recently used past leveled_cache_mb, a new admin setting (migration 0068, Loudness analysis card). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 19:31:07 -04:00
bvandeusenandClaude Opus 5.5	af36b2f24a	feat: per-user volume leveling preference, synced across devices (M464 #4998) ... Mode (off, auto, track, album), target (-18, -16, -14 LUFS) and boost (within headroom, or fully with a limiter), stored per user on the server so the web player, the Android app and casts apply the same one. - Server: user_normalization_prefs (migration 0067), GET/PUT /api/me/normalization; a whole-body PUT, validated, last write wins. - Web: Settings > Playback > Volume leveling. Saves at once, restores the old choice if the save fails, and caches the value for the player. - Android: Settings card. The device keeps a copy for offline playback (Room v9 with an explicit migration, so the upgrade wipes nothing). Writes are offline-first: shown at once, PUT best effort, queued on failure (NORMALIZATION_SET, collapsed to the newest). A refresh never overwrites a change still queued. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 14:29:40 -04:00
bvandeusenandClaude Opus 5.5	e3aa8629d3	feat(api): deliver loudness gains to every client (M464 #4997) ... ReplayGain 2.0 values (gain to -18 LUFS, linear peak) derived from the stored track and album loudness: - Web: GET /api/tracks/replay-gain?ids=... (up to 200), a lookup the player calls for its queue, rather than a field on every TrackRef surface. - Android: track_gain/track_peak and album_gain/album_peak on the sync views, so cached tracks level offline. Storing a measurement logs a track change, and an album's values moving logs an album change, both before the write (#2704), so caches pick the gains up. - OpenSubsonic: replayGain on every song (album, getSong, search3, starred), as a JSON object and an XML element. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 13:54:05 -04:00
bvandeusenandClaude Opus 5.5	f3196b3443	feat(library): measure every track's loudness in the background (M464 #4995) ... The first step of loudness normalization: the server measures each track with ffmpeg's EBU R128 filter (true peak, mono as dual mono) and stores the integrated loudness, true peak and loudness range in track_loudness (migration 0065). It also keeps a histogram of the 400 ms gating blocks at 0.1 LU, so album loudness can be computed exactly later with no second decode (#4996). The histogram reproduces ffmpeg's own figure (-10.68 against -10.7 on the captured fixture), and the analyzer logs a warning if the two ever drift. - A background worker, cloned from the fingerprint backfill, measures every track, new ones included. Measuring inline in the scan was dropped: the analysis decodes the whole file, and a large import could pass the scan's one-hour stuck threshold. The scan only deletes a changed file's measurement; the worker ticks every 10 minutes. - Timeouts, the cancel/missing-binary split and settled verdicts follow the fingerprint runner. Silence and undecodable files are stored as verdicts; stalls are retried. The deadline scales with track length. - loudness_settings (enabled, files at once) and an admin card with the coverage gauge, under GET/PUT /api/admin/library/loudness-settings and GET /api/admin/library/loudness. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 13:01:01 -04:00
bvandeusenandClaude Opus 5.5	edd9a3a6db	fix(auth): the Subsonic password is generated, never the login password (M462 #5026) ... `minstrel admin reset-password` copied the new login password into subsonic_password, which is stored in plain text because Subsonic t/s sign-in needs it. Every account recovered through the CLI had its login password readable in the database, and changing the password later left the copy behind. - reset-password now changes only password_hash. - Migration 0064 clears every subsonic_password, removing the copies. - Settings gets a Subsonic password card: the server generates a random password, shows it once, and it can be regenerated or turned off (GET/POST/DELETE /api/me/subsonic-password, audited). Generated rather than user-chosen so it can never be a reused password. - docs/security.md describes the separate password instead of the known issue. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 10:54:30 -04:00
bvandeusenandClaude Opus 5.5	327d49428f	feat(auth): store Subsonic API keys hashed; a new key is shown once (M462 #4983) ... users.api_token held each user's apiKey in plaintext and was looked up by equality, so a leaked row or backup handed out working keys. Migration 0063 replaces it with api_token_hash (sha256, hex), computed in place from the existing keys so every Subsonic client keeps working. The key can no longer be read back: GET /api/me/api-token is gone, and POST returns the new key once. Settings shows it right after Regenerate with a copy button and a "won't be shown again" note. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 09:42:35 -04:00
bvandeusenandClaude Opus 5.5	2f3fbccab6	feat(auth): first account on a new server needs the setup token from the server log (M462 #4982) ... While no accounts exist, the server mints a random setup token at boot and logs it. Registering the first account (which becomes admin) must carry it, so whoever reaches a freshly exposed instance first cannot claim it. The register page asks GET /api/auth/setup-status and shows a "Setup token" field in place of the invite field while setup is pending. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 09:35:52 -04:00
bvandeusenandClaude Opus 5.5	3bfddd0862	feat(auth): throttle login, register, password reset and Subsonic auth failures (M462 #4976) ... Every password-shaped check was mounted bare, so guessing was limited only by bcrypt cost. A shared in-memory AttemptLimiter now sits in front of them: - login: 10 failures per account and 50 per address per 15 min, checked before the user lookup and bcrypt; 429 with Retry-After. A success clears the account's count but not the address's. - unknown usernames run a dummy bcrypt compare, so timing no longer says which accounts exist. - register: 10 per address per hour; forgot-password: 5 per address and 3 per email per hour (applied whether or not the email matches); reset: 20 failed tokens per address per 15 min. - Subsonic /rest: same limits as login, counting only wrong credentials, since clients authenticate on every request. Web login, register, reset and forgot-password screens say how long to wait; web and Android carry copy for the rate_limited code. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 08:28:29 -04:00
bvandeusenandClaude Opus 5	077ae61235	feat(admin): fingerprinting settings — on/off, length, match threshold, concurrency, sweep interval (M400 #3913) ... Rule 25: the fingerprinting knobs move out of source into a DB-backed singleton (migration 0061), edited from a card on the Duplicates page and shared live with the scanner, the backfill and the duplicate sweep through one service instance, so a save needs no restart. The length is the knob that can silently break the library: prints taken at two lengths never match. Each track_fingerprints row now records the length it was taken at, and every reader filters on the current one — the backfill treats another length as stale, the gauge counts it pending, the sweep never streams it. Equivalent to a version bump, except that setting the length back makes rows not yet redone current again. The card warns before a length change re-fingerprints the library. Off stops every decode: the scan takes only the stream hash (a demux, and what recognises a moved file) and stores nothing, dropping a changed file's stale row; the backfill idles. A save also makes a sweep due, since a new threshold or length changes what the same prints group into, and the sweep interval gains slack so an hourly interval on an hourly tick doesn't skip every other tick. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 17:53:55 -04:00
bvandeusenandClaude Opus 5	11ef044ef6	feat(library): merge duplicates without losing history (M400 #3911) ... Merge keeps one copy of a duplicate group and removes the rest. Every table that references tracks does so ON DELETE CASCADE, so deleting a duplicate's row outright would silently destroy its likes, plays, playlist entries and tags. The merge moves all of that onto the kept copy first, then deletes the empty row. In one transaction, holding a lock on the group: - repoints play_events, skip_events, contextual_likes, playback_errors, lidarr_requests.matched_track_id and playlist_tracks. The last is keyed by position, so every entry stays where it was. - merges general_likes one per user, dated to the earlier like - takes the union of track_tags, keeping the kept copy's own weight on a shared tag - rewrites track_similarity onto the kept copy, dropping edges that would point a track at itself and keeping the kept copy's existing edge on a collision - lets the kept copy take a recording MBID only the removed copy had - deletes the removed copies' rows, tidies emptied albums and artists, marks the group merged - logs sync changes: track deletes, and like and playlist-track delete/upsert pairs The removed copies' files are deleted first, before any row changes, through the same helper as DeleteTrackFile (now shared, along with the album tidy-up). A merge that left the file behind would be undone by the next scan re-importing it. An unwritable library answers 409 library_not_writable and nothing changes. tracks.Service.MergeDuplicates wraps it with the opt-in Lidarr unmonitor from RemoveTrack, skipped when the removed copy is a second file of the kept copy's own album track: unmonitoring that would stop Lidarr managing the kept file. It writes a duplicate_merge audit row after commit, per the audit package's best-effort contract, naming both paths. POST /api/admin/library/duplicates/{id}/merge takes an optional survivor_track_id (the report's proposal otherwise) and unmonitor. On the report page: - each copy gets a Keep choice, defaulting to the proposed one - Merge needs a second click, on a button that says how many files it removes, with the consequence stated beside an opt-in Lidarr checkbox Integration tests cover: - every piece of history landing on the kept copy exactly: likes deduped at the earlier time, plays and skips counted, playlist position unchanged, tags unioned, similarity rewritten with no duplicate or self-edge, MBID inherited - the removed file gone, and a second merge refused - an unwritable file leaving likes, plays, row and group untouched - a survivor outside the group refused Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 17:25:06 -04:00
bvandeusenandClaude Opus 5	ff493a8c7d	feat(admin): the duplicates report — review proposed duplicate groups (M400 #3912) ... A new admin tab, Duplicates, beside Missing files: the proposals from the duplicate sweep, with a Sweep now trigger and a Not duplicates dismissal. Nothing on it merges or deletes; the merge is #3911. Each group shows: - whether it is identical audio or the same recording, with a match percentage from the weakest link between members - every copy's format, size, duration, path, and the likes and plays it carries (every user's; this is admin-only, and it is what decides which copy to keep) - the copy proposed to keep, and the rule that chose it The survivor rule is library.ProposeSurvivor, a pure function the merge will reuse: lossless over lossy, then the larger file, then the copy in the library longest, then lowest id. Bitrate is not in it because the scanner never fills tracks.bitrate, and for one recording at one duration a larger file is the higher bitrate. m4a is not counted as lossless: it may be AAC. The reason names the rule that separated first place from second, not every rule the winner passed. An empty report has three causes, and the page says which: still fingerprinting, the sweep has never run, or it ran and found nothing. The sweep's state and the backfill's progress come back with the groups for that reason. Groups left with fewer than two members since the sweep are not shown. GET /api/admin/library/duplicates, POST .../sweep (202, or 409 sweep_in_progress), POST .../{id}/dismiss (404 duplicate_group_not_pending when already resolved). Migration 0060 indexes play_events by track_id. Its only indexes led with user_id, so each copy's play count, and the merge's repointing of play history, would scan the whole table. Web only, like Missing files: Android has no library-health admin screens. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 17:11:11 -04:00
bvandeusenandClaude Opus 5	b8855b480f	feat(library): backfill fingerprints for the existing library — M400 #3908 ... The scan fingerprints only bytes it has not seen, so everything imported before fingerprinting existed, and any row derived by an older fingerprintVersion, needs a pass of its own. That pass is a background worker, not a stage in RunScan. RunScan runs at boot and then every 12h, and an in-flight scan older than an hour is reaped and a second started beside it. A stage would have to stop inside the hour: a few hundred decodes a run, so about a month for a 50k-track library. It would also hold the run in flight and answer manual rescans with 409 while it worked. FingerprintBackfillWorker runs once at start, then hourly. Nothing a pass does (error or panic) can stop the next tick. A pass walks tracks with no fingerprint or a stale version, skipping missing tracks, keyset-paged on id. The cursor is what lets a pass end: an inconclusive attempt writes no row, so a file that keeps timing out would otherwise be re-listed and retried forever. Two decodes at a time, deliberately: they compete with transcoding for CPU and with streaming for the mount. storeFingerprint is now one package function shared by the scan and the worker, and reports whether the attempt was fingerprinted, rejected, inconclusive or failed to store. Progress is a live gauge on the Admin scan card, served by GET /api/admin/library/fingerprints: fingerprinted / rejected / pending of total, with missing tracks excluded so it can reach the end. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 14:56:18 -04:00
bvandeusenandClaude Opus 5	721154847e	fix(recommendation): size the candidate pool to the library ... Operator, 2026-09-10: "is the pool that we draw from somehow scaled to the amount of music in the library... my earlier understanding of the tuning and work may have been skewed by what was in my library." It was not. DefaultCandidateSourceLimits returns what its own comment calls "the v1 hardcoded constants per spec" — ~170 candidates for a 500-track library and a 100,000-track one alike. The pool therefore samples a shrinking FRACTION of a growing collection: 17% of 1,000 tracks, 1.7% of 10,000, 0.17% of 100,000. RandomFill, whose whole job is exploration, becomes a thinner and noisier slice at exactly the moment a library gets more diverse — which is the "starting to feel weird" being reported. 1,000 tracks -> pool 170 (unchanged) 5,000 -> pool 170 (unchanged) 20,000 -> pool 280 80,000 -> pool 500 (ceiling) THE SCALING IS PER-ARM, and that is the substance rather than a refinement. A limit only matters if there are rows for it to cut off, so what an arm is BOUNDED BY decides whether library size can help it. LBSimilar, SimilarArtist, TagOverlap and RandomFill grow: they are bounded by similarity/tag data and by the library itself. LikesOverlap, UserCoplay and TasteOverlap do not: they are bounded by the user's likes, the instance's co-play graph and the taste profile, none of which grow when the library does. Raising those would sample more of a set that did not change — churn, not reach. It also keeps this from inflating the sim_score-0 share, since TasteOverlap is one of the two zero-similarity arms. sqrt, not linear: linear would put a 100,000-track library at a 3,400-candidate pool, long past where more candidates improve the answer. A 4x ceiling bounds it at ~500. Never shrinks an arm. The base limits are a floor, and #3889 makes that load-bearing rather than tidy — shrinking an arm ordered by unseeded random() changes pool membership between same-day rebuilds. Library size comes from a TTL-cached count reusing CountTracksMatching with an empty pattern (rule 28 — a new query would need sqlc regeneration, which is blocked). The ILIKE defeats every index, so it is a full scan and must not run per request. It degrades rather than fails: an error keeps the last known value, a never-counted cache returns 0, and 0 scales to the base limits — today's behaviour exactly. Nothing about sizing a pool justifies failing the request it is sizing. Bounded by a 3s deadline (rule 156), and a failed refresh does not stamp the clock, so a blip cannot pin a stale value for the whole TTL. THE REFERENCE IS ASSUMED, NOT MEASURED. libraryScaleReference = 5000 is where growth starts, and the size the v1 constants were really tuned against is unrecorded. #3879 should replace it; until then that constant is the one thing to change. Deliberately conservative: below it nothing scales at all, so no existing install changes behaviour. Falsification caught a weak guard: the sqrt-vs-linear assertion was written at SIXTEEN times the reference, where linear has already been clamped by the ceiling and both curves land on 4x. It proved nothing. Moved to four times the reference, below the ceiling for both, where sqrt gives 2x and linear would give 4x. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 23:23:04 -04:00
bvandeusen	30a5ac56ce	feat(api): admin endpoints for the re-acquisition policy — #2527 ... GET/PUT /api/admin/library/reacquisition, so every knob the sweeper reads is editable without a restart (rule #25). Routed under /library beside the missing-files list it governs rather than under /lidarr: Lidarr is the mechanism, but missing files are the problem the operator came to solve, and that is the surface they meet it on. The payload carries one thing the settings table doesn't: the count of albums with missing files that can never be auto-requested, because neither they nor their artist has an MBID. Nothing can be asked of Lidarr for a release MusicBrainz cannot name, and a feature that silently does nothing for part of its input reads as broken -- so the card states the number instead of leaving it to be inferred. Counted best-effort: the settings are the point of the endpoint, and failing the whole card because a count query hiccuped would be the wrong trade. Range errors come back as 400 naming the field. The Go-side validation mirrors migration 0056's CHECKs precisely so the operator reads "grace_hours must be 1-720" rather than a constraint-violation string surfacing as a 500.	2026-08-17 00:02:41 -04:00
bvandeusen	4dd0a58d63	feat(api): admin surface for files the library has lost — #2527 ... The scan has marked missing files since f6d1cf24 and every selection path filters them out, so they cause no harm -- and are invisible. The operator found out about the first batch only because an unrelated MBID backfill logged "no such file or directory" forty times. GET /api/admin/library/missing reports them, grouped by directory. The grouping is the whole ergonomic argument: the case that produced #2523 was three reorganised albums, which a flat list renders as forty unrelated problems and a folder list renders as three decisions. ListMissingTracks orders by directory so the handler can fold runs without a map, which also keeps the query's ordering instead of Go's random map iteration. Each row carries last_played_at, nullable, because "gone six months, never played" and "gone yesterday, played 200 times" deserve opposite reactions and a file path tells you neither. The correlated MAX needs its ::timestamptz cast or sqlc infers interface{} and the Go layer loses the type. Read-only, deliberately. Nothing here deletes: a missing file keeps its row, its play history and its likes because it may come back, and if it comes back renamed the scanner adopts it (#2528). The route sits under /library rather than /tracks so it can't be confused with the destructive DELETE /admin/tracks/{id} beside it.	2026-08-16 11:48:45 -04:00
bvandeusen	1126bfcf78	feat(library): genre + year browse queries and endpoints — #367 ... Server half of #367. Web UI follows. Genres are exposed AS-IS per the operator: split on the delimiter, trimmed, but no case folding and no synonym mapping. So "Rock" and "rock" appear as separate rows, as does "Rock/Pop" alongside "Rock" and "Pop". The raw spread has to be visible before anyone can judge whether it needs normalising, and the alternative is a mapping table to invent and then maintain. Trimming is not an exception to that. Splitting "Rock; Pop" yields " Pop", and showing that as a genre distinct from "Pop" would be a bug in OUR splitting, not fidelity to the operator's tags. ## The correctness trap this had to avoid ListAlbumsByGenre compared tracks.genre verbatim, while recommendation.sql and discover.sql have always split it on [;,]. Building the browse index by splitting while matching exactly would have listed genres whose pages are empty — every multi-genre track unreachable from either of its genres. So ListAlbumsByGenre now splits too. That also fixes Subsonic getAlbumList?type=byGenre, its only caller, which silently missed every multi-genre track. Its Genre param went *string → string as a result. EXISTS rather than JOIN + DISTINCT ON throughout: the lateral split emits one row per (track, fragment), so a join multiplies rows per album and needs DISTINCT to undo itself. EXISTS asks the question directly, and the count query then matches the list query by construction rather than by coincidence. ## Genre is a query parameter, not a path segment Because "Rock/Pop" is a real ID3 tag — the one the task itself cites — and a slash cannot survive a path segment: Go normalises %2F and the router would split the value in two. So filtering rides GET /api/library/albums?genre=, which also reuses the existing paged album surface instead of adding a parallel one. Endpoints: GET /api/library/genres unpaged index + track counts GET /api/library/years unpaged index + album counts GET /api/library/albums?genre= filtered page GET /api/library/albums?year_from=&year_to= filtered page, either edge open The indexes are unpaged deliberately: a client needs the whole set to render a browsable picker, and paging would let it show only a prefix of an ordering the user didn't choose. Two refusals rather than guesses: genre+year together is a 400 (the UI browses them as separate axes, and quietly dropping half a filter would report a narrower result than it returned), and an inverted year range is a 400 rather than being silently swapped. Undated albums are absent from the year axis rather than bucketed under 0 — "unknown" is not a year, and a 0 row would sort to one end of a chronological list looking like data. Tests: parseYearFilter is pure and runs in the fast lane. The integration tests assert the thing that would otherwise be silently broken — that a "Rock;Pop" track is reachable from BOTH genres, that "Rock/Pop" survives as a filter value, that fragment whitespace is trimmed, and that undated albums stay out of every year range. Reused the existing seedAlbum/seedTrackWithGenre fixtures, which already took exactly the year and genre arguments needed.	2026-08-05 13:22:30 -04:00
bvandeusen	381e9cedb7	feat(net): trusted-proxy depth so real client IPs survive a proxy — #2453 ... Fixes the defect the operator spotted in #370 immediately after it shipped: auth.ClientIP ignored X-Forwarded-For whenever RemoteAddr was public, so a proxy on a public address — a separate host, or a CDN, i.e. anyone running this publicly, since public means TLS means a proxy — recorded the PROXY for every session. created_ip and last_ip were then always equal and the "Address changed" signal could never fire. The feature looked like it worked and reported nothing. Replaced with the standard trusted-hop model (Rails, Caddy, Traefik, nginx). XFF grows left-to-right as each proxy appends the peer it received from, so for client -> CDN -> own-proxy -> app the app sees [client, CDN] with RemoteAddr = own-proxy, and the client sits at XFF[len - hops]: 0 RemoteAddr, XFF ignored — no proxy 1 the address your own proxy observed 2 through a CDN in front of your proxy Default 1, per the operator: publicly reachable means a TLS terminator in front. The cost is real and stated rather than hidden. hops >= 1 DECLARES that a proxy exists; set it with no proxy, or deeper than the actual chain, and the index reaches attacker-supplied entries, letting a visitor choose which address their own session shows — defeating exactly the detection #370 is for. That's inherent to the model, which is why 0 is a first-class value and the admin card says "count your proxies, don't guess high" instead of just exposing a number. Both mis-set shapes are pinned by tests so they stay known consequences rather than surprises. Migration 0053 + internal/netsettings, cached under an RWMutex. That's not an optimisation: ClientIP runs in RequireUser for every authenticated request, so a per-request query would put the database on the critical path of the whole API. New() always returns a usable service so a boot-time DB hiccup degrades to the default instead of breaking that path (rule #131), and Hops() is nil-safe because test routers construct middleware without it. RequireUser now takes a func() int rather than an int — the value is operator-editable at runtime while the middleware is built once at boot, and reading it per request is what makes a save take effect with no restart (rule #25). The admin card is verifiable, not just configurable: it reports the address the CURRENT setting resolves THIS request to, the raw forwarded chain, and the socket peer — so you set the number, save, and confirm the address matches the machine you're on. It also counts the arriving chain and says how many proxies that implies. GET/PUT both return that payload, PUT recomputed under the new value, so the effect is visible without a reload. Also fixes styling in the #370 card that CI could not catch: text-destructive and bg-destructive don't exist in this Tailwind config — the palette is colors.action.destructive — so the "Address changed" warning and the sign-out-others button were rendering unstyled. Both now use text-action-destructive / bg-action-destructive / text-action-fg. Not done here: requestlog.go still logs raw RemoteAddr and will disagree with the sessions UI about who connected. Left for its own change.	2026-08-05 10:07:43 -04:00
bvandeusen	d86af7397d	feat(auth): active sessions API with origin/current IP — #370 ... Server half of the active-sessions surface. Web UI follows. The operator wants this specifically to notice a compromised account, which sets the bar: the addresses have to be trustworthy, or the feature is worse than absent because it looks like evidence. Migration 0052 adds created_ip + last_ip. Two columns, not one, and the pair is the signal: a session issued at home and now being used from elsewhere is the shape of a stolen token, and neither column alone can show that. Typed text, matching the user_agent column beside it — these are displayed, never queried by subnet, and inet round-trips through pgx as a netip.Prefix that renders "1.2.3.4/32". The rest of the schema was already waiting. Migration 0004 anticipated this exactly: "last_seen_at enables an 'active sessions' UI later (not wired in this plan) without schema churn." last_seen_at is live data — the auth middleware already touches it per request — so last_ip rides that same UPDATE for free. Getting the address right is the substance here. Nothing extracted a client IP anywhere before, and both obvious approaches are wrong: - RemoteAddr alone shows the reverse proxy on every session, which is the normal self-hosted deployment. Noise shaped like data. - Trusting X-Forwarded-For lets any client choose what its victim sees. A security surface an attacker can write to is worse than none. So auth.ClientIP trusts the header only when the request actually arrived from a proxy range. Public RemoteAddr means a direct connection, so XFF is attacker-controlled and ignored outright. Private RemoteAddr means we walk XFF right-to-left — proxies append, so the right end is what our own infrastructure wrote — and take the first non-proxy address. A forged XFF only prepends to the left end, which that walk never reaches. Unit-tested, including both spoofing shapes. Fails closed on a public-addressed proxy (separate host, CDN): we report the proxy rather than trusting a forgeable header. Documented at the function. Endpoints, all scoped by user_id per rule #47: GET /api/me/sessions → list, flagging the current row DELETE /api/me/sessions/{id} → 204, or 404 if not yours POST /api/me/sessions/logout-others → {"revoked": n} Keyed on session id alone, any household member could revoke another's session by guessing a uuid, so the delete carries user_id in its WHERE and :execrows distinguishes "not yours" (404) from a false 204. There's a test that asserts the row actually survives, not merely that we returned 404. The middleware now also puts the session id in context. logout-others is defined by exclusion, and without knowing which session is ours the safe-looking action deletes everything including the caller's — so it refuses rather than guesses when the id is absent, and that refusal is tested for non-deletion too. audit_log.action is plain text with no CHECK, so the two new actions need no migration (rule #36 checked, not assumed). Codegen is real sqlc 1.31.1 via the container in `make generate` — docker is present on this workstation even though Go and sqlc aren't — rather than the hand-written .sql.go shortcut used in milestone #268.	2026-08-05 09:17:40 -04:00
bvandeusenandClaude Opus 5	86af79bd2f	feat(discover): time-boxed suggestion snooze, server side — #2374 ... Migration 0049 adds suggestion_snoozes(user_id, candidate_mbid, candidate_name, snoozed_until), and SuggestArtistsForUser excludes rows whose snooze hasn't expired. This is NOT a dislike. Rule #101 forbids a "Not for me" / thumbs-down UI; a snooze is the approved shape instead because it records no verdict on the music, expires on its own (~90d), and never reaches the taste profile. It's acquisition triage — "not right now" — so the filter sits at the candidate stage rather than in the score, where it would become a ranking signal by the back door. Per-user throughout (rule #47): one household member parking a candidate leaves everyone else's deck untouched. candidate_name is denormalized because suggestions are out-of-library by definition — there is no artists row to resolve a display name from, and the un-snooze list has to show something. That list is why GET /discover/snoozes exists at all: a parked candidate is by definition absent from the deck, so without it the DELETE would be unreachable. Also fixes a hole in the codegen check from #2380: `git diff` ignores untracked paths, so a brand-new generated file would have passed it silently. `git add -N` first. This commit is the first to add one. Endpoints: POST /api/discover/suggestions/{mbid}/snooze (body: name, days) DELETE /api/discover/suggestions/{mbid}/snooze GET /api/discover/snoozes UI lands in slice 4 (#2375) before any of this merges — rule #27. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 22:51:51 -04:00
bvandeusenandClaude Opus 4.8	cce928e584	feat(api): admin tag-sources endpoints (#1490 Step 4 backend) ... Expose the tag-enrichment provider settings over the admin API, mirroring the cover-sources surface so a Last.fm key can be pasted and sources toggled from the web admin UI (rules #25/#27). - GET /api/admin/tag-sources — list providers + version - PATCH/api/admin/tag-sources/{id} — enable / set api_key - POST /api/admin/tag-sources/{id}/test — test connection - POST /api/admin/tag-sources/research — bump version, re-open settled rows for re-enrich - Thread tags.SettingsService through server.New (struct field, like RecSettings) → Router → api.Mount → handlers.tagSettings; main.go sets srv.TagSettings. Handler tests mirror admin_cover_sources_test (list / flip-bumps-version / key-only-no-bump / unknown-404 / non-admin-403 / not-testable-ok-false), integration-tier (skip without MINSTREL_TEST_DATABASE_URL). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 22:24:28 -04:00
bvandeusenandClaude Fable 5	9ad4343c76	feat(tuning): weekly trend view — per-surface series + knob-turn markers ... The verify half of the tune→verify loop (#1251), on the same admin Tuning page as the knobs: - RecommendationWeeklyTrends: weekly per-source outcomes aggregated across all users (the knobs are global, so judging a turn needs global outcomes — rows carry rates only, no track/user identity), with a taste-hit count per bucket: plays whose track's artist has a positive weight in the player's current taste profile. That's the "cheap recompute" reading — retroactive over the whole window, at the cost of profile drift. - GET /api/admin/recommendation-trends?weeks=N (default 12, cap 52): per-family weekly series (skip rate, sample-weighted completion, taste-hit rate) plus the tuning-audit markers inside the window. - Web: sparkline table under the tuning cards — skip rate per week on a shared axis with dashed ticks at knob turns, latest-week columns, window taste-hit rate, low-volume rows dimmed as anecdote, and a plain-text list of the window's tuning changes. Also fixes the revive unused-parameter lint on the tuning GET handler that failed CI run 1903 on the previous commit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6	2026-07-03 09:29:33 -04:00
bvandeusenandClaude Fable 5	0d0a8f46b1	feat(tuning): scoring weights → DB-backed admin tuning lab ... The recommendation scoring knobs move out of YAML (radio profile) and out of the systemMixWeights hard-code (daily_mix profile) into DB-backed settings with live effect (#1250) — the defaults-discovery lab per decision #1247: the operator turns knobs to find good values, which then get baked back into shipped defaults; end users and other operators should never need the card. - Migration 0040: recommendation_weight_profiles (radio / daily_mix, 8 weight columns), taste_tuning singleton (engagement half-life + completion-curve points), recommendation_tuning_audit (one row per change with a {field, old, new} diff — the trend view's markers, #1251). - internal/recsettings: boot reconcile seeds shipped defaults without clobbering tuned rows (coverart SettingsService pattern), validates patches (bounds, curve ordering), writes audit rows, and pushes daily_mix weights + taste config into package playlists. No-op patches write no audit row. - playlists gains SetSystemMixWeights / SetTasteConfig swap points under a RWMutex — no signature threading through the producers; the scheduler's taste rebuild reads the pushed config. - Radio reads its weight profile from the service per request; the 8 weight fields leave config.RecommendationConfig (YAML keeps only RecentlyPlayedHours / RadioSize / RadioSizeMax). - Admin API: GET/PATCH/reset under /api/admin/recommendation-tuning, echoing current + shipped values. - Web: new admin Tuning tab — two weight profiles side by side, taste card, per-scope save (changed fields only) + reset, deviation dots against shipped defaults. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsF3cNoKrqCYsU78cXC8U6	2026-07-03 09:22:03 -04:00
bvandeusenandClaude Opus 4.8	4ed831d9c3	feat(server/diagnostics): device debug-reporting ingest + admin timeline + retention (M9) ... New diagnostic_events table + per-account users.debug_mode_enabled flag. When an account's flag is on, its client(s) POST a batch timeseries of connectivity / UPnP-sync / power / lifecycle events to /api/diagnostics (no-op 204 when off, kind whitelist mirrors the CHECK constraint). Admin surface: GET /api/admin/diagnostics (optional account/device/kind/ time-window filters, RFC3339-or-epoch-ms, export-sized paging) + a /diagnostics/devices overview + PUT /api/admin/users/{id}/debug-mode to flip an account remotely while a bug is live. debug_mode_enabled is now exposed on /api/me (client gate) and the admin user views. Retention: a 30-day gc-worker sweep (GcPruneDiagnostics), keyed on the server clock so a skewed device clock can't keep rows alive. Refs Scribe M9 (#119), tasks #1172 #1173. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K55iTxn95BtshocgdE1shW	2026-06-29 18:38:56 -04:00
bvandeusenandClaude Opus 4.8	1a7515e6ea	feat(taste): phase 4 — recommendation observability (#796) ... Per-source play outcomes so the operator can see whether each recommendation surface is landing and tune the now-operator-tunable taste weights. Server: - query RecommendationSourceMetricsForUser: groups the user's play_events by source (system-playlist surface), reporting plays / skips / avg completion over a window; NULL-source (library/radio) plays excluded. - GET /api/me/recommendation-metrics?days=30 (default 30, capped 365) → {window_days, sources:[{source, plays, skips, skip_rate, avg_completion}]}. - handler test: 401 unauth; per-source aggregation + NULL-source exclusion + skip_rate / avg_completion math. Web: - lib/api/metrics.ts: query + friendly source labels. - settings page gains a "Recommendation metrics" card (table of surface / plays / skip rate / avg completion), with loading/error/empty states. - settings tests mock the new query (manual subscribe-store, hoisting-safe). Note: You-might-like plays aren't source-tagged (it's a Home row, not a system playlist), so this covers For-You / Discover / the mixes. Tagging YML plays would be a client follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-12 00:28:30 -04:00
bvandeusen	63b25e65ad	feat(server): similar-artists + per-user artist top-tracks endpoints ... GET /api/artists/{id}/similar — in-library artists ranked by similarity score (deduped across sources), ArtistRef list with cover + album count. GET /api/artists/{id}/top-tracks — current user's most-played tracks for the artist (skips excluded, quarantine filtered).	2026-06-06 22:30:41 -04:00
bvandeusen	e994aae613	feat(server): retire scan scheduler for watcher + safety-net walk ... Wire the fsnotify watcher and a fixed 12h safety-net delta walk in main; remove the configurable scan scheduler (scheduler.go, scan_schedule table via migration 0033, GET/PATCH /api/admin/scan/schedule, and the server/api plumbing). Manual scan + scan status are unchanged.	2026-06-06 21:50:08 -04:00
bvandeusen	27bd38e005	feat(server): stream URL gets file extension so Sonos can probe duration	2026-06-04 07:29:28 -04:00
bvandeusenandClaude Opus 4.7	e774097fd8	feat(server): POST /api/cast/stream-token + secret bootstrap (UPnP slice 2/6) ... Adds the client-facing endpoint that issues a signed stream URL for the current track. Authenticated via the standard session cookie. Returns {token, exp, url} where url is a fully-formed stream URL the client passes verbatim to a UPnP / Sonos device's AVTransport.SetAVTransportURI call. expSeconds clamped to [60, 86400]; default 21600 (6h) - long enough to play through any typical track without re-minting mid-playback. MINSTREL_STREAM_SECRET is loaded from env var with a per-machine fallback persisted at <Storage.DataDir>/stream_secret (auto-generated on first boot via 64 random bytes, base64-url-encoded, 0600). The file-based fallback is operator-machine-scoped runtime state, not a user-facing setting - chosen over a DB column to avoid a migration and keep the secret out of cross-instance restores. Operator can override at any time via the env var; default path requires zero config. Tests cover happy-path token issuance + URL formatting, bad-UUID rejection, unauthenticated rejection, the expSeconds clamp at all boundaries, secret env override, auto-gen + file persistence at 0600, second-boot reuse of the persisted file, and rejection of a malformed env value. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-03 11:46:57 -04:00
bvandeusen	236637fcd3	feat(server): HMAC stream token auth path (UPnP slice 1/6) ... Adds SignStreamToken / VerifyStreamToken (HMAC-SHA256 over trackID|exp) and modifies handleGetStream to accept either the existing session cookie OR a valid signed token. Stream route moved out of the authed group so the handler's own auth check runs and the token bypass is reachable. Enables Sonos / UPnP speakers to fetch the stream URL without carrying the user's session cookie - they cannot. The token is short-lived (max 24h per the design); expiry checked at request time only, not per-byte, so long tracks play through. streamSecret field on handlers is nil for now; Task 2 wires the loader (env var with auto-generated fallback persisted in app_preferences). Adds auth.OptionalUser - the permissive sibling of RequireUser that attaches the user to context when a valid cookie / bearer is present but does NOT 401 on absence. The stream route is wrapped with it so the handler can fall through to the token path when no session is present. newLibraryRouter (test fixture) gets a synthetic-user middleware on the stream route so existing media_test tests keep passing without seeding a real session row - production traffic uses auth.OptionalUser, the test path uses auth.UserCtxKeyForTest(). Five tests cover round-trip, tampered token rejection, expiry, wrong-track-ID, and wrong-secret rejection. CI verifies.	2026-06-03 11:34:02 -04:00
bvandeusen	15b59a214d	feat(server): playback_errors table + admin inbox endpoints ... New client-reported playback-error log. Surfaces zero-duration tracks (and future load_failed / stalled kinds) into an admin inbox so the operator can hide / delete / re-request the offending track. Schema (migration 0032): - playback_errors table with CHECK constraints on the kind + resolution enums (per the standing rule that new enum values need a migration to add) - Partial index on unresolved rows for fast inbox lookup - ON DELETE CASCADE from tracks + users so cleanup is automatic Endpoints: - POST /api/playback-errors: any signed-in user reports. Body validates track existence + kind whitelist; client_id required so support can correlate reports from the same device. - GET /api/admin/playback-errors?resolved=false&offset=&limit=: admin list with join to track/album/artist for table render without per-row round-trips. Pagination capped at 200/page. - POST /api/admin/playback-errors/{id}/resolve: admin marks resolved with a resolution enum string. Auto-resolve on Hide/Delete/Re-request from the inbox row is driven from the web client (two sequential calls) — keeps the existing track-action endpoints unchanged.	2026-06-02 11:25:50 -04:00
bvandeusenandClaude Opus 4.7	005965d6de	feat(coverart): #388 remove global cover-art backfill cap ... Operator feedback (2026-05-09): the 500-album cap meant cover art rolled in over many nightly runs even when local sources (sidecar/embedded) could finish in minutes. Remove the global cap; rely on the existing per-provider HTTP throttle (coverart httpClient MinInterval) so local art is disk-speed and remote providers stay TOS-friendly. - enricher.go / artist_enricher.go: EnrichBatch, EnrichArtistBatch, EnrichRetryMissing now treat limit<0 as unbounded (0 still = stage disabled). The cap was a SQL LIMIT; unbounded uses max int32. - main.go: RunScanConfig EnrichCap/ArtistEnrichCap = -1 (unbounded). - Drop LibraryConfig.CoverArtBackfillCap + the MINSTREL_LIBRARY_COVERART_BACKFILL_CAP env var. - Drop the now-dead coverBackfillCap param threaded through server.New + api.Mount + the handlers struct. - Admin bulk refetch (/api/admin/covers/refetch-missing) now drains unbounded; response {queued:int} → {started:bool} (the count is unknowable synchronously for a fire-and-forget drain). Web copy + client type + Go/web tests updated to match. No doc refs existed (config.example.yaml / docker-compose / README never documented the env var). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 18:41:21 -04:00
bvandeusenandClaude Opus 4.7	a5e2abb8c4	feat(offline): #427 S4a — Shuffle all + offline system-playlist gate ... Headline of S4. "Shuffle all" is always present (home app-bar shuffle icon); the pool degrades with reachability: - online → GET /api/library/shuffle?limit=N (new): N random library tracks server-side, per-user quarantine filtered (ListRandomTracksForUser, ORDER BY random()). - offline → ShuffleSource shuffles the whole local cache index (audio_cache_index ∩ cached_tracks, names from cached_artists/ albums) — a UNION over liked AND recently-played, since the two-bucket split is storage-only and never filters playback. Offline gating: refreshable (singleton) system playlists need the live build/shuffle endpoints, so their tile play is disabled when offlineProvider is true — Shuffle all is the offline path. User playlists still play from cache. playlist_card now reads offlineProvider in build → wrapped the direct-render widget test in ProviderScope (offlineProvider is smoke-safe from S1: tracked timers, no connectivity mount). S4b (offline Recently-played / Liked browsable surfaces over the cache index) next. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 21:37:29 -04:00
bvandeusenandClaude Opus 4.7	d67c0de596	refactor(playlists): #411 R2 — generic registry-driven system endpoints ... Replaces the per-kind refresh/shuffle handlers with one generic pair driven off the kind registry, in lockstep across both clients. Server: - systemPlaylistKind gains Singleton; RefreshableSystemKind(key) exported. for_you/discover singleton; songs_like_artist not. - New generic POST /api/playlists/system/{kind}/refresh and GET /api/playlists/system/{kind}/shuffle ({kind} = raw system_variant). Non-singleton/unknown kind → 404. Deleted playlists_{foryou,discover}_refresh.go and the per-kind shuffle wrappers; serveSystemPlaylistShuffle core kept. - playlistRowView.refreshable: server-derived flag so clients show the refresh affordance generically without hardcoding kinds. Web (not drift-cached → uses the server flag): - refreshSystem(variant) replaces refreshForYou/refreshDiscover; systemShuffle drops the for_you→for-you mapping (raw variant). - PlaylistCard + detail page gate the kebab/Refresh button on playlist.refreshable; label is "Refresh {name}". Tests reworked; obsolete refresh-foryou/discover api tests deleted. Flutter (list tiles are drift-cache-sourced → derive, no migration): - Playlist.refreshable getter = isSystem && variant != songs_like_artist (holds for all current + planned kinds). - refreshSystem/systemShuffle use the raw variant; PlaylistCard + detail screen gate kebab/Regenerate/source-tagging on refreshable so songs_like_artist plays via get() (no by-kind endpoint). Pure-plumbing refactor; CI verifies parity. Next (R3): the five discovery mixes — each a candidate query + one registry entry. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 13:21:09 -04:00
bvandeusenandClaude Opus 4.7	e43281d1d0	feat(playlists): #415 stage 2 — rotation-aware shuffle endpoint ... GET /api/playlists/system/{discover,for-you}/shuffle returns the caller's system playlist with tracks ordered: unplayed-this-rotation first (shuffled), then already-heard (shuffled). When the whole snapshot has been heard, ResetRotationState fires and the full list reshuffles fresh. Option A (operator's choice): a separate, intentionally-uncached endpoint. The cached GET /api/playlists/{id} detail path stays pure for "open to view"; this varies per play. Same JSON shape as the detail GET so Stage 3 clients reuse track parsing with no new model. Two explicit static routes per variant mirror the refresh handlers and avoid chi static-vs-param ambiguity under /playlists/system/. Empty/absent snapshot → 200 with empty track list (nothing to play, not an error). Rotation reset failure is non-fatal — still returns a playable reshuffled list. No client wiring yet — Stage 3 makes web + Flutter call this on the play/tile gesture and send `source` on play_started. Handler-level test deferred to Stage 3 (needs the full service+pool harness; the end-to-end path is exercised there). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 07:47:57 -04:00
bvandeusen	0119eacf14	feat(api): GET /api/home/index for per-item rendering (Slice B) ... Sibling to /api/home that returns the same five sections (recently added, rediscover albums, rediscover artists, most played, last played) but as flat slices of entity ID strings instead of denormalized objects. The Flutter client uses this to drive its per-item rendering pass — small discovery response then per-tile hydration via the existing /api/albums/:id, /api/artists/:id, /api/tracks/:id endpoints. Reuses recommendation.HomeData so the DB cost is identical to /api/home. JSON payload shrinks roughly an order of magnitude on populated libraries (no embedded title / artist / cover URL fields). Old /api/home stays untouched so the web client and older Flutter builds keep working — no min-client-version bump needed until both clients have migrated.	2026-05-13 20:41:44 -04:00
bvandeusenandClaude Opus 4.7	46c8edfa82	feat(playlists): gocron-based per-user scheduler ... Builds the per-user daily-at-03:00-local scheduler for #392 Half B. Uses github.com/go-co-op/gocron/v2 with WithLocation(userTZ) for each user's job. Hourly reconciliation pass keeps the in-memory job set in sync with the active-users query. Start sequence: clear stale in_flight rows; register a daily job for every active user at their stored timezone; fire a one-shot runOnce to catch up missed schedules during downtime; start gocron. Stop drains and shuts down the gocron loop. Refresh(ctx, userID) removes the user's existing job (if any) and registers a fresh one at their current timezone — wired into the PUT /api/me/timezone handler and new-user registration in the next commit. Server struct gains PlaylistScheduler; main.go constructs it after the eventbus and threads it through to api.Mount. The existing StartSystemPlaylistCron call stays for one more commit so we don't have a window where no scheduler is running; Task 3 deletes it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-13 11:57:13 -04:00
bvandeusenandClaude Opus 4.7	230da7bdcb	feat(users): timezone column + PUT /api/me/timezone ... Schema + endpoint scaffolding for #392 Half B (per-user timezone scheduling). Adds two columns to the users table: - timezone text NOT NULL DEFAULT 'UTC' (IANA name) - timezone_updated_at timestamptz (nullable; populated on each PUT) PUT /api/me/timezone validates the IANA value via time.LoadLocation and writes the row. No scheduler integration yet — the scheduler struct lands in the next commit and the handler-side Refresh call in the commit after. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-13 11:54:45 -04:00
bvandeusenandClaude Opus 4.7	170614baf1	feat(#392): SSE event stream foundation — eventbus + /api/events/stream ... Slice 1 of the #392 hybrid live-refresh work. Ships the in-process pub/sub bus and the SSE subscriber endpoint; no producers wired yet, so the stream emits only heartbeats today. Verifiable in isolation by curl-ing the endpoint with a valid Bearer token — the connection opens, ": heartbeat" lines arrive every 15s, the connection closes cleanly on client disconnect. eventbus.Bus is a small fan-out broadcaster: subscribers register through Subscribe (returns a receive channel + an unsubscribe closure), writers call Publish, and the bus drops events for any subscriber whose buffer is full rather than blocking the writer. No persistence — clients are expected to resync via normal /api/* fetches on (re)connect. The SSE handler emits an initial ": connected" comment so the client sees the connection open immediately, then forwards events whose UserID matches the authenticated user (or is empty for broadcast). Heartbeat comments keep proxy connections alive. Context cancellation cleanly tears down the subscription on client disconnect. Producers (likes, request status, quarantine, scanner, playlist mutations) land in subsequent slices. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 20:44:37 -04:00
bvandeusenandClaude Opus 4.7	154f415f92	fix(server,web): auth-gate client APK + version endpoints + per-user rate limit (#397) ... Closes the bandwidth-abuse vector on the in-app update flow. Both endpoints now sit inside the authed.Group; APK additionally gets a 60s/user rate limit to suppress accidental hammering or scripted abuse. ### Server - internal/api/client_assets.go: - clientAPKAllowDownload(): in-memory map[userID]time.Time under a mutex. Returns 0 (allow) or wait duration (block). - handleClientAPK reads user from context, checks the limit, returns 429 + Retry-After header if blocked. - testResetClientAPKRateLimit() lets tests start clean. - internal/api/api.go: routes moved from the root /api group into the authed.Group block (alongside /quarantine, /requests, etc.). - Tests: added TestClientAPK_401WhenUnauthenticated and TestClientAPK_RateLimit_429OnRapidSecondCall (also verifies different user gets a fresh slot). Existing tests updated to use authedRequest() helper. ### Web - MobileAppDownload.svelte: switched from bare fetch (no credentials) to api.get<>() which carries the session cookie. 404 / 401 / network errors all silently hide the download row. - Removed the login-page mount entirely — pre-auth surfaces should never show this. Settings → Mobile app section keeps it for logged-in users. Flutter unaffected: dio's Bearer interceptor already attaches the token, and the polling only fires once the post-login shell mounts the banner widget. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-10 20:28:27 -04:00
bvandeusenandClaude Opus 4.7	a2bea8601a	feat(server): /api/client/version + /api/client/apk endpoints (#397 phase 1) ... Phase 1 of the in-app update flow — server side. Endpoints serve the bundled Android APK + sidecar version file from /app/client/. Returns 404 gracefully when files aren't present, so dev environments and pre-CI-wiring images degrade cleanly to "no update available." - internal/api/client_assets.go: handleClientVersion + handleClientAPK. Both unauthenticated (matches /healthz) so install flow doesn't depend on a live session. APK served with proper application/vnd.android.package-archive Content-Type + http.ServeContent so Range requests work for resumable downloads on flaky networks. - Path resolves to /app/client/ by default; MINSTREL_CLIENT_APK_DIR env var overrides for dev. - Dockerfile creates /app/client/ + commented COPY hooks for the CI sequencing phase. - Tests cover all four states: missing apk, apk-but-no-version, both present (200 with correct shape), apk stream (200 with correct Content-Type + body bytes). Phases 2 (Flutter client provider + banner + install intent + Android manifest changes) and 3 (CI sequencing to bake the APK into the image) land in follow-up commits. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-10 19:35:24 -04:00
bvandeusenandClaude Opus 4.7	6bd8a15c7a	feat(server): mount /api/library/sync route ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-09 22:36:46 -04:00
bvandeusenandClaude Sonnet 4.6	cbe838cbe3	feat(server/m7-user-mgmt): forgot + reset password endpoints (U3) ... POST /api/auth/forgot-password and POST /api/auth/reset-password. Forgot-password ALWAYS returns 200 with empty JSON to prevent enumeration of registered emails. Side effect: when email matches a user with email-on-file, generates a 32-byte hex token (24h TTL), inserts into password_resets, and sends the reset email via the mailer. Mailer failures are logged (not surfaced) and the audit log carries metadata.email_match for operator visibility. Reset-password atomically claims the token via UsePasswordReset (:execrows; concurrent calls can't both succeed). On rows=1, hashes the new password and writes via ChangeUserPassword. Returns 204 on success, 400 invalid_token on stale/used/missing tokens, 400 password_too_short for short passwords. Audits ActionPasswordResetByEmail. Wires the mailer.Sender into the handlers struct via Mount; production sender (NewSMTPSender) constructed in server.Router(); tests inject FakeSender via testHandlers default. The reset URL embedded in the email is derived from r.Host (no PublicURL config setting in v1; self-hosted operators see their own hostname). Tests cover happy-path send + token-row insertion, unknown email returns 200 with no send, mailer failure still returns 200, reset happy path verifies bcrypt match + used_at set, already-used token 400, expired token 400, short password 400, bogus token 400. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 12:49:30 -04:00
bvandeusenandClaude Sonnet 4.6	aa67a09b80	feat(server/m7-user-mgmt): mailer package + SMTP config endpoints (U3) ... New internal/mailer/ package: - Sender interface with two impls: SMTPSender (production, reads smtp_config at send time so admin edits apply without restart; uses stdlib net/smtp + STARTTLS) and FakeSender (test/concurrent- safe call recorder). - Embedded text + HTML templates for the password reset email, rendered via stdlib text/template + html/template. The HTML uses the FabledSword forest-teal accent color. - ErrNotConfigured surfaces when smtp_config.enabled is false or required fields are empty; callers like the future forgot-password handler will treat this as "log and pretend success" to avoid user-enumeration leaks. Three admin endpoints under RequireAdmin: - GET /api/admin/smtp-config — returns the singleton; password field is masked ("***" or ""). - PUT /api/admin/smtp-config — updates settings. Validates host + from_address are non-empty when enabled=true. Empty password in the request preserves the stored value (so the operator doesn't have to re-enter it on every save). - POST /api/admin/smtp-config/test — sends a real test email to the calling admin's email. 400 if admin has no email; 500 with the error message on send failure (so the operator can debug config without grep-then-trace through logs). Tests cover the password-mask, password-preservation-on-empty, enabled-requires-host-and-from validation, and the no-email-on-file rejection. Mailer unit tests cover the fake recorder and template rendering. The "real SMTP send" path needs a live server and isn't covered in CI; the FakeSender covers that role for downstream tests. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 12:43:44 -04:00
bvandeusenandClaude Sonnet 4.6	aa73c93f85	feat(server/m7-user-mgmt): self-service /me endpoints (U3) ... Four authenticated endpoints for the user's own account: - PUT /api/me/password — change own password. Caller must supply current_password (verified via bcrypt). Distinct from admin-driven reset (which doesn't require knowing the old). Audits ActionPasswordChangeSelf. - PUT /api/me/profile — set display_name + email. Both fields are nullable; empty string clears, omitted leaves unchanged. Email is lowercased before store + format-validated. Unique violation → 409 email_taken. - GET /api/me/api-token — returns current API token (for copy-paste into Subsonic clients). - POST /api/me/api-token — regenerates token. Old one stops working immediately. Audits ActionTokenRegenerate. All four use the existing RequireUser middleware on the authed sub-router; audit writes are best-effort (logged on failure). Tests cover happy paths, wrong-password 401, password-too-short 400, email-invalid 400, email-taken 409, clear-by-empty-string, omit-leaves-unchanged, token GET + regen. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 12:38:48 -04:00
bvandeusenandClaude Sonnet 4.6	46d38afe2d	feat(server/m7-user-mgmt): admin user CRUD endpoints (U2) ... Four new admin endpoints under existing RequireAdmin middleware: - POST /api/admin/users — admin-creates-user. Body {username, password, display_name?, is_admin?}. Same username + password validation as the public /register handler. 409 on duplicate. Audits ActionCreateUserAdmin. - DELETE /api/admin/users/{id} — hard delete. Last-admin guard refuses delete when target is the only admin (409). Schema's ON DELETE CASCADE on user-FK tables handles plays/likes/ sessions cleanup. Audits ActionDeleteUser with target's username + was_admin flag. - POST /api/admin/users/{id}/reset-password — body {password}. 8-char minimum. Admin sets a new password without knowing the old one. Audits ActionPasswordResetAdmin. - PUT /api/admin/users/{id}/auto-approve — body {auto_approve: bool}. Toggles the per-user flag added in T1 (the #355 sub-feature surface). Audits ActionAutoApproveToggle. adminUserView shape extended with auto_approve_requests so the list and toggle responses carry the flag. ListUsers SQL query updated to include auto_approve_requests; generated Go updated to match. Tests cover happy paths, last-admin guard on delete, password validation, duplicate username, and the auto-approve round-trip. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 12:17:14 -04:00
bvandeusenandClaude Sonnet 4.6	bd362ab384	feat(server/m7-user-mgmt): admin endpoints (invites, users, promote/demote) ... Five admin endpoints under existing RequireAdmin middleware: - GET /api/admin/invites — list active + recently-redeemed - POST /api/admin/invites — generate 24h invite, returns {token, expires_at, ...}. Audits ActionInviteCreate. - DELETE /api/admin/invites/{token} — revoke unredeemed invite. Audits ActionInviteRevoke. - GET /api/admin/users — list all users (id, username, display_name, is_admin, created_at). - PUT /api/admin/users/{id}/admin — toggle is_admin with last-admin guard. Audits ActionPromoteAdmin / ActionDemoteAdmin. Last-admin guard counts admins, refuses demotion of the sole admin with 409 'last_admin'. Race window between count and update is acceptable for v1 — worst case is 'no admins left,' which the env-driven bootstrap or CLI reset can recover from. Common path ('admin demotes themselves') is now blocked. Adds ListUsers, CountAdmins, UpdateUserAdmin sqlc queries to users.sql. Tests cover: invite create/list/delete round-trip, non-admin gets 403, user list, promote happy path, last-admin demotion refused, two-admins demotion allowed. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 12:01:16 -04:00
bvandeusenandClaude Sonnet 4.6	a449398906	feat(server/m7-user-mgmt): self-registration handler ... POST /api/auth/register accepts {username, password, invite_token?, display_name?} and creates a user. Race-safe first-admin path: when the users table is empty, the SQL query (CreateUserFirstAdminRace) inserts is_admin computed from a SELECT NOT EXISTS subquery — no serializable isolation needed; concurrent empty-state registrations both end up admin (benign). Past first-admin, registration_settings.mode dictates: 'invite_only' (default) requires a valid unredeemed unexpired invite token, which is atomically claimed via RedeemInvite (rows-affected returns from sqlc's :execrows directive). 'open' mode skips the invite check. On success: hashes password (bcrypt), mints session token + cookie matching handleLogin's shape, mints a separate api_token for Subsonic clients, audits ActionRegister + ActionInviteRedeem (best-effort — a failed audit write does NOT fail the user-facing operation). Validation: 3-32 char usernames (alphanumeric + underscore + hyphen), 8-char minimum password. Duplicate username surfaces as 409. Tests cover: first-user-becomes-admin, invite-only requires token, valid token redeems + non-admin role, invalid token 400, open mode skips check, duplicate username 409, password too short 400, username format 400, race scenario asserts at-least-one-admin. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 11:56:19 -04:00
bvandeusen	54c40c18be	feat(server/playlists): manual For-You refresh endpoint ... POST /api/playlists/system/for-you/refresh re-runs the system playlist build synchronously for the calling user, then returns the freshly-built For-You playlist's id, track count, and the track IDs in playlist position order. The frontend tile play button (next task) calls this endpoint on click and enqueues the returned track_ids directly — one roundtrip, no follow-up "list tracks" call needed for playback to start. Same authenticated-user-only posture as the Discover refresh from D-T3. Returns playlist_id=null and track_ids=[] when the build succeeded but the user's library yielded no eligible candidates (degenerate empty-library). Returns 500 on actual build failure. Tests cover 200 with shape (track_count matches len(track_ids)) and 401 without auth.	2026-05-07 10:37:12 -04:00
bvandeusen	0ba31c7816	feat(server/playlists): manual Discover refresh endpoint ... POST /api/playlists/system/discover/refresh re-runs the system playlist build synchronously for the calling user, then returns their newly-built Discover playlist's UUID and track count. Used by the frontend's "Refresh" affordances (next task) on the Discover detail page header and the home Playlists row tile kebab. Operator's escape hatch when they want a different randomness without waiting for tomorrow's cron tick (e.g., after pasting a Last.fm key, after the daily cover-art enrichment expanded their playable library, or just for the heck of it). Authenticated user only; the authed sub-router's RequireUser middleware handles 401. Each user refreshes only their own Discover — no admin route, no cross-user impersonation. Adds GetSystemPlaylistByVariantForUser sqlc query for the response lookup. Returns playlist_id=null and track_count=0 if the build succeeded but the user's library yielded no eligible tracks (degenerate empty-library).	2026-05-07 08:39:26 -04:00
bvandeusenandClaude Sonnet 4.6	c53bcb6c99	feat(server/web/coverart): manual Re-search missing art button ... POST /api/admin/cover-sources/research bumps cover_art_sources_meta. current_version unconditionally; the next enrichment pass re-eligibles every 'none' row. Existing positively-sourced rows are not affected — the version-mismatch eligibility rule only kicks in for 'none'. Admin Cover Art panel gains a "Re-search missing art" button that calls the endpoint and shows a confirmation toast. Operator's escape hatch when: - They've added a Last.fm key and want to retry failed rows immediately rather than waiting for the next scheduled scan. - An upstream provider's catalog has updated (e.g. Deezer added a back-catalog import). - They want to verify a fix end-to-end before the next scheduled scan fires. SettingsService.BumpVersion (the unconditional version of T5's BumpVersionIfProvidersChanged) is the single-call DB writer; both endpoints route through it. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-07 07:59:40 -04:00