Repair the tags on recordings that already exist

[revtex]

Offstream tags a recording while it makes it, and only then. A file recorded before a metadata
source was configured, recorded while Last.fm was down, or recorded from a window title the parser
could not split, keeps its thin tags for good — and the recordings worth keeping are exactly the
old ones. This adds a Metadata page that scans a folder, reads what each file already carries,
looks up what is missing, shows the result for review, and writes the approved tags back.

Three steps in one direction, and only the last one writes. An automatic match is wrong often
enough that the review step is the feature rather than friction in front of it.

Three premises that did not survive contact with the code

Each one looked settled going in. There is no downloads directory — recordings go to the
configured output path, so the page defaults there and offers a picker. The existing Spotify
provider cannot look up a file: it asks what is playing right now, which is useless for a file at
rest, so search is genuinely new code. And there was no Spotify-then-Last.fm fallback anywhere; the
provider is a single user choice, so the chain is new and deliberately confined to this page. The
recording pipeline keeps its single-provider behaviour and is untouched.

LastFmMetadataProvider needed no change at all — it already looks up by artist and title, which
is exactly what a filename or a partial tag gives it.

Retagging cannot go through ffmpeg

This is the constraint the change touches, so it is restated rather than quietly bent. ffmpeg
cannot edit a tag in place; changing one string means remuxing the file, rewriting audio that had
nothing wrong with it. TagLib# writes this path instead — which makes it the second tag writer in
the codebase, and two rules follow:

• It writes tags and cover art in one TagLib# session rather than calling CoverArtWriter
  after itself, which would save the file twice for one edit.
• It pins Id3v2.Tag.DefaultVersion = 3. TagLib# defaults to v2.4 and this project ships v2.3, so
  a retag that silently upgraded the tag would make tags vanish from Explorer and Media Player on
  files that displayed correctly until Offstream touched them.

"ffmpeg writes every textual tag" stays true of the recording pipeline and is now false of this
page. CLAUDE.md says so.

/search costs no user scope, so DefaultScopes stays at two. While in that file: the rule said
Offstream makes exactly three calls while the code already made four, so it now names the five
and states the thing that actually matters — the scope list is what to guard, not the count.

The first layout was unreadable, and the cause was measurement

It was a seven-column table. Long filenames were the visible symptom; the cause is that a
ScrollViewer with HorizontalScrollBarVisibility="Auto" measures its content at infinite
width, so a * column asks for the full unwrapped width of its longest string and TextTrimming
never engages. The trimming was already in the XAML and had never once run — one long filename
widened the table and pushed everything else out of the window.

The row is now compact and shows what will be written — title, artist · album, filename —
and opens on demand into labelled fields, with a was … line only under a field that actually
changes. Three of a hundred and twenty-seven files fitted on screen before; the whole list does
now. Scrolling is Disabled, which is what forces measurement at the real available width.

Two defects only the running app exposed

Both had passing tests on either side of them.

HasChanges ended by asking whether the suggestion had cover art at all — true of every
well-tagged file, since the scan reads the file's own picture into Existing and the copy
constructor carries it into Suggested. The visible half was a "will change" badge on all 127
rows. The invisible half was that the same comparison is what LibraryTagWriter skips on, so
Save would have rewritten every one of those files to embed the artwork it already had. The
whole suite passed, including the test named for skipping a row with no changes, because no fixture
gave a file a picture — a fixture that omits the field a rule is about confirms the rule either way.

A correction typed over a fetched match was discarded at the point of writing. Track keeps a
scraped value and an API value per field and the getter prefers the API one. That is right while a
provider fills gaps and wrong the moment a person corrects the provider. Both tiers are set now.
The existing test asserted the right thing in the wrong scenario: it edited without fetching first,
so the API tier was null and the ordinary setter was enough.

Editing a row after saving it also left the badge dark, since Saved is what suppresses it. The
write was always correct — the writer re-checks — so the page was only lying about there being
nothing left to do.

Other decisions worth knowing

• A fully-tagged file is skipped by Auto-Fetch and shown as Matched, so a large library costs
  few requests and curated tags are never silently replaced. Per-row Re-fetch overrides it.
• .wav is excluded on purpose. Offstream records it, so those files will be in the folder,
  but WAV has no dependable tag container — listing them would show rows that look taggable and
  then fail on save. The page says how many it skipped rather than hiding them.
• Failures are per-row, never fatal. A locked file, a 429, a quota 403 and a no-match each mark
  one row and leave the run going, and Spotify's own error message is surfaced rather than replaced.

Verification

.\build.ps1 -Clean -Test — 1,214 passing (231 UI + 983 Core), 0 warnings. -VerifyFormat
clean. Resource keys 182/182 across en and fr.

Beyond the suite, the page was driven in the running app against a real 127-file library with
UIAutomation and real mouse input, because a clean build and a green suite are not verification for
a WPF page — that is how both defects above were found. Confirmed there: trimming engages on long
filenames, click-to-expand fires on the row text (119px → 395px) without fighting the checkbox,
a live Re-fetch returns Suggested with the badge lit on that row alone, and the was … line
appears under the one field that changed. The shell's MinWidth is 1024 DIP and the display runs
at 150%, so every frame was already at the narrowest width the page can ever render.

🤖 Generated with Claude Code