The previous attempt opted out of AGP 9's built-in Kotlin (via
android.builtInKotlin=false + explicit kotlin-android plugin) because
the message from Gradle suggested it. But Kotlin 2.2.21's
kotlin-android plugin can't cast AGP 9's new ApplicationExtension to
the removed BaseExtension:
class ApplicationExtensionImpl$AgpDecorated_Decorated
cannot be cast to class com.android.build.gradle.BaseExtension
That suggestion is for projects with an older Kotlin toolchain. The
real fix:
- Kotlin 2.3.21 (latest stable; first line where kotlin-android also
supports AGP 9, but more importantly the built-in path works)
- KSP 2.3.8 — KSP PR #2674 (merged Oct 2025) added AGP 9 built-in
Kotlin support. KSP 1.x and pre-2.3 don't work with built-in Kotlin.
- Re-drop the kotlin-android plugin from both build.gradle.kts files;
AGP 9 enables built-in Kotlin by default and KSP 2.3 cooperates.
- Remove android.builtInKotlin=false from gradle.properties.
compose-compiler plugin tracks the Kotlin version via version.ref, so
no separate bump there.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AGP 9 enables built-in Kotlin by default (`android.builtInKotlin=true`),
which we initially adopted by dropping the `kotlin-android` plugin
alias. But KSP isn't compatible with built-in Kotlin yet — Gradle
errors out with:
> KSP is not compatible with Android Gradle Plugin's built-in Kotlin.
> Please disable by adding android.builtInKotlin=false to gradle.properties
> and apply kotlin("android") plugin
Restored the explicit kotlin-android plugin (root + :app) and added
`android.builtInKotlin=false` to gradle.properties. Revisit when KSP
gains built-in-Kotlin support.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`kotlinOptions { jvmTarget = "17" }` inside the `android { }` block was
removed in newer Kotlin tooling; replaced with the modern top-level
`kotlin { compilerOptions { jvmTarget.set(JvmTarget.JVM_17) } }` form.
Required after the Kotlin 2.2 + AGP 9 bump; the old DSL was tolerated
through AGP 8.7 + Kotlin 2.0 but not through AGP 9's built-in Kotlin.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Hilt 2.52 referenced AGP's old BaseExtension which AGP 9 removed,
causing ktlintCheck to fail at plugin-application time:
Failed to apply plugin 'com.google.dagger.hilt.android'.
> Android BaseExtension not found.
Dagger/Hilt 2.59+ adds AGP 9 support (and mandates it for the Gradle
plugin path). 2.59.2 is the current latest.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Original 8.x toolchain choked on the ci-android image's JDK 25 with an
opaque "25.0.3" error in `ktlintCheck`; Gradle 8.10's JDK compat matrix
caps at 23. Modern chain:
- Gradle 9.1.0 (first to support JDK 25)
- AGP 9.0.1 (requires Gradle 9.1+, requires Kotlin 2.2.10+)
- Kotlin 2.2.21 / KSP 2.2.21-2.0.5 (latest 2.2.x line)
- Compose BOM 2026.05.01 (current; pulls ui-text-google-fonts at the
BOM-managed version, so the explicit pin was dropped)
AGP 9.0 breaking changes that affected us:
- `kotlin-android` plugin no longer needed — AGP 9 auto-enables via
`android.builtInKotlin=true` default. Removed alias from both the
root build.gradle.kts and :app/build.gradle.kts.
- `applicationVariants` API removed; we don't use it.
- Other defaults flipped (useAndroidx, uniquePackageNames, etc.) but
we already set them explicitly or weren't relying on the old defaults.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
M8 phase 2.1. Runs on every push to dev/main + PR to main (path-filtered
on android/**). Tag pushes (v*) additionally build a signed release APK
attached to the existing Forgejo release as minstrel-android-<tag>.apk
during the side-by-side period; that name flips to minstrel-<tag>.apk
at M8 phase 14.4 cutover.
Reuses ANDROID_KEYSTORE_B64 + STORE/KEY_PASSWORD + KEY_ALIAS secrets so
signing matches flutter.yml — Android accepts upgrade in place at cutover
without uninstall.
runs-on: flutter-ci because that's the only proven-working runner label
on this Forgejo instance with docker. Switch to android-ci once that
label gets registered.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
M8 phase 1.4. Mirrors flutter_client/lib/theme/. Source of truth for hex
values is flutter_client/shared/fabledsword.tokens.json (manual sync until
cross-language codegen lands; ports the dark-surface + flat cohort).
Material 3 ColorScheme takes accent as primary; action colors
(Moss/Bronze/Oxblood) live in LocalActionColors as semantic roles per the
project_design_system rule "NEVER use accent for action buttons".
Typography uses androidx.compose.ui.text.googlefonts to fetch Fraunces /
Inter / JetBrains Mono at runtime via Play Services Fonts — matches the
Flutter client's `google_fonts` package (no bundled .ttf files in either
tree). Weights restricted to 400/500. Fraunces is reserved for ≥18sp
display/headline slots per the design-system rule.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
M8 phase 1.3. Plants the Hilt entrypoint so the rest of the modules
(NetworkModule, DatabaseModule, PlayerModule) can land in subsequent
phases. WorkerFactory wired so HiltWorker can be used directly later.
Restores @AndroidEntryPoint on MainActivity (deferred from 1.2 since
Hilt KSP errors without an annotated Application class).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
M8 phase 1.2. AndroidManifest declares FGS mediaPlayback +
POST_NOTIFICATIONS permissions ahead of the player phase. Activity
hosts a single Compose Scaffold for now; nav graph lands in phase 5.
Launcher icons reused from flutter_client/ (same applicationId means
same brand at cutover). MinstrelApplication referenced in manifest
but the class itself lands in Task 1.3 — manifest class names are
resolved at install time, not build time, so the intermediate commit
still builds.
@AndroidEntryPoint deferred to Task 1.3 alongside @HiltAndroidApp on
MinstrelApplication (Hilt KSP errors without an annotated Application).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
M8 phase 1.1: empty multi-project Gradle scaffold (root + :app
placeholder). Version catalog establishes pinned Kotlin/AGP/Compose/
Hilt/Room/Media3/etc. versions for the whole module.
Gradle wrapper (8.10) reused from flutter_client/ — the wrapper jar
is a bootstrap and respects distributionUrl from gradle-wrapper.properties.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Last meaningful-feature release on Flutter. Ships:
- #472: notification + Wear OS controls stay live across idle
teardown (audio_handler softTeardown split)
- #479: system-playlist tap surfaces empty / slow / failed
states with SnackBar feedback
- #399: drift test cohort re-enabled on ci-flutter:1.26
- Tier-A deps sweep (audio_session 0.2, flutter_lucide,
permission_handler), Go server bumps, golangci v2 schema,
Flutter 3.44 ListTile strictness fixes
Future Flutter releases on this codebase are bugfix-only; the
v1 Android native rewrite has been planned.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
pubspec.yaml already requires audio_session ^0.2.3, flutter_lucide,
and permission_handler as direct deps (committed in earlier sweeps)
but the lock file on HEAD was stale — still referenced audio_session
0.1.25 transitive, missed flutter_lucide / permission_handler
entirely, listed the now-dropped cupertino_icons.
Regenerated locally via `dart run build_runner build` (which runs
`flutter pub get` first). Also picks up an in-range
flutter_secure_storage 10.1.0 -> 10.2.0 patch bump.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Wear OS companion app's MediaController caches the MediaSession
token at first bind. When our idle timer fired super.stop() — which
calls stopSelf() on the AudioService and makes it eligible for OS
destruction under memory pressure — the next play() spun up a fresh
MediaSession with a different token. The companion's cached controller
still pointed at the dead one, so transport taps from notification
+ watch silently no-op'd even though PlaybackState broadcasts kept
flowing (those go through the live session). User-side workaround
was unpair/repair of the Watch.
Split stop() into:
- _softTeardown: stops the player, clears mediaItem/queue, broadcasts
idle. Display surfaces drop their visible state (this is what made
notification + watch tile cleanup work today; not super.stop()).
- stop(): _softTeardown + super.stop(). Reserved for explicit close
(onTaskRemoved while idle).
_onIdleTimeout now calls _softTeardown — the FGS + MediaSession stay
alive across idle, preserving the Wear binding. Explicit user-close
still terminates the service fully.
Diagnostic debugPrints from the investigation phase removed.
Research: ryanheise/audio_service 0.18.18 has been stale ~13 months,
no Media3 migration in flight upstream. This is the surgical fix
that respects the plugin's lifecycle contract.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tapping a system-playlist PlayCircleButton before the mix had loaded
silently stalled — three failure modes all looked identical to the
user (PlayCircleButton's spinner clears with no playback):
- api.systemShuffle returns empty (mix not built server-side yet)
→ silent return at `if (refs.isEmpty)`
- api call slow / hung → spinner spins indefinitely (no client
timeout was set; Dio default is unlimited)
- api throws → uncaught; spinner finalizer clears it silently
Bundle:
- 8s `.timeout` on the systemShuffle / get call; TimeoutException
→ "Couldn't load playlist — check your connection"
- empty refs after filtering → "Mix isn't ready yet — try again
in a moment"
- other throws → "Playlist load failed: <error>"
- thread BuildContext through and capture ScaffoldMessenger before
the first await so no `use_build_context_synchronously` lint
No pre-warm — system playlists are intentionally uncached per the
api endpoint comment ("varies per play"); pre-warming would decide
the shuffle order at home-screen load instead of at tap, breaking
the fresh-per-play contract.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The 'flag keeps drift optimistic + queues mutation on server failure'
case trips a StreamProvider<bool> lifecycle issue when the async catch
path's awaited MutationQueue.enqueue → unawaited drain() chain reads
connectivityProvider.future. The other 3 quarantine tests pass with
the same _container helper (incl. the never-closing connectivity
override); only the throw variant surfaces this. Full diagnostic and
suggested next investigations are in Fable #476.
Closes#399's drift-re-enable scope: 11/11 originally-scoped tests
(4 sync_controller + 5 audio_cache + 2 storage_section) pass on the
libsqlite3-bearing ci-flutter:3.44 image, plus 3/4 quarantine tests
and the widgets_smoke suite.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
like_button_test 'tap toggles icon optimistically; rollback on error':
Stale survivor of the pre-MutationQueue era. The test name claims
to verify rollback after error, but LikesController.toggle no
longer rolls back — it adopted the same offline-first pattern as
quarantine: optimistic drift write, on API failure enqueue a
mutation for replay, drift state stays (user's intent persists
offline). The test's `expect(heartFilled(), isTrue)` after the
failed unlike happens to align with current "don't rollback"
behavior by accident; the test's intent is stale. The genuine
offline-first property is exercised by the quarantine test.
Delete rather than rewrite — no unique coverage to preserve.
quarantine connectivity override:
Previous Stream.value(true) override emitted true and then closed
the stream immediately. Riverpod's StreamProvider transitions
loading → data → closed when the underlying stream completes,
and that "closed" transition during the AsyncNotifier + mutation
replayer's overlapping lifecycle was tripping "disposed during
loading" on the throwing-API variant. Replace with an async*
generator that yields true and then holds open via
`Completer<void>().future` until tearDown disposes the container.
Same .future semantics for consumers; the provider stays in
AsyncData(true) throughout the test instead of transitioning to
closed mid-flight.
Closes the last 2 of the 6 drift-cohort surfaced failures. Fable #399.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Last 2 of the 6 surfaced drift-cohort failures. Diagnoses below.
quarantine_provider_test 'flag keeps drift optimistic + queues
mutation on server failure':
MyQuarantineController.build() schedules unawaited _refreshFromServer()
which reads connectivityProvider (a StreamProvider<bool>). In tests
without an override, that stream never emits — its real impl listens
to connectivity_plus's platform channel which has no fixture in
flutter test. The success-path quarantine tests resolve their main
flow before _refreshFromServer's chain reaches the connectivity read,
so they don't trip the "disposed during loading" guard at tearDown.
The throwing-API variant's `await ref.read(mutationQueueProvider)
.enqueue(...)` advances enough async work that the connectivity read
IS reached, then container.dispose() trips Riverpod's invariant.
Fix: override connectivityProvider in the shared _container helper
with `Stream.value(true)` so it resolves immediately. The previous
`await Future.delayed(Duration.zero)` workaround is removed — the
cleaner fix makes that band-aid unnecessary.
like_button_test 'tap toggles icon optimistically; rollback on error':
LikesController.toggle:
final user = _ref.read(authControllerProvider).value;
if (user == null) return;
The test only overrode `likesApiProvider`; authControllerProvider was
in AsyncLoading state at toggle() time → user was null → early return
→ no drift write → likedIdsProvider never emits "liked" → heart never
fills → assertion fails. The test would never have passed against the
current controller; it was a stale survivor of an older API.
Fix: stub authControllerProvider with _FakeAuthController that yields
User(id: 'u1', …) immediately. Also add overrides for appDbProvider
(NativeDatabase.memory, bypasses drift_flutter's Timer) and
connectivityProvider (Stream.value(true), unblocks cacheFirst's
isOnline check) — both are transitive dependencies of
likedIdsProvider's cacheFirst.
After this push, the full drift cohort should be all-green. Fable #399
/ local #62 closes when CI lands.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
All six tests had been silently skipped under @Tags(['drift']) for
6+ months, so they accumulated test-vs-implementation drift. Now
running against the libsqlite3-bearing ci-flutter:3.44 image, each
failed for a distinct reason. Diagnoses below.
audio_cache_manager_test 'usageBytes sums sizeBytes across rows':
usageBytes() is a directory walk (authoritative on-disk total,
catches orphan partials the index misses). The test inserted drift
rows but never wrote files, so the walk returned 0. The actual API
for summing drift sizeBytes is bucketUsage(). Rename to
'bucketUsage sums drift sizeBytes across rows', use that API,
assert liked+rolling == 350. Also give the two rows unique paths
per row-shape sanity.
sync_controller_test (3 200-path tests, all returning null result):
Map literals in Dart 3 with mixed value types infer as
Map<String, Object>, not Map<String, dynamic>. The sync controller
casts `resp.data as Map<String, dynamic>` (and several nested
casts), which is invariant on generics and throws TypeError. The
silent try/catch in sync() swallowed the throw and returned null.
Real JSON parsing produces Map<String, dynamic>, so this never
surfaced in production. Fix: route the test stub body through
jsonDecode(jsonEncode(body)) in _stubDio — mimics real Dio's
parsed-response shape. Affects '200 with artist upsert', '200 with
track delete', and 'like_track upsert + delete round-trip'.
quarantine_provider_test 'flag keeps drift optimistic + queues
mutation on server failure':
When the API stub throws, the controller catches + queues to
CachedMutations. The drift watch() stream in MyQuarantineController
was still in loading state when addTearDown disposed the
container, tripping Riverpod's "StreamProvider disposed during
loading" assertion. The success-path tests resolved before
tearDown so they didn't see it. Fix: await one microtask before
the test ends so the stream emits.
like_button_test 'tap toggles icon optimistically; rollback on error':
After the LikeButton was migrated to LucideHeart in the Lucide
sweep, the prior fix replaced the find.byIcon assertion with a
heartFilled() helper reading LucideHeart.filled. But likesController
.toggle() goes through an async chain (optimistic state flip + await
api.like + state notification), which one frame of tester.pump()
doesn't flush. Use pumpAndSettle after both tap and rollback toggle
so the widget rebuilds with the new state before the assertion.
After this push, the drift cohort should be all-green on the
libsqlite3-bearing image. Fable #399 / local #62.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both fixes paired with the ci-flutter:3.44 rebuild that adds
libsqlite3-dev to the runner image (CI-runner push #2: libsqlite3-0
→ -dev because dart:ffi opens the unversioned .so symlink that only
the dev package ships).
widgets_smoke_test (TrackRow):
TrackRow contains CachedIndicator which reaches
audioCacheManagerProvider → appDbProvider → drift_flutter's
`driftDatabase()`. That schedules a deferred-init Timer that
outlives the test widget tree and trips the
"A Timer is still pending after dispose" invariant. Override
appDbProvider in the test to use AppDb(NativeDatabase.memory())
directly — bypasses drift_flutter's Timer-using init path, still
exercises real SQLite via FFI.
like_button_test (tap toggles + rollback):
LikeButton was migrated to LucideHeart (SVG widget with `filled`
bool) in the Lucide sweep; the test's `find.byIcon(Icons.favorite)`
is stale. Replace with a small heartFilled() helper that reads
the LucideHeart's `filled` prop straight off the widget tree.
Same assertion semantics, just against the post-migration shape.
The four sync_controller failures need no code change — they're
the same root cause as the drift-tagged cohort (libsqlite3.so
missing → try/catch returns null → `result?.upserts` is null
instead of the expected 0). The image fix should clear them.
Fable #399 / local #62.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drops the libsqlite3-missing skip cohort now that the ci-flutter
runner image installs libsqlite3-0 (CI-runner commit on its main).
Per-file removals (no behavior change in tests themselves — they
just stop being skipped):
- `@Tags(['drift'])` + `library;` directive from 5 files.
- `const _skipDrift = ...;` declaration + its rationale comment
from 6 files (the 5 above + like_button_test.dart, which had its
own _skipDrift for the rollback-via-drift case).
- `skip: _skipDrift` annotations from 17 test invocations across
those 6 files (16 single-line + 1 multi-line in like_button).
- Stale `@Tags(['drift']) tier covers it` reference in
home_screen_test.dart's drift-coverage comment.
Net -79 +18 lines across 7 files; 17 previously-silent tests are
now part of the CI signal. Fable #399.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
staticcheck S1016 in the new golangci-lint v2 flagged four sites
copying field-by-field between two types with identical struct
shapes. Direct type conversion is the canonical form:
- internal/library/scanrun.go:
- LibraryStageTallies copy from Stats → LibraryStageTallies(lastStats)
- MBIDBackfillStageTallies copy from BackfillMBIDsResult →
MBIDBackfillStageTallies(lastRes)
- internal/recommendation/home.go:
- dbq.ListRediscoverAlbumsForUserRow copy from the Fallback row
type → dbq.ListRediscoverAlbumsForUserRow(r)
- Same pattern for the Artists rediscover pair.
No behavior change; the underlying struct shapes are identical
(staticcheck verified the conversion is valid). Net -18 +4 lines.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The lint config change in 70529de (v2 schema migration) didn't
re-run Go CI because .golangci.yml wasn't in test-go.yml's paths
filter — the lint config was on dev but Go CI was still pinned to
the previous failure. Adding it to both the push and pull_request
filters so future lint-only edits retrigger the workflow.
Side effect: this commit itself retriggers test-go.yml (the
workflow file changed), so Go CI gets the v2 lint config now.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two fixes for CI bounces caused by the new ci-go:1.26 / ci-flutter:3.44
toolchain images surfacing stricter checks than the previous runners.
1. .golangci.yml: migrate to v2 schema
- Add `version: "2"` (now required).
- `linters.disable-all: true` → `linters.default: none`.
- Move `gofmt` + `goimports` out of `linters` into the new
top-level `formatters:` block (v2 separates linters and
formatters).
- Nest `linters-settings:` under `linters.settings:`.
- Drop the v1-only `issues.exclude-use-default: false`
(v2 default exclusion behavior is what we want).
2. Flutter 3.44 made ListTile-inside-ColoredBox a hard assertion
(was a warning before). Both bottom sheets in track_actions/
set Container.color on the outer surface, which inserts a
ColoredBox above their ListTiles. Wrap each ListTile in
`Material(type: MaterialType.transparency)` so it has an ink
target beneath the outer color paint without changing the
visual surface:
- track_actions_sheet.dart `_MenuItem.build`
- add_to_playlist_sheet.dart inner ListTile
5 failing widget tests should pass with this change. Local task #70.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adopts the FabledRulebook ci-runners.md policy: workflows select
toolchains via container.image, not via runs-on labels. `runs-on`
stays as the scheduling handle only.
Workflows updated:
- test-go.yml: ci-go:1.26 on both `test` and `integration` jobs.
- test-web.yml: ci-go:1.26 (bundles Node + npm); the
actions/setup-node@v4 step is removed.
- flutter.yml: ci-flutter:3.44 (Flutter 3.44 + Android + Java 25).
- release.yml: ci-go:1.26 (ships docker CLI + buildx).
Side effect: this unblocks the Go server deps bump (commit 6a62120)
which auto-bumped go.mod to `go 1.25.0` via x/crypto v0.51.0's
minimum — ci-go:1.26 satisfies it with headroom.
Adds ci-requirements.md at repo root per the ci-runners.md
"every project ships a requirements sheet" rule. Documents:
runtime images consumed, image deps used per workflow, per-job
installs (none), and a Notes section covering the integration
docker-socket dependency, the toolchain pin rationale, and the
in-app-update channel polling.
Tracked in local task #70.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Direct bumps:
- golang.org/x/crypto v0.35.0 → v0.51.0 (security backports;
single highest-priority bump in the audit)
- github.com/jackc/pgx/v5 v5.7.4 → v5.9.2
- github.com/golang-migrate/migrate/v4 v4.18.2 → v4.19.1
- github.com/jackc/pgerrcode 2022-04-16 → 2025-09-07 (untagged
pseudo refresh)
Side effects (good):
- `go mod tidy` dropped three transitives that migrate v4.18
pulled in but v4.19 no longer needs: hashicorp/errwrap,
hashicorp/go-multierror, go.uber.org/atomic.
Toolchain note:
- `go.mod` `go` directive auto-bumped 1.23.0 → 1.25.0 because
x/crypto v0.51.0 declares Go 1.25 as its minimum. If the
go-ci runner image isn't on Go 1.25+, CI will bounce on
this; the runner image bump is operator infra (memory:
project_forgejo_ci.md). Tracked in Fable #464.
Reference: Fable #464 + audit note #460.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both verified unused at the source/config level (Fable #461 +
audit note #460):
- cupertino_icons: zero `CupertinoIcons` / cupertino imports in
flutter_client/lib/. Pure `flutter create` template residue;
the design system mandates Lucide.
- tslib: web/tsconfig.json does not set `importHelpers: true`,
so TypeScript inlines helpers per-file. Declared peer with no
runtime consumer.
`npm uninstall tslib --save-dev` updated package-lock.json
surgically (8 lines removed for the tslib entry only). No other
deps disturbed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Root cause: discover.test.ts and requests.test.ts were the only route
page tests NOT mocking $app/state (+ $app/navigation), so rendering
the +page.svelte pulled in SvelteKit's client runtime and threw
`TypeError: notifiable_store is not a function` at module load. They'd
been describe.skip'd AND hard-excluded in vitest.config.ts.
Fix mirrors every other route test: vi.hoisted pageState +
vi.mock('$app/state', () => pageUrlModule(state)) +
vi.mock('$app/navigation', () => ({ goto: vi.fn() })). Un-skip both
describe blocks; drop the vitest.config exclude. The web test job
now runs both suites again.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reported: on poor coverage a track ends and the next (uncached) track
never starts — streams, hangs, no retry. Root cause: a buffering stall
emits NO error event so the onError path never fires and there was no
stall watchdog; even on a real error _handlePlaybackError immediately
skipped the literal-next (likely also-unreachable) source with no retry.
- _reconcileStallWatchdog: while playing+buffering, a 15s window; if
buffered position hasn't advanced it's a dead stream → recover; if
progressing, re-arm (slow-but-downloading is fine). Driven from
_broadcastState like the idle/position reconcilers.
- _recoverPlayback unifies stall + onError: retry the SAME track once
(skipToQueueItem rebuilds a fresh source/HTTP — a transient blip no
longer loses it); on exhaustion, surface via the #58 SnackBar and
skip to the next cached track, else pause (no thrashing through
unreachable streams).
- per-track retry budget resets when a track reaches ready+playing.
- _handlePlaybackError now delegates into the unified path.
Core playback change — device-verify on a throttled connection.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The home screen renders solely from the per-item cached_home_index
path (proven on devices for many releases); the legacy snapshot stack
was dead weight.
- library_providers: remove homeProvider + _encodeHomeData +
_albumToJson/_artistToJson/_trackToJson; drop now-unused dart:convert
and models/home_data.dart imports
- metadata_prefetcher: re-point off homeIndexProvider/HomeIndex —
pre-warm artistProvider from the rediscover/last-played artist
sections (album/track tiles hydrate their own artist on render)
- live_events_dispatcher: homeProvider -> homeIndexProvider so live
events still refresh the home screen
- db.dart: drop CachedHomeSnapshot (table class + @DriftDatabase
entry); schemaVersion 10->11; from<3 createTable -> raw
customStatement so the historical step compiles without the
generated symbol; from<11 DROP TABLE cached_home_snapshot
No test references the removed symbols. db.g.dart regenerated by CI.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Device logcat (Pixel 6 Pro / Android 16) showed audio_service throwing
on every state broadcast:
java.lang.IllegalArgumentException: You must specify an icon resource
id to build a CustomAction
at com.ryanheise.audioservice.AudioService...
The #57 MediaControl.custom favorite makes audio_service build a
PlaybackStateCompat.CustomAction whose icon id resolves to 0 on real
builds; the exception aborts the ENTIRE media notification, so nothing
posts to the tray or the watch (emulator tolerated it). Not a
permission / PathParser / FGS issue — POST_NOTIFICATIONS was verified
granted. Pre-#57 there was no CustomAction, matching the regression.
Remove the custom favorite control; the notification is rebuilt with
only the standard transport controls (audio_service ships their icons).
customAction handler / refreshFavoriteControl left as harmless no-ops
to minimise churn. Like/favorite remains in-app + lock screen.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Device-surfaced on physical Android 13+ (worked on emulator):
A) The media notification never appeared because the app never
requested POST_NOTIFICATIONS at runtime — the manifest declares it
and the foreground service is correct, but Android 13+ denies it by
default until asked. Add permission_handler ^12.0.1 and request
Permission.notification once at startup (post-first-frame,
Platform.isAndroid-guarded; no-op on <13 / once decided).
B) When the #52 idle/dismiss teardown nulled mediaItem while the full
NowPlayingScreen was open, it stranded the user on an empty
"Nothing playing." Scaffold. Now post-frame maybePop() so it
auto-minimizes (the mini bar is already gone).
pubspec.lock + db.g.dart regenerated by CI/build.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`--filter name=integration` matched EVERY concurrent integration run's
Postgres service container. A dev push and the main-merge run overlap
on the shared act_runner daemon → 2 candidates → the "expected exactly
1" guard aborts (false failure; not a code defect).
Discover instead by intersecting networks: act_runner attaches the job
container and its service container to a shared per-job network, so
select the postgres that sits on a network this job container is also
on. The dev-compose container is skipped explicitly as before.
CI-only change; the released v2026.05.19.0 code is unaffected (a clean
re-run of the failed job passes — the failure was a concurrency race).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fast-follow of #54. After the #52 idle/dismiss teardown, pressing play
on a headset / watch / lock screen did nothing (handler.play() was just
_player.play() with nothing loaded; the handler is Riverpod-agnostic).
- audio_handler: _resumeHook + setResumeHook(); play() is now async —
when mediaItem == null and a hook is set it awaits the hook (which
restores + plays) and returns, else _player.play()
- resume_controller: extract shared _loadAndRestore() (bool); _restore()
keeps the paused launch path; new resumeFromMediaButton() restores
then starts playback; start() registers it via setResumeHook
Recursion-safe (post-restore mediaItem != null so the re-play hits
_player.play()); no-op when nothing to resume / auth missing / a
session is already active.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
#60 swapped Icons.more_vert -> LucideIcons.ellipsis_vertical in
playlist_card.dart; the widget test still asserted the old Material
icon (find.byIcon(Icons.more_vert)) and failed. Update both finders
+ import flutter_lucide.
Note: like_button_test.dart still references Icons.favorite but is
skip:true (gated on Fable #399) so it compiles and doesn't run;
flagged as stale to update when that test is unskipped.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mechanical sweep across 30 files: every Material Icons.* replaced with
the signed-off Lucide equivalent + a flutter_lucide import per file.
Zero Material Icons.* remain in lib/; no unused imports.
Judgment-call mappings: album->disc_3, library_music->library_big,
playlist_play->list_video, graphic_eq->audio_lines,
system_update->download, restore->archive_restore,
download_done->circle_check_big.
track_actions_sheet like menu row: collapsed `liked ? favorite :
favorite_border` to a single LucideIcons.heart (the row's Like/Unlike
text label conveys state). Icon-only LikeButton + the notification keep
the filled-vs-outline shape per the design decision.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Design system mandates Lucide, not Material. Foundation before the
mechanical Icons.* sweep:
- pubspec: add flutter_lucide ^1.11.0
- shared/widgets/lucide_heart.dart: LucideHeart renders the verified
lucide-icons/lucide heart path as outline (stroke) or filled, via
flutter_svg, tinted by color — Lucide ships no filled heart, so the
liked state fills the same Lucide silhouette (user-chosen approach)
- like_button: use LucideHeart instead of Icons.favorite/_border
- notification drawables re-derived from the verbatim Lucide heart
path (border = stroke, filled = fill); separators spaced for
Android pathData
Unit 2 (mechanical Icons.* -> LucideIcons.* sweep) follows once this
is CI-green. pubspec.lock regenerated by CI.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
_handlePlaybackError silently skipped a dead track (404 / decoder /
EOS / network drop) with only a debugPrint, hiding the signal that
tells a broken track from a flaky app.
- audio_handler: _playbackErrors broadcast stream; emit the failing
track title (mediaItem.value?.title — correctly mapped post-#49)
before the skip/pause
- playback_error_reporter (new): global scaffoldMessengerKey +
reporter that buffers, 2s-debounces, and coalesces bursts into one
SnackBar ("Couldn't play X — skipping" / "Skipped N unplayable
tracks")
- app.dart: scaffoldMessengerKey on MaterialApp.router + postFrame read
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`Future<dynamic>` in the customAction doc comment tripped
unintended_html_in_doc_comment (bare angle brackets read as HTML).
Wrap the code identifiers in backticks.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a heart action to the media notification implemented as a custom
control + customAction handler — NOT setRating, which is broken
upstream (audio_service #376: onSetRating never fires from a
notification tap) and previously blanked the Pixel Watch.
- res/drawable/ic_stat_favorite{,_border}.xml: white 24dp vector hearts
- audio_handler: favorite MediaControl.custom in _broadcastState
(icon/label toggle by LikeBridge state; kept out of
androidCompactActionIndices so compact/lock + Wear transport are
unchanged); customAction override (Future<dynamic>, matches base)
toggles the like then re-broadcasts; refreshFavoriteControl()
- player_provider: cascade refreshFavoriteControl into the likedIds
listener so liking from TrackRow/kebab/SSE flips the notification heart
Reliable on phone notification + lock screen; Wear/Auto display of a
non-transport custom action is platform-dependent (not a bug).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AudioServiceConfig handed full-res album art to the notification /
lock screen / Wear. Add artDownscaleWidth/Height: 300 + preloadArtwork
so external surfaces get a smaller, faster, lower-memory cover with a
warm first paint.
6b (notification tap-to-open) dropped: androidNotificationClickStarts
Activity already defaults to true, so the tap foregrounds the app;
deep-linking to now-playing isn't a config knob and was judged
disproportionate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
_broadcastState only set updatePosition on transitions, so the lock-
screen / Wear / Android Auto scrubber jumped in chunks (the in-app bar
uses positionStream and was fine). Add _positionBroadcastTimer: a 1s
periodic PlaybackState re-broadcast while actively playing so
updateTime/updatePosition stay fresh and external surfaces interpolate
smoothly. Idempotent (driven from _broadcastState, which the tick
itself calls — guarded against pile-up), cancelled when not playing
and in stop(). 6a: the notification progress bar now advances since
MediaItem.duration was already set.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The #52 teardown clears the session when idle/dismissed, so the
headset / lock-screen play button had nothing to resume and the user
lost their place.
- track.dart: toJson() (round-trips fromJson)
- db.dart: CachedResumeState single-row snapshot, schema 9->10 + migration
- audio_handler.dart: queuedTracks getter
- player_provider.dart: restoreQueue() — configure + setQueueFromTracks
+ seek, no play (restores PAUSED)
- resume_controller.dart: restores last snapshot paused on launch;
persists {source,index,position_ms,tracks} debounced on track
change / pause and immediately on app teardown; never clobbers the
saved snapshot when the queue is empty so a teardown stays
recoverable; restore gated on auth + no active session
- app.dart: wired into postFrame
db.g.dart regenerated by CI per project convention. Deferred fast-follow:
media-button-when-fully-stopped re-init (needs a configure()-injected
callback; tracked on #54).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AudioSessionConfiguration.music() is a const constructor; the earlier
pre-emptive drop of `const` tripped prefer_const_constructors under
flutter analyze --fatal-infos.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Flutter client had no audio_session integration, so it didn't pause
for phone calls / other media, didn't duck for navigation prompts, and
kept blasting the phone speaker when earbuds were unplugged.
Add audio_session ^0.2.3 and configure AudioSessionConfiguration.music()
in MinstrelAudioHandler (best-effort, fully try-caught):
- becomingNoisy -> pause (no speaker blast on unplug/BT drop)
- interruption begin: duck -> lower volume; pause/unknown -> pause,
remembering whether we were actively playing
- interruption end: duck -> restore volume; pause -> resume only if we
paused it and the session isn't torn down (guards the idle-teardown
-during-long-call edge; re-init is resume-last-session territory);
unknown -> no auto-resume
pubspec.lock regenerated by build/CI.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Nothing drove the audio_service session to a terminal state and the
notification is configured ongoing, so the Wear tile / lock screen /
notification lingered on a stale paused track indefinitely.
- stop() override: pause, broadcast idle, clear queue/mediaItem, then
super.stop() so the foreground service + notification (and watch tile)
tear down; in-app mini bar collapses in lockstep.
- onTaskRemoved(): keep playing if audio is active (standard media
behaviour), otherwise stop so a dismissed-while-paused app doesn't
leave a stale tile.
- 5-minute idle timer armed while paused or on a finished queue,
cancelled on resume / new queue, re-checked at fire time.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
player: setQueueFromTracks fast-starts a single source at player-index 0
while the full queue is broadcast, so the transient currentIndexStream→0
emission clobbered the correct mediaItem with queue.value[0] (the first
track). Mini bar / playlist marker pinned to the wrong track until a
later index event (~the "passive ~30s recovery"). Track a logical-index
base so the player→queue mapping stays correct during the fill window;
also fixes the latent forward-fill auto-advance off-by-base.
lidarr #50: approving no longer fails when Lidarr is down. Approve
records the decision durably first, then best-effort adds; the
reconciler idempotently (re)sends unconfirmed adds every tick until they
stick (new additive lidarr_add_confirmed_at; AddArtist/AddAlbum map
Lidarr's "already exists" 400 → ErrAlreadyExists). No failed-state or
expiry by design — Lidarr keeps trying, operator monitors.
lidarr #51: Create() is now idempotent — a non-terminal request for the
same MBID returns the existing row instead of inserting a duplicate.
Rewrites the obsolete LidarrUnreachable_503 test to assert the durable-
approve contract; threads a client factory into NewReconciler.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Operator decision: the enricher is canonical. No MBID still runs the
provider chain (name-based providers — Deezer/Last.fm — resolve
without an MBID); if every provider returns ErrNotFound the row
settles cover/artist source 'none' at the current sources version
(re-eligible only when the registered provider set changes). It does
NOT skip-and-leave-NULL.
The two _NoMBID_LeavesNull tests predated the name-based providers
(0020 slice) and asserted the old skip→NULL contract. Updated:
- TestEnrichArtist_NoMBID_SettlesNone: stub now returns ErrNotFound
(realistic MBID-only-provider-with-empty-MBID), expect source 'none'.
- TestEnrichAlbum_NoSidecarNoMBID_SettlesNone: empty registry →
allWere404 stays true → expect 'none'.
Last failing cluster from the CI-integration initiative; suite should
now be fully green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The test marked id2 'none' via SetAlbumCover, which (covers.sql:42)
does NOT set cover_art_sources_version. ListAlbumsMissingCover treats
'none' AND version != current as eligible, so id2 (version 0, current
1) was wrongly drained → processed=2. The comment's intent ("'none'
with current version → not drained") requires SetAlbumCoverWithVersion
(albums.sql) stamped with the live GetCurrentSourcesVersion — the same
value EnrichBatch compares against. Test-only.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two distinct pre-existing test bugs in the last failing cluster:
1. newTestEnricher() called resetRegistryForTests() itself, wiping the
fake providers callers Register() right before calling it (its own
doc says callers register first and reconcile() picks them up). The
~8 TestEnrichArtist_* failures (source stayed NULL, no thumb
written) all stem from reconcile() seeing an empty registry. Remove
the internal reset; make every caller that lacked one own the
registry lifecycle explicitly (resetRegistryForTests + t.Cleanup):
SidecarFound, NoSidecarNoMBID, AlreadySidecar_NoOp,
DrainsNullSourceOnly.
2. apiTestAlbumProvider.FetchAlbumCover had a stale signature
(context, string) predating the AlbumRef refactor; it no longer
satisfied coverart.AlbumCoverProvider, so the p.(AlbumCoverProvider)
capability assertion failed and TestAdminListCoverSources got
supports=[]. Fix the param to coverart.AlbumRef.
Test-only. (A1/A2 were correct; they unmasked these. Any residual
album-enricher semantics failures will be root-caused from the next
clean run, not bundled speculatively.)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Flutter Discover screen was Lidarr-search-only; its empty state
showed a "Type to search" placeholder while web's /discover renders
the LB-derived out-of-library artist SuggestionFeed as its default
surface. Parity gap that slipped #356.
- ArtistSuggestion/SeedContribution model mirroring web types, with
attributionText() matching web's "Because you liked/played X[, Y, and
Z]." (Oxford comma, max 3).
- DiscoverApi.listSuggestions() → GET /api/discover/suggestions
(image_url already resolved server-side from Lidarr, a7bea43).
- discover_screen: empty search box → suggestions feed (artist art +
name + attribution + Request, reusing the existing createRequest +
mutation-queue-replay flow with optimistic hide); typing → Lidarr
search replaces; clearing → suggestions return. Mirrors web exactly.
Flutter-only; server endpoint unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A2 — migration 0030: the albums/artists art `*_source` CHECK was a
fixed provider-ID allowlist fighting the extensible coverart.Register
registry (per-provider migration churn at 0016/0018/0020; rejected
test stub providers → ~11 enricher tests failed). Relax to "NULL or
non-empty"; the registry is the source of truth. Same brittleness
class as the #433 discovery-mix CHECK.
D — lidarr Approve resolves metadata/quality profiles (JSON arrays)
before the add; the test stubs returned {"id":1} for every path, so
ListMetadataProfiles failed to unmarshal → 500/Approve errors. Make
the lidarrrequests + admin_requests stubs path-aware (arrays for
/metadataprofile, /qualityprofile).
E:
- auth: requireUser (prelude.go) emitted code "auth_required"; the
canonical code is "unauthenticated" (operator decision). Change the
code; drop the now-dead "auth_required" web error-copy key
("unauthenticated" already has copy).
- playlists_system_test wrapped the real auth.RequireUser middleware
but only injected withUser() context → 401. Like every other api
handler test, drop the middleware and rely on requireUser().
- admin_users dup-username test seeded "test-existing" (seedUser
prefixes) but POSTed "existing" → no collision; POST the prefixed
name.
- me_timezone test decoded a top-level {"code"} but the envelope is
{"error":{"code"}}; decode the nested shape.
- audit test asserted compact JSON; Postgres jsonb::text is spaced.
- put-lidarr-config tests predated the missing_defaults gate (correct
handler behavior); supply the required defaults in the bodies.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A redo: the prior commit truncated cover_art_sources_meta, but
SettingsService.reconcile() only READS that singleton (seeded once by
migration 0018) and never recreates it → ~45 coverart/api tests hard-
failed "get current sources version: no rows". Correct reset: keep
cover_art_provider_settings in the truncate set (boot idempotently
re-UpsertProviderSettings), drop cover_art_sources_meta from it, and
instead `UPDATE cover_art_sources_meta SET current_version = 1` so the
row survives while cross-test version accumulation is cleared.
B residual (exposed once the play_events FK fix let these run):
- seedQuarantine used reason 'test-hide', invalid for the
lidarr_quarantine_reason enum (bad_rip/wrong_file/wrong_tags/
duplicate/other) → use 'other'.
- TestBuildSystemPlaylists_SufficientActivity predated #411/#352: the
variant switch errored on the 5 new seedless mixes and capped
track_count at 25. Accept deep_cuts/rediscover/new_for_you/
on_this_day/first_listens as seedless; raise the cap to 100.
Test/test-harness only.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Latent failures exposed now that integration tests run in CI (#339).
All test/test-harness only — no production code changes.
A (dbtest.ResetDB): also truncate cover_art_provider_settings +
cover_art_sources_meta. The monotonic source-version counter (seeded 1
by 0018) accumulated across internal/coverart tests → CurrentVersion=4
want 1, key-only-bump assertions, enricher source skips. SettingsService
re-seeds both at boot, so a truncated start is the correct fresh state.
B (playlists system_test.seedPlayEvent): inserted play_events with a
random session_id → play_events_session_id_fkey violation (7 tests).
Create the parent play_sessions row in the same statement (CTE).
C (similarity worker_integration_test.newTestWorker): built the client
with only BaseURL. Post-4fca0e6 similarity hits the Labs API via
LabsBaseURL, so an unset LabsBaseURL fell through to the real labs.api
and the stub never ran → 0 similarity rows. Set LabsBaseURL to the stub.
F (library scanner_test): NOT a flake — deterministic. Synthetic
ID3-only MP3s have no decodable duration; the scanner intentionally
won't skip duration_ms=0 rows (retries duration backfill), so every
re-scan reported Updated not Skipped. Seed duration_ms>0 before the
second scan so the mtime-based incremental-skip path under test is
actually exercised. Production scanner behavior unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First CI integration run proved the act_runner pattern works (service
discovery, migrate, exactly-one guard all functioned) but ~150 tests
failed with `dbtest.ResetDB truncate: deadlock detected (40P01)` plus
cascading FK/dup-key symptoms. Root cause: `go test ./...` runs package
binaries concurrently (default -p = NumCPU); every integration package
TRUNCATEs the single shared minstrel_test DB, so concurrent truncates
deadlock and half-seeded fixtures violate FKs. The documented local
invocation is `go test -p 1 ./...` for exactly this reason. Serialize
package execution in both the CI step and `make test-integration`.
Genuine (non-concurrency) failures will remain after this — never caught
before because integration tests never ran in CI. Triaged next.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
#321 — `minstrel admin reset-password [-user admin] [-password X]`:
loads config, updates BOTH password_hash (bcrypt) and subsonic_password
(plaintext, for Subsonic t+s) so neither auth path is left stale;
generates+prints a strong password when -password is omitted. Recovers
a locked-out operator without DB surgery. Subcommand dispatch added to
main.go (os.Args switch before flag-parse; server path untouched) plus
a `minstrel migrate` subcommand exposing db.Migrate standalone.
#339 — integration tests no longer truncate the dev DB:
- deploy/initdb creates minstrel_test on a fresh compose volume;
`make test-integration` ensures it idempotently and points
MINSTREL_TEST_DATABASE_URL at minstrel_test.
- docker-compose.yml + README updated.
CI integration job (test-go.yml): the prior workflow only ran
`go test -short -race` with no DB, so the entire integration suite
silently t.Skip'd — "CI green" never covered API/db/scanner. New
`integration` job runs the full `go test -race` against an ephemeral
Postgres service, using the act_runner shared-daemon pattern: no
published ports, discover the service container by job-name filter via
the docker socket, reach it by bridge IP, hard exactly-one assertion +
dev-compose-name reject (a wrong target would truncate real data),
TCP-wait, `minstrel migrate`, then test. Fast `test` job kept as the
quick gate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Out-of-library suggestion artists (artist_similarity_unmatched rows)
have no local art row, so the Discover card always showed a
placeholder. Resolve art on-demand from Lidarr's artist lookup,
matched by MBID (foreignArtistId == candidate_mbid), and pass the
remote image URL straight through — no caching (a suggestion may
never be viewed; the browser fetches the URL directly).
- suggestionView gains image_url (omitempty); handler resolves it via
bounded-concurrency Lidarr LookupArtist, best-effort, never fails
the request.
- Lidarr is the sole source: disabled / unreachable / no-match →
empty → existing placeholder. (No inline TheAudioDB fallback — it's
externally rate-limited and there's no cache to amortize it.)
- web: ArtistSuggestion.image_url?; SuggestionFeed passes it to
DiscoverResultCard (already supports imageUrl).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follows 005965d (#388), which removed the coverArtBackfillCap param
from server.New. server_test.go is in package server so it calls New()
unqualified — missed by the signature-caller grep. Updated all 6
positional calls.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
Root cause of zero LB recommendations (every similar-recordings AND
similar-artists call returned HTTP 404, worker logs):
- Wrong host/path: client called
api.listenbrainz.org/1/explore/similar-{recordings,artists}/{mbid}.
/explore/... is a WEBSITE route, not an API endpoint — it 308s then
404s. Similarity datasets live on the separate Labs API.
- Invalid algorithm: the hardcoded
session_…_session_30_…_limit_100_filter_True_… is not a permitted
Labs enum member (400s) regardless of host.
Verified against the live Labs API:
GET labs.api.listenbrainz.org/similar-recordings/json
?recording_mbids=<mbid>&algorithm=<algo>
GET labs.api.listenbrainz.org/similar-artists/json
?artist_mbids=<mbid>&algorithm=<algo>
algorithm=session_based_days_9000_session_300_contribution_5_threshold_15_limit_50_skip_30
→ 200 for both. Response field names (recording_mbid/artist_mbid/
name/score) already match the existing structs — parsing unchanged.
- Add defaultLabsBaseURL + Client.LabsBaseURL (separate from the main
BaseURL; scrobble submission still uses api.listenbrainz.org).
- Drop the count/limit query param — result size is encoded in the
algorithm name (limit_50); caller still applies its own top-K.
- Tests: newTestClient sets LabsBaseURL; the two *_LimitParamSet tests
become *_MbidParamSet (assert the Labs path + mbid query param).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follows ca1bc5a, which raised the worker batch default. The defaults
test pinned the old value; align it with the intended new default.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- similarity.Worker batch 5→25 (tracks AND artists per 1h tick). At
5/h a freshly-scrobbled library took days to build a usable
similarity pool; 25/h converges in hours, still well under
ListenBrainz rate limits (429 aborts the tick).
- scanrun Stage 2b track backfill now runs unbounded (-1) instead of
reusing the album backfill's 5000 staged cap. It's a one-time
whole-library heal with no progress UI; a cap just left tracks.mbid
partially NULL (3634/18056 after one pass) until several future
scans caught up, re-reading untagged files each time. One uncapped
pass converges; later scans only re-read the remaining NULL rows.
Album backfill keeps its 5000 cap (it has staged scan_runs UX).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tracks.mbid was 100% NULL: the scanner only extracted album + artist
MBIDs, never the recording MBID. The ListenBrainz similarity worker is
gated on tracks.mbid IS NOT NULL, so track_similarity could never
populate — starving For-You/radio's strongest candidate source
(lb_similar) on every library.
- mbids.go: add extractRecordingMBID (mbz.Recording / Picard
musicbrainz_recordingid). Separate fn so extractMBIDs' signature +
unit tests stay untouched.
- scanner.go: persist recording MBID via UpsertTrack (heals on the
file_path conflict, so re-scans backfill for free).
- BackfillTrackMBIDs: one-shot pass mirroring BackfillMBIDs, wired as
scan Stage 2b (idempotent via SetTrackMbidIfNull, gated by
BackfillCap, log-only progress).
- migration 0029: tracks_mbid_unique (0002, written when the column
was always NULL) wrongly assumes one MBID == one track. A recording
appears on multiple releases, so rows legitimately share a recording
MBID. Replace with a non-unique partial index. Zero-risk: column is
100% NULL at migration time.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
For-You silently vanished after ~7 days of not listening (seed query
required a non-skip play in the last 7 days) and capped at ~40 on
self-hosted libraries with no ListenBrainz similarity data.
- PickTopPlayedTracksForUser: tiered seed — last 30d top plays, else
all-time top plays, else liked tracks. For-You only disappears now
if the account has zero plays AND zero likes.
- produceForYou uses deeper candidate source limits (raised random/
tag/similar K) so it reaches ~100 even with empty lb_similar /
similar_artists; richer when LB enrichment is present.
- Rediscover: tiered — 6-month-dormant, else ≥5-play 30-day-dormant.
- On This Day: floor 60→30 days, window ±7→±10 doy; still skips
cleanly (no rows → no playlist) on insufficient history.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
HOTFIX for v2026.05.15.0. R3 added deep_cuts/rediscover/new_for_you/
on_this_day/first_listens producers + registry entries but not their
system_variant values to the playlists_kind_variant_consistent /
playlists_seed_consistent CHECK constraints (0021's whitelist).
insertSystemPlaylist for any new mix → SQLSTATE 23514, and since
BuildSystemPlaylists is one all-or-nothing txn that aborts the
ENTIRE build — For-You/Discover refresh 500s and the daily lazy
build fails too. System playlists are fully broken in prod.
Migration 0028 drops + re-adds both constraints with all five new
seedless variants (mirrors the 0021 drop-and-readd pattern).
CHECK-only — sqlc/dbq unaffected (regen produced no drift).
Bumps to 2026.5.15+7 for the v2026.05.15.1 patch release.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the last buildable item of the #411 system-playlists-v2
umbrella. System playlists atomic-replace on rebuild, so created_at
(already on the wire — no server change) is the last-rotated time.
Surface it as a small tile subtitle so users see how fresh a mix
is: "Refreshed just now / today / yesterday / N days ago / Mon D".
- web PlaylistCard: refreshedLabel() + a muted footer line, shown
only when system_variant != null. Unparseable/empty timestamp →
suppressed (web test fixtures use created_at:'' so no test churn).
- flutter PlaylistCard: mirrored _refreshedLabel() + subtitle under
the system badge for isSystem playlists.
Friendly wording deliberately distinct from HistoryRow's "m/h ago";
per-surface helper per the project's existing relative-time
convention. CI-pending; closes with the umbrella on device-check.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Operator's model: offline, surface the cache-backed pools right
where the (now play-disabled, S4a) system playlists sit, so Home
still has something to play.
- ShuffleSource gains recentlyPlayed() (cache by lastPlayedAt desc,
liked included) and liked() (cache ∩ liked set); shared _refs()
materializes ordered ids from cached_tracks/artists/albums.
Shuffle-all reuses the same recency walk.
- Home Playlists row: when offlineProvider is true, prepend two
tiles — "Recently played" / "Liked" — sized to PlaylistCard.
Tap → shuffle+play that pool from cache; empty → snackbar.
System tiles still render (play disabled per S4a) beside them.
- offline=false (online + all widget tests) → no extra tiles;
placeholder-count tests unaffected.
Closes the S4 thread of the #427 umbrella (S4a + S4b).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Query-builder methods come through the generated AppDb, not the
drift package directly — the import was dead. (#427 S4a)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Operator: Shuffle-all belongs in the Library view, not the Home
app bar. Moved the shuffle IconButton to LibraryScreen's app bar
(same behavior — online server-random / offline cache-union via
shuffleSourceProvider); reverted Home's app bar to the original
MainAppBarActions-only and dropped the now-unused imports.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
The debug APK step dominated the run (~7m32s of ~10m) and ran on
every dev push, but the operator dev-tests via a local Android
Studio build, not the CI artifact. Gate the debug APK + its
artifact upload to main pushes only: dev = analyze+test+codegen
(~3min); main = + debug APK as the native-build safety net
(Gradle/manifest/plugin breakage analyze+test can't catch) before
any release tag; tags = signed release APK (unchanged).
Note: the bulk of that 7m32s was the flutter-ci runner image
re-installing NDK 28.2.13676358 + build-tools 35 + platform 35/36
+ cmake 3.22.1 every run (image baked platform-34/build-tools-34,
stale vs the bundled Flutter's requirements). Baking those into
CI-Runner/CI-flutter/Dockerfile is the larger win and also speeds
release builds — tracked separately (operator-side infra, not in
this repo).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the single 5GB capBytes with independent Liked + Rolling
budgets (5GB each default). Bucket = liked-ness, NOT CacheSource:
a cached track currently in the liked set is charged to / evicted
under Liked; everything else is Rolling. Storage-only dedup — it
never filters playback (S4's offline lists query the whole index).
- db.dart: schema 8→9, AudioCacheIndex.lastPlayedAt (real play
recency for S4 + rolling LRU; migration backfills to cachedAt).
drift codegen run.
- cache_settings: likedCapBytes + rollingCapBytes (+ setters); old
cache_cap_bytes key dropped, defaults reapply (not data loss).
- audio_cache_manager: touch(); bucketUsage() counts orphan
partials (LockCaching files never indexed) as Rolling so the cap
truly bounds disk; evictBuckets() drains non-liked LRU then
sweeps orphans, Liked only by its own (large) cap — normal use
never evicts the user's liked library.
- prefetcher → evictBuckets with the cached liked set.
- storage_section: two cap selectors + per-bucket usage (folds in
S3 to avoid a broken intermediate).
- Explicit Download dropped: removed album + playlist Download
buttons, autoPlaylist pins, now-unused imports.
- Tests updated/compiled (drift-cohort tests are CI-skipped).
High blast radius (eviction deletes files) — liked-protective by
design; needs operator device-check before "done".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
offlineProvider: a Notifier<bool> driven by a periodic /healthz
probe. Offline after N=3 consecutive failed probes; recovers on
the first success. Slow heartbeat when online (30s), faster when
offline (10s) so recovery is noticed quickly. 5s initial delay for
provider warmup; optimistic (false) until proven otherwise.
Deliberately NOT coupled to connectivityProvider — subscribing to
that StreamProvider eagerly mounts its 2s timeout and leaks a
pending Timer through widget tests (the MutationReplayer bug).
/healthz failing already covers interface-down. No .timeout()
wrapper either (dio's own timeouts bound the probe) so the only
Timers are the tracked initial+periodic, both cancelled via
ref.onDispose — the proven smoke-safe shape.
Wired in app.dart postFrame to start the poller. No UI yet; S4
gates system-playlist play + Shuffle-all on it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Each is one candidate query + one registry entry; zero client work
(R2 made tiles/refresh/shuffle generic, all are singleton kinds so
web's server `refreshable` flag and Flutter's derived getter both
light up automatically).
- deep_cuts (#419): <=2-play tracks from liked / heavily-played
artists; diversity-capped.
- rediscover (#420): >=5-play tracks not heard in 6 months, by
historical affection.
- new_for_you (#421): tracks from albums added <=30d whose artist
the user likes/plays; album-coherent (no cap).
- on_this_day (#422): tracks played within ±7 day-of-year in prior
windows (>60d ago), weighted by play count.
- first_listens (#423): never-played albums, tiered liked-artist →
played-artist → rest; album-coherent.
system_mixes.go producers mirror the Discover model (SQL gives the
ranking; finishMix caps+truncates to 100 to match For-You/Discover
shuffle depth; album-coherent mixes skip the cap). Builder query
failure is non-fatal (logged, yields no playlist) like Discover.
Existing system_test existence checks are unaffected.
Closes the #411 system-playlists-v2 umbrella's new-types thread.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The commented Refreshable field broke gofmt's struct-tag column
alignment in playlistRowView. Pure formatting.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
go vet broke because playlists_{discover,foryou}_refresh_test.go
referenced the handlers/types deleted in R2 (d67c0de). Consolidated
into playlists_system_test.go covering the generic
/playlists/system/{kind}/{refresh} endpoint: for_you + discover
200/shape, non-singleton & unknown kind → 404, no-auth → 401.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
revive unused-parameter: produceDiscover keys off dateStr, not now,
but must keep the uniform systemPlaylistProducer signature. Blank
the unused param (param names don't affect func-type identity).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Behavior-preserving prep for the new mix types. Extracts the three
inline candidate computations in BuildSystemPlaylists into
producers (produceForYou / produceSeedMixes / produceDiscover) and
drives the build off a systemPlaylistRegistry. The shared
machinery (run-claim guard, atomic delete+insert tx, post-commit
collages) is now generic over a []builtPlaylist.
Fatal-vs-skip error semantics unchanged: a base query failure
(PickTopPlayedTracksForUser, PickSeedArtists) still aborts the
whole build; candidate-load / per-seed-artist / Discover-bucket
failures are still logged and just yield fewer playlists.
Materialize order (for_you, songs_like_artist, discover) is
unchanged and functionally irrelevant.
No API/client/schema change — CI's system/foryou/service tests
verify For You / Songs-like-X / Discover parity. Adding a new mix
is now: a producer + one registry entry + its candidate query.
Next (R2): generic /api/playlists/system/{kind}/{refresh,shuffle}
off the registry; then the new kinds.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Flutter half of offline-replay capture. Play events no longer
fire-and-forget: the reporter now tracks each play as a completed
unit (track, original start time, source, duration reached)
independently of connectivity.
- EventsApi.playOffline: single timestamp-preserving call → the new
/api/events play_offline (47aa178).
- MutationQueue: new play.offline kind + handler (EventsApi).
- PlayEventsReporter rework:
- _beginTrack captures start context + fires live play_started;
the server id is adopted only if it lands while still on-track.
- position progress gated on the tracked track id so a track
change can't clobber the finishing track's last values.
- _closeCurrent: if a server id registered, attempt the live
ended/skipped and fall back to the offline queue on failure; if
no id (offline start) enqueue the completed play directly. The
server applies the canonical skip rule, so the offline payload
only carries duration.
- app paused/detached closes durably via the queue (survives a
process kill; a teardown POST would not).
Result: listening to cached tracks fully offline now records
history / recs / scrobble / #415 rotation once back online, with
the original timestamps. Web stays best-effort by standing
occasional-use scope.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Server half of the offline-replay capture. New writer path
RecordOfflinePlay: writes a complete start+end play in one txn from
a caller-supplied `at` + duration_played_ms, applying the spec §6
skip rule (same AND-of-thresholds as RecordPlayEnded) and threading
`source` so #415 rotation advances for system-playlist plays just
like the live path. Generalizes RecordSyntheticCompletedPlay (which
hard-codes full completion). duration clamped to [0, track len].
New /api/events type "play_offline" → handleEventPlayOffline:
validates track + duration, reuses the existing req.At parse so the
play lands on the original timeline, not replay time. Subsonic
shim + live 3-call lifecycle untouched.
Flutter half next: EventsApi.playOffline, a play.offline
MutationQueue kind, and PlayEventsReporter capturing the completed
play + enqueuing it when the live calls have no server id / fail.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The events dispatcher closed every prior open row as play_skipped on
any track-id change. Server-side RecordPlaySkipped force-sets
was_skipped=true regardless of completion, so a queue played start
to finish reported tracks 1..N-1 as skips — inflating
recommendation skip-ratios (-skipRatio*SkipPenalty) and degrading
For You / Discover quality for web listeners.
Now: on track change, close the prior row as play_ended if that
track reached ~its duration (3s tolerance, matching the Flutter
PlayEventsReporter), else play_skipped at the real last position.
Race fix: the store synchronously resets position/duration to 0 on
track change, so reading lastPositionMs at change-time would see 0
and misclassify. Track per-open-row state (openReachedEnd,
openLastPositionMs, openDurationMs) updated ONLY while the open
track is current — a track change can't clobber them before the
close branch runs.
Brings web wire behavior back in line with Flutter. Test added:
auto-advance after reaching duration → play_ended, never skipped;
existing mid-track-skip and pause-at-end tests still hold.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Flutter client previously reported NO plays — mobile listening
never reached play_events, so history, recommendation scoring,
ListenBrainz scrobbles, and #415 rotation all missed mobile entirely.
Operator chose to close that gap properly as part of Stage 3.
New:
- EventsApi (api/endpoints/events.dart): play_started/ended/skipped.
- PlayEventsReporter (player/play_events_reporter.dart): state
machine over (track id, playing) mirroring the web dispatcher.
Persists an opaque client_id in secure storage. Deliberate
divergence from web: a track change inside a queue is classified
ended-vs-skipped by whether the prior track reached ~its duration
(3s tolerance), instead of web's blanket "track change = skip"
which would mark every naturally-finished in-queue track a skip
and dilute recommendation skip-ratios — the exact failure mode
that motivated doing this properly. Fail-safe: no-ops when there's
no audio handler (tests / no-audio env). App-lifecycle paused/
detached closes an open row as a best-effort skip (web pagehide
parity). Wired in app.dart postFrame.
- PlaylistsApi.systemShuffle(variant): GET the rotation-aware order.
Wiring:
- audio_handler: _queueSource carried through setQueueFromTracks
(source param); preserved across internal skipToQueueItem rebuild.
- player_provider.playTracks: source param → setQueueFromTracks.
- PlaylistCard: system playlists fetch systemShuffle and play as-is
tagged with source (no client shuffle — server already ordered).
- playlist_detail_screen: header Play + per-track tap tag source for
system playlists so rotation advances from any entry point.
Known/flagged separately: the web dispatcher likely has the same
false-skip-on-advance issue; not fixed here to keep #415 scoped and
clients' wire behavior comparable.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Web half of Stage 3. System-playlist tile play now:
- calls the new GET /api/playlists/system/{variant}/shuffle endpoint
(rotation-aware order from the server) instead of getPlaylist;
plays the returned order AS-IS — no client Fisher-Yates, since
the server already ordered it. Supersedes #413's client shuffle
for system playlists specifically; user playlists keep getPlaylist
+ stored order.
- tags the queue with the system variant. The player store carries
_queueSource; the events dispatcher includes `source` on
play_started so the server advances that playlist's rotation.
User playlists are unchanged (getPlaylist, plain playQueue, no
source). Tests updated: For-You play hits systemShuffle (not
getPlaylist/refresh) and passes source:for_you; user play uses
getPlaylist + plain playQueue with no source.
Flutter half is blocked — the Flutter client has no play-event
reporting at all (no /api/events POST, no scrobble), so there's no
play_started to attach `source` to. Surfacing that as a separate
decision rather than silently scope-exploding #415.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
First of three stages for system-playlist sample-history dedup
(Fable #415, server-side rotation per the operator's choice).
Schema (migration 0027):
- play_events.source (nullable text): which surface a play came
from. 'for_you' / 'discover' feed rotation; NULL for library /
user-playlist / radio / Subsonic.
- system_playlist_rotation_state(user_id, playlist_kind,
played_track_ids uuid[], rotation_started_at, updated_at): the
per-(user,kind) set of already-heard tracks this rotation.
Ingest:
- New RecordPlayStartedWithSource on the writer; RecordPlayStarted
is now a thin source="" wrapper so the frozen Subsonic shim is
untouched (no signature ripple).
- When source is a known system kind, the same txn appends the
track to rotation state (AppendRotationPlayed keeps the array a
set via the conflict CASE).
- /api/events play_started accepts an optional "source".
No serve-behavior change yet — Stage 2 makes shuffle prefer the
unplayed tail + resets on exhaustion; Stage 3 wires the clients to
send source and consume the rotation-aware order.
Tests: rotation appends + dedupes for a system source; source-less
play writes no rotation row. (Existing RecordPlayStarted tests are
unchanged — same wrapper signature, identical behavior at source="".)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes Fable #414. forYouHeadN/forYouTailN go 12/13 → 50/50 so the
For-You snapshot is 100 tracks, matching Discover. Motivated by the
shuffle-on-play default that just shipped (#413): a 25-track shuffle
pool repeats fast; 100 makes re-plays within a day feel varied.
pickHeadAndTail already degrades gracefully when the candidate pool
is too thin for a full head/tail split (returns top-N-by-score),
mirroring how Discover returns <100 when its buckets are thin — no
new edge-case handling needed. No build-path test asserts the
For-You total; pickHeadAndTail unit tests pass their own head/tail
values so they're unaffected.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per operator decision: in the playlist detail header, system
playlists (For You / Discover) now show a Regenerate button where
user playlists keep Download. Offline-download is intentionally
dropped for system playlists — operator chose the literal swap.
- Regenerate calls PlaylistsApi.refreshSystem(variant), invalidates
playlistsListProvider (home row tile rebinds to the rotated UUID),
and pushReplacement's to /playlists/<newId> so the open detail
screen rebinds instead of 404-ing on the stale id.
- Null id (empty library) and errors surface as snackbars.
- User playlists are unchanged (Download + Play).
The home-card kebab (#416, 7a04370) stays — web has refresh in both
the detail view and the home tile, so this matches web parity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the Flutter half of Fable #416. Web got a generalized
system-playlist refresh kebab in d12afda; this brings Flutter to
parity instead of leaving the affordance web-only.
- PlaylistsApi.refreshSystem(variant): POST
/api/playlists/system/{for-you|discover}/refresh, maps the
underscore model variant to the hyphenated route segment,
returns the rotated playlist id.
- PlaylistCard: top-right PopupMenuButton on system playlists
with a context-labelled "Refresh For You" / "Refresh Discover"
item. Calls refreshSystem, invalidates playlistsListProvider
(which reconciles the rotated UUID + new tracks), snackbars
the result. ScaffoldMessenger captured pre-await.
- Tests: kebab present for system, absent for user playlists.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes Fable #412 (For You force-refresh on play) and #413
(shuffle-on-play default for system playlists).
Web (PlaylistCard.svelte + player/store.svelte.ts):
- Drop the refreshForYou() call from the play handler. The daily
03:00 user-local snapshot is what plays now. Stops burning server
compute on every press and stops swapping the playlist out from
under the user.
- Generalize the kebab affordance to render for any system playlist
(was Discover-only). Adds "Refresh For You" as an explicit
replacement so users can still force a regen when they want one.
- Extend playQueue(tracks, startIndex, { shuffle? }) to Fisher-Yates
the queue when shuffle:true. PlaylistCard passes shuffle:true for
any non-null system_variant.
Flutter (player_provider.dart + playlists/widgets/playlist_card.dart):
- playTracks now accepts shuffle:bool. When true, picks a random
starting index and enables AudioServiceShuffleMode.all after
setQueueFromTracks. PlaylistCard passes shuffle:playlist.isSystem.
User playlists keep linear order. Detail-screen play buttons are
unchanged for now (follow-up if user requests).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds an About card to Settings that shows the installed version
(version+build from PackageInfo), the latest known version from
clientUpdateProvider, and a "Check for updates" button that
invalidates the provider to force a fresh poll. When an update is
available, surfaces an Install CTA that reuses the same installer
flow as the top banner.
The existing banner (shouldShowUpdateBannerProvider) is unaffected
— it gates on per-version dismissal, while the About section
always reflects the current provider state regardless of dismissal.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Removed in f6ee837 thinking it was unused, but drain() still
reads connectivityProvider.future to gate replay attempts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
