224 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	2e36e70268	feat(android): Sonos/UPnP queue plays leveled URLs, rendered a track ahead (M464 #5002) ... Every URL the Sonos queue loader sends is minted with level=true and the track's album-play verdict from its neighbours in the queue; the server returns the plain stream when leveling is off or changes nothing. The playing track and the one after it are rendered ahead, and each time the renderer moves on, the next is. Server: a mint no longer prerenders on its own. A queue load mints every track, which would have started an ffmpeg render per track at once. The request now carries prerender, and at most two prerenders run at a time; past that they are dropped, since a fetch renders on demand anyway. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 19:38:21 -04:00
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	aee4b50bd4	test(api): pass the loudness settings to Mount in the library test router (M464 #4995) ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 13:06:44 -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	46194a609d	fix(auth): build password-reset links from an operator-set public address, never the Host header (M462 #4981) ... buildResetURL used r.Host and r.TLS, so a forgot-password request with a forged Host emailed the victim a real reset token on a link to the attacker's server. Links now come only from network_settings.public_url (migration 0062), and no reset email is sent while it is empty; the response stays the same opaque 200 and the log says why. The address is set on a new "Public address" card under Admin → Integrations, which offers the page's own origin and warns while unset. PUT /api/admin/network-settings takes either field alone, so the proxy card and this one can't overwrite each other. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 09:32:10 -04:00
bvandeusenandClaude Opus 5.5	24b767c23b	feat(server): cap request bodies, bound body reads, private cache headers, JSON-only cookie writes (M462 #4979) ... - Every request body is capped at 4 MiB and must arrive within 30s. The deadline is set per request and cleared at end of body rather than via http.Server.ReadTimeout, which would cancel audio streams and the SSE stream once the background read hit it. - IdleTimeout 120s closes idle keep-alive connections. Still no global WriteTimeout, for the same streaming reason. - Streams, album covers and playlist covers are Cache-Control: private, so a shared cache never keeps an authenticated response for others. - A cookie-authenticated write to /api must be application/json (415 otherwise). SameSite=Strict can't see a sibling app on the same registrable domain; forms and no-preflight fetches can't send JSON. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 08:34:26 -04:00
bvandeusenandClaude Opus 5.5	755f997b0d	feat(auth): sessions expire server-side; password change and reset end other sessions (M462 #4978) ... Sessions had no server-side expiry: only the web cookie's 30-day Max-Age limited them, and a bearer token (Android) lived until revoked by hand. GetSessionByTokenHash and ListSessionsForUser now ignore sessions idle for 30 days or older than a year, and the GC worker deletes them hourly. A password change was a plain UPDATE, so a session opened with the old password survived it. Now: - self-service change signs out every other device and keeps this one; - reset by email ends every session the account has; - an admin reset ends the target's sessions (keeping the admin's own when they reset themselves). The success copy on web and Android says the other devices were signed out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 08:32:39 -04:00
bvandeusenandClaude Opus 5.5	719dc62b0d	fix(auth): set the session cookie's Secure flag behind a TLS-terminating proxy (M462 #4977) ... The cookie set Secure from r.TLS, which is nil whenever TLS terminates at Traefik or Cloudflare, so a public deployment's session cookie went out without Secure. auth.IsHTTPS now decides it from X-Forwarded-Proto, believed only through the trusted-hop count (rule 94) and read positionally like X-Forwarded-For. Plain-HTTP and LAN logins are unchanged; nothing redirects. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 08:30:46 -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	37d4906033	test(api): pass fingerprint settings to Mount in the route-registration test (M400 #3913) ... The unprefixed Mount call in library_test.go was missed when #3913 added the parameter, failing go vet. Also pins the fingerprint coverage, fingerprint settings and duplicates routes as admin-gated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 17:58:05 -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	d7a8e5f300	fix(library): a track delete that cannot remove its file deletes nothing — #3918 ... Two delete paths had opposite failure policies. tracks.RemoveTrack logged a failed os.Remove and deleted the row anyway, which CASCADEs likes, plays, playlist memberships and tags, while the file survived for the next scan to re-import as a stranger. library.DeleteTrackFile stopped correctly but reported it as a bare 500 nobody could read. One path now: library.DeleteTrackFile removes the file first and, on anything but ErrNotExist, returns *FileRemoveError with nothing deleted. Only then does it delete the row and tidy an emptied album and artist in one transaction, log the sync change and clear orphaned artist art. RemoveTrack calls it, which also fixes RemoveTrack never logging a sync change. Quarantine Delete file now tidies emptied albums and artists too. Both endpoints answer an unwritable library (EROFS, EACCES, EPERM) with 409 library_not_writable. The message names the directory (removal writes to the parent), the uid:gid the server runs as, and that nothing was deleted. Other remove errors are 500 file_delete_failed with the path. The reachable surface is quarantine Delete file, which failed silently: no copy for the code on either client, and Android swallowed the exception so the row just reappeared. Web and Android now have copy for both codes and append the server message for exactly those two. Android's quarantine screen shows it in a snackbar. DELETE /api/admin/tracks/{id} has had no client since f7278f24, which kept it on purpose for a safer admin surface, so its history loss was latent. Fixed rather than removed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 14:23:01 -04:00
bvandeusenandClaude Opus 5	eff3d88931	fix(recommendation): make the candidate draw reproducible, not accidentally so ... Four arms of the candidate query ended in a bare `ORDER BY random()` with no seed: similar_artists, likes_overlap, coplay_artists and random_fill. Such an arm returns a STABLE set only while its LIMIT exceeds the rows eligible for it — at that point it returns all of them and the order stops mattering, because scoreAndSortCandidates sorts by track id before drawing jitter. Below that threshold it returns a random SUBSET, and two builds on the same day draw different ones. So daily determinism held BY ACCIDENT, and only for libraries smaller than the limits. Any real library is larger, which means same-day rebuilds have been producing different mixes since those arms were written — invisible, because a mix that changes after a refresh looks like a feature rather than a broken promise. Found by breaking it: cutting RandomFill to 10 while tuning Songs-like turned TestBuildSystemPlaylists_DailyNonceDeterminism red. That test seeds ~20 tracks against a default RandomFill of 30, so its determinism came from the limit exceeding the library, not from the code being right. It is now a real guard. The arms order by md5(id || $12) instead. The CALLER decides what that means, which is the point: system mixes pass a per-(user, day) seed and get the determinism they promise, radio passes a fresh value per request and keeps varying, which is what a radio should do. Same shape the browse queries in this file already use (`md5(id::text || current_date::text)`) — existing idiom, not a new one. This also unblocks the trim that #3881 wanted and could not have. Shrinking a randomly-ordered arm was what broke membership; a seeded one takes a smaller but REPRODUCIBLE slice. Songs-like's seed-independent share drops from 29% to 12%, which was the original intent before determinism forced it back to 20%. TestSongsLikeLimits_DoNotShrinkTheUnseededRandomArms is DELETED rather than kept passing. It existed to stop anyone trimming those arms while the ordering was broken; the ordering is fixed, so the constraint is gone and a guard enforcing it would now forbid correct code. Was filed as blocked on tooling. It was not: `make generate-go` runs sqlc as a pinned Go tool and is the same path CI takes. One thing worth knowing for next time: three files in internal/db/dbq are owned by root, left by `make generate` running sqlc in Docker. sqlc errored on the first it could not write. They are untouched by this change and the regeneration of recommendation.sql.go completed, but `make generate` will keep failing until they are chowned. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 08:44:33 -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
bvandeusenandClaude Opus 5	633d4f591f	fix(radio): cap any one artist's share of a radio session ... Operator, 2026-09-10: started radio from a song and "literally all of the songs in the playlist after that were from a single artist which was not expected." There was no per-artist cap anywhere in the radio path. radio.go built the pool and handed it straight to Shuffle, which scores, sorts and takes the top N — nothing between those steps bounded any artist's share, so a pool dominated by one artist produced an output dominated by it. The asymmetry was the tell: discover.go, you_might_like.go and home.go all cap; radio never got one. With the fixture that reproduces it — 20 liked tracks by one artist plus 10 by ten others — the old path returns 10 tracks from 1 artist. It now returns 10 from 8. TWO PASSES, and that is the whole design. A hard cap was the easy mistake: radio asks for 50 tracks by default and 200 at most, so capping at three per artist over a concentrated pool would hand back a six-track "radio". Pass one takes candidates that fit under the caps; pass two fills any remaining slots from those it skipped, still in score order. The result always holds min(limit, len(candidates)) — the caps change WHICH tracks are picked, never HOW MANY. Rule 131's principle past the system mixes it was written for. The caps SCALE with the requested length rather than being a constant. Three-per-artist is a sensible 12% of a 25-track mix and an absurd 1.5% of a 200-track radio, where every selection would sit in the relaxation path and the cap would be decorative. RadioDiversityCaps holds the system mixes' proportion at any length: 3/2 at 25, 6/4 at 50, 24/16 at 200, with floors so a very short radio is not capped down to one track per artist. A BOUND, NOT AN EXCLUSION — the operator asked for the opposite of removal: "again it should be able to add songs from the same artist." The dominant artist still appears, just not exclusively. Guarded, because the tempting wrong fix is the filter songs-like used to carry. Shuffle grew the parameter rather than gaining a capped twin: radio is its only production caller, so a second function would have left the original dead (rule 22). Falsified against each named regression: uncapped gives 10/10 to one artist; a hard cap returns 3 of 10 on a single-artist pool; a cap-as-exclusion drops the artist entirely; a fixed cap stays 3 where the scaled one reaches 24. Caught while writing the guards: the artist-key constant was hand-written hex and wrong — the fixture's artist UUID carries 0001 in its fourth group, so the lookup missed and the assertion measured nothing. Derived from the same construction the fixture uses now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 22:14:42 -04:00
bvandeusenandClaude Opus 5	f367eeaa9d	fix(recommendation): Songs-like gets its own profile so it stops wandering ... Operator, 2026-09-10: "when I play it I'm expecting to get a consistent sound and style from the experience... I was getting a seeming wide variety of music from each one when I was hoping to stay in a certain neighborhood." Songs-like shared the `daily_mix` weight profile with For-You, and that sharing WAS the bug. The two surfaces want opposite things: For-You answers "what will they enjoy today" and is supposed to roam; Songs-like answers "what sounds like THIS". Under one profile the broad answer wins. The arithmetic, from the shared weights: unrelated track, liked, not played recently → 1.0 + 2.0 + 1.0 = 4.0 PERFECT similarity match, not liked → 1.0 + 1.5 = 2.5 Liking something outranked sounding like the seed, because LikeBoost (2.0) exceeded SimilarityWeight's whole range (1.5) and TasteWeight (1.5, and seed-INDEPENDENT) matched it outright. Under the new profile the same pair scores 5.00 vs 2.00. Two levers, because either alone leaves the other's failure intact: POOL. Songs-like now takes its own CandidateSourceLimits. The default gave ~29% of candidates a sim_score of literally zero — `taste_overlap` and `random_fill` are both `0.0::float8` in recommendation.sql, seed-independent by construction. Same total pool size; composition shifts to arms that measure distance from the seed, LBSimilar doubled. WEIGHTS. A third profile beside radio and daily_mix, DB-backed and live per rule 25, with the property that similarity's range exceeds the combined range of every seed-independent differentiator — so a closer match cannot be beaten on likes, freshness and taste alone, while tracks within ~0.39 similarity of each other still get ordered by what the user likes. Rule 131 changed the pool design mid-way and for the better. Zeroing the two seed-independent arms was the first instinct and is exactly the vanish-or-nothing shape that rule forbids: a seed with thin ListenBrainz coverage would yield a short mix or none. They are the tier-3 FLOOR — cut hard, never removed — and the weights keep them at the bottom of the ranking rather than out of the pool. "A few tracks further from the seed than we'd like" beats "no playlist". Caught while wiring it: switching only pickTopN's final Score would have been nearly INERT. scoreAndSortCandidates does the selection sort, and the caller caps and truncates in that order — so the playlist would still have been chosen by daily_mix and merely relabelled with songs_like numbers. It now takes the profile as a parameter, and each surface passes its own. Also corrects the daily_mix card's blurb, which claimed Songs-like as one of its surfaces and no longer is. Guards pin behaviour rather than the numbers, since numbers get retuned: that similarity beats an unrelated liked track, that daily_mix still DOESN'T (or the split buys nothing), that the tier-3 floor is non-zero, and that the UI card shows its own values rather than falling back. Each falsified against its named regression first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-10 20:51:15 -04:00
bvandeusenandClaude Opus 5	9f3e0b8cd3	feat(version): sidecar and /api/client/version carry name, code and channel ... The client compares names while Android installs by versionCode, and the wire had no way to close that gap: the sidecar was one positional line and the endpoint returned a name only. This is the plumbing that makes the ordering key decidable by the client at all. The sidecar is now JSON rather than a grown positional string. That shape was chosen against a specific failure: the obvious growth path was "<name> <code>", which a first-space split silently mangles the moment a third field appears — the code stops parsing as an integer and the reader falls back to name comparison WITHOUT erroring. JSON cannot mistake a new field for an old one. code is a POINTER on both sides, and omitempty on the wire. Absent has to stay distinguishable from zero: a build published before ordering keys were recorded genuinely has no code, and zero would claim it is infinitely old rather than unknown. A malformed sidecar now fails loudly instead of serving a blank version. If an unreadable file produced an empty name, every client would compare against nothing, conclude it was current, and go quiet — "I cannot read this" and "there is nothing newer" would return the same answer, which is the failure mode nobody reports because nobody is offered anything to report. The non-tag :latest path no longer RECONSTRUCTS the bundled APK's version. android-release now publishes the sidecar as a release asset beside the APK, and the image build downloads it. The old reconstruction duplicated a derivation formula across two files, and could only ever recover the name — the ordering key is build-time minutes and exists nowhere once that build ends. Releases predating the sidecar report their name with a null code, which is the honest answer rather than a guessed one. image-release also drops to a shallow checkout: it needed full history and tags only to re-derive versions from the tagged commit, and now touches git for nothing. MINSTREL_VERSION comes from GITHUB_REF. Two things checked rather than assumed. The Android Json sets ignoreUnknownKeys, so the added fields cannot break already-installed apps. It also sets coerceInputValues, which will silently turn a null code into 0 if step 4 declares the field non-nullable — recorded on task #3811, because reading the field declaration alone would never reveal it. Also fixes a stale comment block describing "the Flutter client", deleted in v2026.08.18. Step 3 of 5 — Scribe task #3810, milestone #390. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-09 21:51:41 -04:00
bvandeusen	955a61194e	fix(library): a fully-missing album leaves the year axis too — #2702 ... Filed as a product decision, but the code had already made it: the genre queries filter tracks.missing_since inside their EXISTS, so an album whose every file had gone was ALREADY absent from genre while still listed under its year — where opening it found nothing playable. The two browse axes disagreed, and whichever answer won, one of them had to change. Hiding is the answer. Browsing is how you go looking for something to play, and the rule for that case is to take it out of view; the admin missing-files surface is where absence gets reported, with far more detail than a silent gap in a grid. It also means changing the axis that was inconsistent rather than the one that was already right. All three year queries move together — index, list and count. That is the invariant #367 needed care for at the genre level: if the index groups differently from the filter, a year leads to an empty page, and if the count disagrees with the list then "Load more" promises rows that never arrive. The predicate is "has at least one playable track", which also excludes an album carrying no tracks at all. Same answer for the same reason — nothing to play, nothing to browse to — and it is what genre has always done, since an album with no tracks contributes no genres either. That last part changed two existing tests, which had been seeding trackless albums as a convenience. Their intent (undated albums never appear in a range) is untouched; they now seed a track each, which is what a real album looks like anyway. Two new tests pin the actual behaviour: a fully-missing album leaves the axis while a half-missing one stays, and the count agrees with the filtered list.	2026-08-17 13:38:08 -04:00
bvandeusen	366692a1fc	fix: stop the sync feed hiding missing files from clients — #2704 ... #2523 filtered missing tracks out of every path that CHOOSES music, but the client sync feed was never touched: GetTracksByIDs has no filter and the wire had no field for it. So every Android client held a cached library containing tracks whose files are gone, with no way to tell, and could queue them from any cache-first path -- the exact failure #2523 existed to prevent, reached by a different route. Ships the state rather than filtering the feed, of the two options the ticket weighed. A missing file is expected to come back: the scanner clears the mark, and adopts the row if it returns renamed (#2528). Withholding the row would mean a delete-and-recreate on every client for what is usually a transient unmount, churning caches and throwing away the identity #2528 works to preserve. Room goes to v8. No hand-written migration: the pre-v1 destructive fallback rebuilds from sync, which repopulates every row with the new column -- exactly the case that policy exists for. The interesting part was working out what "missing" means to a client, and it is NOT "unplayable". Two findings shaped the fix: Server search and album detail never filtered missing tracks either, and that turns out to be right rather than an oversight. The consistent rule the codebase already follows is that Minstrel never PICKS a missing track for you -- recommendation, discover, mixes and browse all exclude them -- but it does not hide one you went looking for by name or opened an album to find. Hiding track 4 makes an album look wrong. So the fix is to mark and to keep it out of queues, not to hide it. And a track whose server file is missing still plays perfectly if its audio is already in the device cache. ShuffleSource's offline pools filter to exactly those residents, so it now clears the mark on the way out: the bytes are local and the server's loss is irrelevant. Without that, the queue filter below would have thrown away tracks that work, turning a fix into an offline regression. The queue protection is one choke point rather than five call sites. setQueue is where playlists, album play-all, search, radio and cold-boot resume all converge. dropUnavailable is pure so the index arithmetic is pinned by tests -- removing entries ahead of the requested position would otherwise start playback on the wrong track, and asking to start on a missing track now starts the next playable one, which is the "gets skipped" behaviour the operator asked for. An entirely missing queue returns empty and the caller leaves the player alone rather than replacing what is playing with silence.	2026-08-17 12:56:31 -04:00
bvandeusen	414dfb23b6	feat: show what re-acquisition has done, per folder — #2527 ... Completes milestone #290. The sweeper has been running and the settings have been editable, but the list itself said nothing about either, so the only way to tell "not tried yet" from "asked twice and nothing came back" was to go and read the Requests queue. Each folder now carries its album's attempt record: how many times, when last, when next -- or that it gave up, with the reassurance that a file coming back and going missing later starts the process over. Null when nothing has been attempted, which is the common case for a folder that just went missing and would be noise on every row. next_attempt_at is computed, not stored. The schedule is a function of the attempt count and the current settings, so persisting it would go stale the moment an operator edited the backoff -- and the card lets them do exactly that. Needed a forward-looking formatter. relativeTime deliberately collapses a future timestamp to "just now" (pinned by its own test) because that is the right answer for a clock-skewed past event; it is the wrong one for a scheduled future attempt, which would have rendered "next just now". timeUntil is its companion rather than a sign-aware rewrite: the two read differently in the same sentence -- "last tried 3d ago, next in 4h" -- and a test asserts they disagree about the future on purpose, so nobody later "fixes" the divergence. The state lookup is one batched query for the whole page and best-effort: this is context on a list whose real job is showing what is missing, so a failure leaves the groups bare rather than failing the page. The settings service is read with a nil guard falling back to the shipped defaults, since contexts that wire routing without services exist and a backoff projection is not worth a nil-pointer panic (rule #48).	2026-08-17 00:19:48 -04:00
bvandeusen	c2862e97bd	test(api): cover the missing-file admin routes in the Mount test — #2527 ... go vet caught the Mount signature change: library_test.go calls it from inside the package, so the earlier grep for "api.Mount(" missed it. Rather than only appending the argument, the route table now includes both admin surfaces from this arc. That test exists to prove every route is actually registered — a 404 there means the route is missing — and the two paths added today had no such coverage. Both are in the admin group, so reaching the 401 is what proves they are wired. The new service is passed as nil, matching the other optional services in this call: the test asserts routing, never executes an admin handler, and constructing a settings service would need a pool round-trip for nothing.	2026-08-17 00:07:10 -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	03a8d12079	docs: stop pointing at the deleted Flutter tree — #2710 ... Every comment naming a path in flutter_client/ now resolves to nothing, which is the failure mode this project has already been bitten by twice -- drift #572 came from delete.go describing behaviour it no longer had, and that same docstring was still wrong when it was fixed last week. A pointer to a deleted directory is the same thing in slower motion: the reader follows it, finds nothing, and cannot tell whether the comment is stale or they are looking in the wrong place. Three treatments, per what each comment was actually doing: - Naming a concept ("mirrors db.dart's CachedTracks Drift table"): keep the concept, drop the path. The Drift table is why the entity looks as it does; the file it lived in is not. - Pure port bookkeeping ("Mirrors <path>." and nothing else): deleted. Git history records the port; the comment only restated it. - Substance introduced by a pointer (a lifecycle list, a 200 px/s threshold, an inverted control-row placement): keep the substance, drop the lead-in. The two Go comments were the valuable ones and got more than a trim. They stated a live contract -- "field names match the client's FromJson helpers exactly, or fields are silently dropped" -- against a client that no longer exists. They now name the real consumer, SyncResponseWire.kt, and say why the failure is silent there too: kotlinx.serialization skips unknown keys, so a renamed field arrives as a default value rather than an error. The ticket counted 64 files by grepping flutter_client/. A second tier turned up during the sweep: 15 more references naming bare Dart files (player_bar.dart, now_playing_screen.dart:464, auth_provider.dart) with no directory prefix. Same dead tree, same treatment, folded in here. Comments only -- verified no non-comment line is touched in the diff.	2026-08-16 22:40:58 -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	c3f3a17c6d	feat(library): a missing file stays in the playlist, greyed and unplayable — #2527 ... Every browse, discover and mix query filters missing_since, so a track whose file vanished disappears from the places Minstrel chooses music. A playlist is different: the entry is there because the user put it there, and silently dropping it rewrites their list behind their back. So playlists keep the row and mark it instead. ListPlaylistTracks now carries missing_since (still deliberately unfiltered), the service layer surfaces it as PlaylistTrack.Unavailable, and the wire gains "unavailable" on each entry. A missing entry also loses its stream_url. Refusing to hand out a URL that cannot serve is stronger than trusting every client to honour the flag, and "stream_url": null is a shape the clients already model -- PlaylistWire.streamUrl is documented nullable for the track-removed case -- so an older build degrades to "present but not playable" with no change. Nothing is deleted here and nothing should be: the row, its play history, its likes and its taste contribution all survive a file going missing, because the file may come back (and #2528 will adopt it if it comes back renamed). Also corrects two comments that had drifted into lying. delete.go still claimed the file-gone case was NOT auto-reconciled and told admins to delete rows by hand -- untrue since f6d1cf24, and that exact staleness is what produced drift #572. It now says what DeleteTrackFile really is: the destructive admin action, which CASCADEs play_events and likes, and is emphatically not the missing-file path. watcher.go claimed the safety-net scan "covers anything missed"; the walk only covers additions, and it is reconcile that covers removals.	2026-08-16 11:43:05 -04:00
bvandeusen	481f906059	feat(metrics): publish margin of error on every delta — #2495, #2524 ... The metrics card had one volume threshold doing two jobs. recMetricsLowVolume = 20 is a DISPLAY floor — below that a skip rate is anecdote — but the card then presented deltas as though it were also a DECISION floor. Those differ by an order of magnitude: detecting the ~13pp differences that matter needs ~133 plays per arm for 80% power at a=0.05. So Discover's taste-matched (59 plays) and random-unheard (70) both rendered as full-confidence rows with a bold delta beside them, and that comparison sits at p ~ 0.06. The card said "signal"; the arithmetic said "maybe". It produced a recommendation the data didn't support, and any reader with the same numbers would have made the same call. Deltas now carry a 95% margin of error and a `distinguishable` flag, computed server-side so both clients read the same arithmetic instead of each re-deriving it. Skip rate is a two-proportion difference; completion is Welch, which needs a variance — hence completion_sqsum in the query. It is the sum of squares rather than stddev_samp on purpose: raw source rows are merged into surface families in Go, and sums of squares combine across groups exactly whereas standard deviations cannot. recMetricsLowVolume is untouched. "Too thin to show" and "too thin to act on" are different questions. Web renders an indistinguishable delta as dimmed and prefixed "≈", with the range on hover and a legend explaining the glyph. Colour is withheld unless the delta clears its margin — colouring noise red is what made the old card misleading. Breakdown rows go through the same path; those are the thinnest samples on screen and where the old card misled most. Also fixes the admin trends view, which had the same problem worse: its "Latest skip"/"Latest completion" columns are one WEEK while the adjacent Plays column is the whole window. I misread exactly that and briefly concluded Deep cuts was the worst surface, from ~17 plays in a single week — over 180 days it is one of the best. Headers now name their period and the skip cell carries that week's play count. #2524: resolveArtist now recognises a duplicate-MBID unique violation as the expected condition it is, matching resolveAlbum. Two rows mapping to one MusicBrainz artist is a merge candidate, not a fault; without the branch it logged a generic warning plus a Postgres ERROR line on every scan, which teaches an operator to ignore database errors.	2026-08-06 21:08:58 -04:00
bvandeusen	37b396a7e4	fix(scanner): read multi-value genre frames correctly — #2499 ... dhowden/tag's readTFrame splits ID3v2 null-separated multi-value text frames and rejoins them with the EMPTY string, so a file tagged "Alternative Rock" + "Rock" was stored as "Alternative RockRock". It also leaves bare numeric ID3v1 references unresolved, which is why the library showed genres like "4017" and "526617". This corrupted more than the browse axis added in #367: taste_profile.sql reads tracks.genre directly, so the welded tokens were entering the taste profile's tag vocabulary, and recommendation.sql/discover.sql were comparing them as single opaque tags. Genre counts were wrong everywhere. ffprobe is not a fix — ffmpeg's read_ttag calls decode_str once with no loop, keeping only the first value. Truncating multi-genre tags would blunt the similarity signal genre mainly feeds. So the TCON frame is now parsed directly (ID3v2.2/2.3/2.4, all four text encodings, per-frame and tag-level unsynchronisation, numeric and parenthesised ID3v1 references); everything else still comes from dhowden/tag. Values are stored ";"-delimited, which the read side already splits on, so no query changes. Existing rows are repaired without an operator-run rebuild: migration 0054 adds tracks.tag_read_version DEFAULT 0, below the scanner's current tagReadVersion, so the next scan re-reads tags it would otherwise skip on mtime. Such a re-read reuses the stored duration instead of re-running ffprobe, keeping a repair pass tag-read-bound rather than one fork+exec per file. Bumping the constant is how a future extraction fix reaches an existing library. Only ID3v2 is in scope — dhowden welds nowhere else. The Vorbis/MP4 repeated-field question is #2500, unproven and deliberately not built.	2026-08-05 21:17:59 -04:00
bvandeusen	a9ca49dc4e	feat(library): genre + year quick-jumps on album and artist detail — #367 ... Last bullet of #367. From an album you like, one click to everything else from that year or in that genre. Year was free — AlbumRef already carried it. Genre was not: AlbumDetail is AlbumRef + tracks and neither carried genre, because genre lives on TRACKS. So both detail responses gained a derived `genres` array, computed from the entity's tracks rather than stored, since an album's tracks can legitimately disagree about genre. Split and trimmed identically to the browse index. That's the invariant this whole task turned on: if the chip's matching diverged from the index's splitting, a chip would lead to a page that doesn't contain the album you clicked from. No year link on artist detail. An artist spans many years, so a single one would be a lie about the discography — genres only there. Genre lookup failure is logged and degrades to no chips rather than failing the request; a navigation nicety must not 404 a detail page that otherwise loaded. `genres` is always an array at JSON, never null, matching how every other list field in this package is emitted. ## Type widening, and the TypeScript version of a lesson from earlier today Adding a required field to AlbumDetail/ArtistDetail breaks every typed fixture that constructs one. Six of them across three test files. That's the same shape as the Go signature changes that cost three CI rounds in #2453 — change a type, then go find everything that builds it — so I searched for the constructions before pushing instead of after. All six updated. Tests: the encoded href for a slash-bearing genre ("Rock/Pop" → ?g=Rock%2FPop), the year href, and the no-tags case rendering no chips at all. gofmt verified clean via docker rather than guessed.	2026-08-05 13:50:29 -04:00
bvandeusen	f8f2273aec	style: gofmt alignment in library_browse_test — #367 ... One space. `name:` had to align with `query:` inside a composite literal where both sat on their own lines. Found via `docker run golang:1.25-alpine gofmt -l`, which is the actual point of this commit: gofmt is available here the same way sqlc is, and there is no reason to have let CI discover a formatting nit. Whole tree verified clean, not just this file. The substance of 1126bfcf was already sound — verify-generate, vet and the full integration suite passed, so the genre-splitting behaviour holds against a real database. Only the formatter objected.	2026-08-05 13:29:28 -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	d5ab3b0764	fix(net): update the in-package Mount call site in library_test — #2453 ... Third attempt at the same class of mistake, so worth naming precisely. TestRoutesRegisteredInMount calls Mount() from INSIDE package api, so the call reads `Mount(...)` unqualified. My verification grep was `api.Mount(`, which cannot match it. Same shape as the previous failure, where I grepped `auth.ClientIP(` and missed nothing — but only because those callers happened to be in other packages. The lesson generalises: after changing an exported signature, search for the bare identifier, not the package-qualified form. In-package callers — which in Go means most tests — are invisible to the qualified pattern. This time I swept every signature I touched (Mount, RequireUser, ClientIP, TouchSessionLastSeen) with an unqualified pattern before pushing, rather than letting CI enumerate them one per run. Passing h.netSettings (nil in test handlers) is deliberate, not a placeholder: this test asserts route registration, and Hops() is nil-safe by design so the middleware reads "trust nothing" rather than panicking. Also gave netsettings' logger field a use — it was assigned and never read, which staticcheck's unused pass can flag. A hop-count change alters how much of a client-supplied header the server believes, so it earns a log line for anyone later debugging odd addresses in the sessions list.	2026-08-05 10:21:16 -04:00
bvandeusen	a07fb3867a	fix(net): thread hops into session creation; disambiguate card tests — #2453 ... Two CI failures from 381e9ced, both mine. **Go (vet, which cascaded into the integration job).** Widening auth.ClientIP to take a hop count, I updated the middleware that TOUCHES a session but missed the two places that CREATE one — handleLogin and handleRegister. So `created_ip`, the frozen origin address that the whole "address changed" comparison rests on, was the one value still being computed the old way. Both now read h.netSettings.Hops(), which is nil-safe so test handlers constructed without the service still work. Worth noting the shape of this miss: I checked call sites by searching for the middleware's own usage and stopped there, rather than for every caller of the function whose signature I changed. vet found it in seconds; a grep for `auth.ClientIP(` would have too. **Web (vitest).** Three tests waited on `findByText('198.51.100.7')`, which matches TWO elements in the fixture — the detected client address and the forwarded chain, identical strings for a single-proxy setup — and findByText throws on multiple matches. Now they wait on the unique "Your address right now" label and assert the address with getAllByText where duplication is legitimate. The duplication is correct behaviour, so the test moved rather than the component.	2026-08-05 10:14:38 -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	799dab029a	feat(discover): rank suggestions by taste-tag overlap — #2377 (server) ... The payoff slice. Until now a candidate's only claim on a slot was "some artist you play is adjacent to it in a similarity graph" — a fact that says nothing about whether the music sounds like anything you like. Now the candidate's own folksonomy tags (cached by slice 5) are compared against the user's taste-profile tags, so the deck ranks on taste and can say WHY. The blend is MULTIPLICATIVE — score × (1 + weight × overlap) — and that choice carries the whole safety argument: - An untagged candidate has overlap 0, so its score is EXACTLY unchanged. Tag coverage is permanently partial (#2376); it must cost a candidate nothing, not sink it (rule #131). - Nothing can leapfrog on tags alone. An additive term with a large weight would let a near-zero-similarity artist outrank a strong match for sharing one popular tag, which reads as noise. - Weight 0 restores pure similarity order bit-for-bit, so the operator's knob has a real off position. overlap = Σ(shared) candWeight × normalizedTasteWeight ÷ Σ(all) candWeight. Normalizing the taste side by the user's strongest tag makes the score comparable across users (taste weights accumulate with listening, so a heavy listener's raw numbers dwarf a new user's while meaning the same thing). Dividing by the candidate's own mass makes it comparable across candidates, so a densely-tagged artist can't win on tag count alone. Applied to the whole over-fetched pool BEFORE selectSuggestions, so the rotation and diversity rules operate on blended scores — boosting only the twelve already chosen by similarity would leave the re-ranking undone. A query failure is returned, NOT degraded past. Graceful degradation is for expected absence (no taste profile, no cached tags) and both are handled explicitly as empty inputs; swallowing a real error would hide a broken DB behind a subtly worse ranking that nothing reports. Migration 0051 adds a FOURTH tuning scope rather than columns on taste_tuning, because snooze_days lives here too and a snooze must never be read as taste signal (#2374) — filing it under 'taste' would put it one careless join from the leak that design forbids. Expanding recommendation_tuning_audit's CHECK is in the same migration per rule #36, and a test asserts the audit row lands, which is what would catch its absence. snooze_days moves out of a Go constant onto the tuning card (rule #25), closing the deferral from #2374. Tag-overlap tests use deliberately SKEWED fixtures: an evenly-matching pool cannot exercise a re-ranking, since every candidate gets the same multiplier and the order is unchanged whether the blend works or not. Admin UI + client attribution follow in this batch — rule #27. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 20:31:12 -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	5749f48b4a	feat(taste): device-class context conditioning — #1551 ... Milestone #160 Opt 3b. Adds device class as a third context axis on top of the #1531 time-of-day/weekday affinity: on the radio path, a candidate is boosted when its artist concentrates in the current (daypart × weekday × device) cell. Client-sent (client_id is opaque; no UA stored), so it's captured going forward and applies to radio only (daily mixes are cron-built with no device → stay device-agnostic). Server: - Migration 0048: play_events.device_class text NULL (no CHECK; normalized in Go — one whitelist entry per new client class, not a migration). - events.go: eventRequest.device_class + normalizeDeviceClass (whitelist → mobile/web/…, else "other", empty → NULL); threaded through both RecordPlayStartedWithSource and RecordOfflinePlay into InsertPlayEvent. - ListArtistContextPlayCountsForUser gains a current-device param; the cell FILTER adds AND ($2='' OR device_class=$2) — '' reproduces the #1531 time-only behaviour exactly (used by mixes). SessionVector.DeviceClass carries it; the radio handler derives the current device from the user's latest play (GetLatestPlayDeviceClassForUser) — request-free proxy. - No new tuning knob: device narrows the existing ContextAffinityScore (reuses context_time_weight). Clients: - web: play_started sends device_class 'web'. - android: play_started + offline replay send 'mobile' (EventsWire + PlayOfflinePayload + MutationReplayer + PlayEventsReporter). Test: LoadContextAffinity device-narrowing integration test (mobile vs web artist separation; device-agnostic parity). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 12:47:59 -04:00
bvandeusenandClaude Opus 4.8	f0c08e7326	feat(taste): mood taste facet — #1534 ... Milestone #160 Opt 2b (mood half of the era+mood option). A fourth taste facet alongside artists + genre tags + eras: signed weights over canonical mood buckets (melancholic / energetic / chill / …) derived from a track's enriched folksonomy tags (#1490). - internal/mood: shared vocabulary — Of(tags) maps folksonomy tags to canonical mood buckets (synonyms collapse). Imported by both the taste builder and the scorer so a track's mood is derived identically. - Migration 0047: taste_profile_moods table + taste_tuning.mood_scale (DEFAULT 0.5). - Build side (internal/taste): Config.MoodScale ([0,1] damper, mirrors EraScale); accumulate folds each play/like's mood buckets at base*MoodScale; persist atomic-replaces the mood rows. - Scorer (internal/recommendation): TasteProfile gains a mood term (own tanh scale + additive 0.12 share, so it never weakens the existing signal when a track has no mood tags). Match now takes the candidate's mood buckets; loaded per candidate (ListTrackTagsForTracks → mood.Of) in the primary similarity loader only — the near-whole-library fallback pool passes nil (mood → 0) to avoid a full-library tag scan. - Tuning lab: mood_scale threaded through recsettings + admin API + web card ("Mood weight" row) + Go/web tests. Coverage is partial (grows with tag enrichment; richer once Last.fm is keyed), so mood is a supplement — neutral for tracks with no mood tags. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 10:32:41 -04:00
bvandeusenandClaude Opus 4.8	65dd132b3d	feat(taste): time-of-day / weekday context conditioning — #1531 ... Milestone #160 Opt 3 (temporal half). A new additive scoring term that boosts a candidate when its artist's play history concentrates in the CURRENT daypart × weekday-type cell, in the user's local timezone. - Migration 0046: recommendation_weight_profiles.context_time_weight (per-profile scoring weight, DEFAULT 1.0). - Query ListArtistContextPlayCountsForUser: per-artist completed-play counts split by the current cell (daypart night[22,5)/morning[5,12)/ afternoon[12,17)/evening[17,22) × weekday-vs-weekend) via started_at AT TIME ZONE users.timezone; 365-day window, skips excluded. - internal/recommendation/context.go: LoadContextAffinity computes each artist's shrunk cell-share minus the user's baseline share, clamped to [-1,1]; sparse artists shrink toward baseline (pseudo-count 5), unknown artists → 0 (cold-start neutral). - Score() gains context_affinity_score · ContextTimeWeight; both candidate loaders set it per candidate. - Tuning lab: ContextTimeWeight threaded through recsettings + admin API + web card ("Time-of-day weight" row) + Go/web tests. Shipped 1.0 both profiles (uniform start, re-bakeable). Device-class axis deferred to #1551 (needs a client_id → device-class mapping that doesn't exist yet). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 09:31:43 -04:00
bvandeusenandClaude Opus 4.8	40384cc05e	feat(taste): era/decade taste facet — #1530 ... Milestone #160 Opt 2 (era half). A third taste facet alongside artists + genre tags: signed weights over decade buckets ("1990s") derived from albums.release_date, rebuilt daily and scored into the taste match. - Migration 0045: taste_profile_eras table (mirrors taste_profile_tags) + taste_tuning.era_scale column (DEFAULT 0.5). - Build side (internal/taste): Config.EraScale ([0,1] damper, mirrors EnrichedTagScale), accumulate folds each play/like's decade at base*EraScale, persist atomic-replaces the era rows. - Scorer (internal/recommendation): TasteProfile gains an era term (own tanh scale + additive 0.15 share so it never weakens the existing artist/tag signal when a track is undated); candidate queries return album release_date; decadeOf mirrors the builder helper. - Tuning lab: era_scale threaded through recsettings + admin API + web card (auto-renders the new row) + Go/web tests. Mood facet deferred to #1534 (partial enrichment coverage + needs candidate-side enriched-tag loading). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 09:01:00 -04:00
bvandeusenandClaude Opus 4.8	2b3be8311a	feat(tuning): expose EnrichedTagScale in the tuning lab (#1520) ... Promote the enriched-tag weight (#1490) from a taste.Config default into the DB-backed tuning lab so operators can dial how much folksonomy tags count vs raw ID3 genre (rule #25). - Migration 0044: taste_tuning.enriched_tag_scale (DEFAULT 0.5, backfills the existing row). - recsettings: TasteTuning gains the field; seeded/read/updated through reconcile + persistTaste; applyTastePatch validates it to [0,1] (generic non-half-life clamp) and diffTaste audits it; TasteConfig maps it into the profile build. - API: tasteTuningResp exposes enriched_tag_scale. - Web tuning card: a data-driven "Enriched tag weight" knob (0 = genre only). Tests: recsettings persist+range, web fixture field. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-14 07:51:36 -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