bvandeusen
e68e1b10a6
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>
9 lines
452 B
SQL
9 lines
452 B
SQL
-- Additive: records when Lidarr accepted the add (POST artist/album)
|
|
-- for an approved request. NULL = not yet sent/confirmed; the
|
|
-- reconciler idempotently (re)sends the add until this is set, then
|
|
-- watches for the import. Decouples the durable admin approval from the
|
|
-- best-effort Lidarr call so a transient Lidarr outage no longer forces
|
|
-- a manual re-approve.
|
|
ALTER TABLE lidarr_requests
|
|
ADD COLUMN lidarr_add_confirmed_at timestamptz;
|