## Done

### Round 47 (2026-09-06) — LinTunes writes the device's library (v0.17.0)

The first half of andTunes, a music player for the Rabbit R1 that never scans
anything. Auxio re-reads Android's MediaStore on every launch, which is what
leaves the Rabbit sitting on "your songs will show up here" — so the answer
isn't a faster scanner, it's not scanning: LinTunes already knows the artist,
album and year of every file it just copied, so it writes them down and the
app reads one JSON file. This round builds the desktop side; the app itself is
rounds 48–50 (`andtunes/TASKS.md`).

- [x] **A de-duplicated tree instead of a folder per playlist.**
      `lintunes/andtunes/layout.py` lays out `Music/andTunes/` — `Media/
      <Artist>/<Album>/04 Song.mp3` (the iTunes shape `filename_tags` already
      reads back, with a `2-04` prefix once a release has more than one disc),
      `Art/<key>.jpg`, `Playlists/<Name>.m3u`, `library.json`. A song in three
      playlists is stored once, which the Artists/Albums/Songs screens need
      anyway and which saves the space three copies cost.
- [x] **`library.json`, the reason the app opens fast.**
      `andtunes/manifest.py` is pure — no Qt, no device, no I/O. Rows are
      sparse the way `Track.to_dict` is sparse, because that file is what the
      R1 parses before it can draw anything. Artists and albums are *not*
      shipped: grouping a flat list on device beats parsing three redundant
      ones. A playlist's ids are filtered to tracks that actually landed, so
      the app never resolves a dangling reference.
- [x] **One cover per album, not per song.** `andtunes/art.py` reads the
      embedded artwork with mutagen, scales to 480 px (the panel's width) and
      re-encodes as JPEG through `QImage`/`QBuffer` — no new dependency, and
      QImage is safe off the GUI thread. Keyed on album artist + album, so a
      twelve-track record costs one mutagen open and one file. Cached under
      `$XDG_CACHE_HOME/lintunes/andtunes-art`, invalidated by the audio file
      being newer — which is exactly right, since embedding new art rewrites
      the file and moves its mtime.
- [x] **A sibling worker, not a flag on the old one.**
      `andtunes/sync.py` follows the `plan_export`/`ExportWorker` shape
      exactly: pure planner, then a daemon thread emitting KiB progress, with
      the same MTP caveats (no copystat, diff by name+size). It is separate
      because it nests directories, has an album-art pass, and writes several
      trailing files instead of one m3u. Planning deliberately does *not*
      render art — that's a mutagen open per album and planning runs on the
      GUI thread.
- [x] **The index is written last, and always describes what's really there.**
      Cancel mid-sync and the manifest and m3us are rewritten listing only
      tracks whose files landed, so andTunes opens a smaller working library
      rather than a broken one. Re-syncing completes it.
- [x] **A containment guard, because this is the first code that deletes a
      directory on the Rabbit.** Every delete goes through
      `layout.assert_inside`, which refuses anything that isn't strictly
      inside the andTunes root — so the old `Music/<Playlist>/` folders are
      structurally unreachable, not merely un-referenced. `Buttons/` (the
      user's own menu artwork) and `plays/` (written by the app) are skipped
      by the scan entirely: sync reads those, it doesn't own them. Emptied
      folders are pruned bottom-up, asking the filesystem rather than
      `os.walk`'s stale listing.
- [x] **Unticking a playlist is how it comes off the device.** New
      `Connections → Sync to Rabbit` (everything ticked, no longer caring
      which view is open) and `Rabbit Sync Settings…`
      (`gui/device_sync_dialog.py` — a checkbox list with a filter box,
      because 487 playlists is a normal library here). The selection lives in
      `preferences.json` under `device_sync`, so it rides the Syncthing share
      and both machines agree on what the Rabbit is carrying; keeping it off
      the `Playlist` keeps it out of the conflict-merge machinery.
- [x] **The old per-playlist sync stays, renamed "(Auxio)".** Removing it in
      the same round that adds the new tree would leave the device full of
      files and nothing able to open them until round 49. It goes when
      andTunes can actually play a song.

Not done, deliberately: the Android app (rounds 48–50), shipping default
button images, the format gate for files Android can't decode, and reading
play counts back off the device. Verified against the real 21,531-track
library into a scratch device root — a re-sync copies nothing, and unticking
a playlist removes its media, its m3u, its now-unused cover and every emptied
folder.

### Round 46 (2026-09-02) — The file already told you (v0.16.0)

Round 45 shipped and trav broke it in two places within the hour, both real.
"B. Clem - Zuuso [1025657891]" fingerprinted fine and matched **nothing**, and
"Snowfall (Live At The Alhambra_1961)" matched but proposed a 2002 reissue year
and ranked a compilation above the album its own filename named.

- [x] **The limit is the database, not the fingerprint.** Verified before
      building anything: that Zuuso fingerprint returns zero AcoustID results,
      a MusicBrainz text search for "Zuuso" returns zero, and iTunes returns
      zero (and irrelevant fuzz for "B. Clem"). The track exists in no metadata
      service on earth. So no smarter lookup — LLM or otherwise — could have
      answered it, because there was nothing to answer with.
- [x] **But the filename knew.** New `lintunes/filename_tags.py` reads tags out
      of the name yt-dlp gave the file. "B. Clem - Zuuso [1025657891]" → artist
      "B. Clem", name "Zuuso", which is exactly what trav said it was. Checked
      against all 474 files in the untagged folder, not against invented
      examples.
- [x] **Careful about what it strips.** An 11-character trailing token is only
      a YouTube id if it carries a digit, an underscore, or case that flips
      repeatedly — otherwise "Cold Draft-Underground" loses a word. A hyphen
      only splits artist from title when it has spaces around it, so "Jay-Z"
      and "350-440-DialTone" survive. A 4-digit year is never a numeric id.
- [x] **A guess is labelled a guess.** `IdentifyCandidate.source` is
      "acoustid" or "filename"; the dialog quotes a match confidence only for
      the former and says "No database knows this — read from the file's name"
      for the latter, rather than inventing a percentage.
- [x] **The file now ranks the results too.** `hint_for(track)` feeds tag +
      filename tokens into `parse_lookup`: overlap scoring (words count double,
      bare numbers single — "alhambra" identifies a release, "1961" appears in
      every compilation spanning it), a coarse duration bucket against the
      recording lengths AcoustID returns, and a filename year that predates
      what the database knows. Alhambra now ranks the right album first with
      year 1961 instead of a compilation with 2002.
- [x] **Live is no longer a demerit.** It was lumped in with Compilation, which
      buried a live album for a file whose name said "Live At The Alhambra".
      Only compilations, remixes, interviews and the like are demoted now.
- [x] **Why the year needed the filename at all:** MusicBrainz's own
      `first-release-date` for "Ahmad Jamal's Alhambra" is *2002* — its three
      original 1961 pressings are in the database undated. A second MusicBrainz
      call, the obvious fix, returns the same wrong answer. 1961 exists only in
      trav's filename.
- [x] Not done, deliberately: trav rejected "never propose a shorter title" —
      truncating is *wanted*, because the garbage in a title is usually the
      part being dropped.

### Round 45 (2026-09-02) — Ask the song what it is (v0.15.0)

Some files arrive with the title right and everything else missing or wrong,
and there was no way to fix that except typing. Now the audio itself is the
question: right-click → **Identify Track…** fingerprints the file and asks
AcoustID who it is.

- [x] **Fingerprint, not filename guessing.** New `lintunes/fingerprint.py`:
      `fpcalc -json` (Chromaprint's CLI, detected with `shutil.which` like
      `ffmpeg_available()` — a runtime tool, not a pip dependency) produces a
      duration + fingerprint, which `lookup_fingerprint` POSTs to the AcoustID
      web API with `meta=recordings releasegroups releases tracks compress`.
      `requests` was already a dep, so the round adds none.
- [x] **The year is the song's, not the pressing's.** trav's actual complaint:
      "I don't care when the CD of something from the 60s came out." So
      `parse_lookup` proposes the *original* release year — the earliest date
      across every release group the recording appears on — and every candidate
      carries it, including the one proposing a 1998 greatest-hits as the album.
      Years sort by when the song came out. `_releasegroup_sort_key` separately
      ranks a plain studio Album above EP/Single above anything wearing a
      Compilation/Live secondary type, so the *default* proposal is the real
      album too.
- [x] **Nothing is written until you say so.** `gui/identify_dialog.py` is
      passive the way `AlbumArtDialog` is — candidates arrive pre-parsed, and
      the caller applies the result afterwards. Each row shows the current value
      beside an editable proposed one, with a checkbox that starts checked only
      where the proposal actually differs from what the file already has (a row
      the lookup knows nothing about is disabled, so it can't quietly blank a
      tag). A dropdown switches between alternate releases.
- [x] **Applied through the one funnel.** `LibraryManager.edit_track_fields`
      does it, so tag writes, the abort-if-the-write-fails rule, artist/album
      file relocation and a single undo step all come free rather than being
      re-implemented.
- [x] **A selection is a queue, one dialog at a time.** Each track is reviewed
      on its own; "Stop Identifying (N left)" abandons the rest, and a failure
      (unfingerprintable file, network error, no match) is a status-bar message
      that moves on to the next rather than ending the batch.
- [x] **The key is trav's, and stays out of git.** `preferences.acoustid`
      + a Preferences row linking acoustid.org/new-application, following the
      Last.fm precedent — preferences.json rides the Syncthing share, so
      pasting it once covers both machines.
- [x] Fixed an unrelated pre-existing test failure: round 40's
      `test_the_pre_010_music_root_key_counts_as_an_override` used the real
      tummult mount point as its stand-in for an unreachable path, so it failed
      whenever that drive was actually plugged in. It now builds the path under
      `tmp_path` and never creates it.

### Round 44 (2026-08-27) — A removal you make sticks (v0.14.0)

Round 43 made the merge report honest, which made its one real limitation
impossible to miss: every merge was a union, so a song removed from a playlist
on one machine was handed straight back by the other on the next sync, and a
track deleted from the library came back with it. A deletion you cannot make
stick is not a deletion.

- [x] **Removals are recorded, not inferred.** The union was there for a real
      reason — two copies and no common ancestor cannot tell "A added this" from
      "B removed it" — so the missing evidence is now written down. New
      `lintunes/tombstones.py`: `Playlist.track_events` holds
      `{track id: [when, "add"|"remove"]}` and `Library.deleted_tracks` holds
      `{track id: when}` in `library_metadata.json`. A merge takes the newest
      event per track across both copies and applies it. A removal beats a copy
      that merely still had the song; a deliberate re-add afterwards beats the
      removal; a track nobody touched still merges as a union, which is the safe
      old behavior for everything that has no evidence either way.
- [x] **Not "the newer copy wins wholesale".** That was the tempting one-line
      version and it silently drops a song the other machine added while you
      were removing one. `test_an_unrelated_addition_is_not_lost` pins it.
- [x] **Recorded in the existing funnels.** `_set_track_ids` diffs before/after
      (so a reorder records nothing), `_remove_tracks` stamps
      `deleted_tracks`, and `_restore_tracks` clears it, so Ctrl+Z on a delete
      takes the tombstone back with it.
- [x] **Track ids are never reused.** The sharpest edge in the whole design: the
      next id came from `max(library.tracks)`, so deleting the highest-numbered
      track freed its id for the next import — and that new track would be
      dropped on sight by the dead id's own tombstone, on every machine.
      `_highest_track_id` counts the deletions too.
- [x] **`library_metadata.json` merges before `library.json`.** It carries the
      record the library merge filters against, and `rglob` order is not a plan.
      `_merge_metadata` unions the two copies' `deleted_tracks` regardless of
      which whole copy the mtime pick kept.
- [x] **A merge applying a deletion never touches a music file.** It drops the
      library entry only — the file was already trashed on the machine where the
      delete happened, and the music folder is its own Syncthing share.
      `test_a_merge_never_touches_a_music_file` fails the run if `send_to_trash`
      is so much as called.
- [x] **Reported as a warning, with the song named.** An applied removal grades
      WARNING so it opens the merge window, names each track, and says Ctrl+Z
      does not reach a merge. `_Labeler.remember` keeps the name of a track
      library.json is about to lose, so the playlist merge can still say which
      song it dropped rather than "track 4".
- [x] **Events expire after 30 days** (`RETENTION_DAYS`), pruned at the save
      boundary like the derived-membership gate. The trade is stated in the
      module docstring: a machine offline longer than that can resurrect a song
      it never learned was deleted.


### Round 43 (2026-08-27) — The merge report says who, what, and where (v0.13.0)

The merge window kept saying `Order kept from this machine (most recently
edited)` for playlists trav had edited on the *other* machine, and offered a
backup folder holding two directories with one hex-named JSON each. Confirmed
against the real snapshots in `.resolved/`: in the 9:34 PM `* a fresh master`
merge, the copy labelled "the other machine" was this machine's own 3:15 PM
merge output (2472 tracks, `date_modified 19:15:26` — the previous merge's own
stamp), so the label was exactly backwards.

- [x] **Stop guessing which machine wrote which copy.** "this machine" was
      inferred from which copy held the plain filename, and that is Syncthing's
      call, not a statement about authorship — it sets the local copy aside as
      readily as a remote one. The report now names the two copies for what
      they factually are ("the copy that was already here" / "the copy
      Syncthing set aside") and attributes the set-aside one from the 7-char
      device ID in the conflict filename, which `CONFLICT_PATTERN` used to
      match with a bare `\w+` and delete along with the file. New
      `lintunes/sync_identity.py` maps that token to a device name out of
      Syncthing's `config.xml` and works out which one is us by deriving our own
      device ID from `cert.pem` (base32 of the SHA-256 of the DER cert, the way
      Syncthing does). Stdlib only, best-effort: no Syncthing, no config or an
      unreadable cert all mean the report simply names nobody.
- [x] **`date_modified` is consulted when only one copy has one.** It used to
      need *both* stamps (`if ours and theirs`) and otherwise fell back to file
      mtime — and a playlist imported from iTunes and never reordered on this
      machine has no stamp at all, so the honest comparison was skipped exactly
      when one machine had edited and the other hadn't. A stamp only exists once
      LinTunes recorded an edit, so stamped-vs-unstamped is evidence: the
      stamped copy wins. mtime is the fallback only when neither side has ever
      been edited, and the report says so when it happens.
- [x] **No more mtime ratchet.** `_merge_playlist` rewrote the file it kept on
      every merge, whether or not anything changed, while Syncthing preserves
      the origin's mtime on the conflict file — so each merge made the copy in
      place harder to beat on the next one. A no-op merge now writes nothing. A
      merge that produces a true union stamps `date_modified`, because content
      neither copy had is genuinely newer than both; that is what stops two
      machines trading the same 19 tracks back and forth (three times in one
      evening, in the snapshots).
- [x] **The report names the songs.** `merge_track_order` knew every
      re-inserted track's position and threw it away. Each re-inserted track is
      now listed as `Artist — Title → position 24, after "…"`, six in the window
      and all of them in the backup. Titles come from a lazy read of
      `library.json` (the 15 MB file, so only when a playlist merge actually
      needs a name).
- [x] **Tracks the other copy didn't have are reported, not resurrected in
      silence.** The union policy is unchanged — nothing is ever removed — but a
      track only this copy has is now named, with both readings offered ("if you
      added it here, that's all this is; if you deleted it on the other machine,
      delete it here too"), since two lists give no way to tell which it was.
- [x] **`what-changed.txt` in the backup folder.** The same merge in words,
      uncapped, beside `original/` and `incoming/` — including the real
      Syncthing conflict filename and its device, which the merge otherwise
      destroys. The dialog button is now "Open merge report".
- [x] **A rename or folder move made elsewhere survives a merge.** Only
      `track_ids` and `settings` were ever taken from the winning copy, so a
      playlist renamed on the other machine was renamed back by every merge.
      `name` and `parent_persistent_id` come from the winner now, and
      `_apply_rename`/`_apply_reparent` stamp `date_modified` so a rename is
      comparable across machines at all.
- [x] **The same revert, on the sync path with no conflict file.**
      `_reconcile_playlist` asserted in its docstring that the local edit was
      the more recent one and never checked — so a reorder synced in from the
      other machine was undone and then flushed straight back to disk. It reads
      the stamps now, and adopts `name`/`parent`/`settings` when the disk copy
      wins. The branch that reaches it is also gated properly: `_dirty_playlists`
      is set by a column drag or a sort click too, so a sync landing in the 3 s
      after a cosmetic click routed through the keep-local path. New
      `_dirty_playlist_content` marks only real content edits — the Round 42
      rule ("cosmetic table settings must not look like edits") one level up.
- [x] **The music folder no longer rides a coin flip.** `_merge_metadata`
      inferred which copy had lost from whichever one `_keep_newer`'s mtime pick
      had kept; when both files land in the same instant that pick is arbitrary,
      which is why `test_but_adopting_a_music_folder_is_a_change` passed about
      half the time. It decides from the two inputs' `music_folder_set_at`
      directly, and grades CHANGE when the folder actually differs from the one
      we started with.


### Round 42 (2026-08-22) — A web mix stops shipping an .m3u (v0.11.1)

- [x] **No `.m3u` beside `index.html`.** It shipped on the theory that it cost
      nothing and let the folder double as a plain music folder, but a web mix
      is a folder you upload — a stray playlist file next to the page is one
      more thing to explain to whoever receives it. `plan.m3u_name` is now `""`
      for `WEB` so the plan says so rather than naming a file it won't write,
      and `index.html` is simply the last thing written, which is what the
      manifest-last invariant always meant for that branch. Folder exports are
      untouched.

### Round 41 (2026-08-22) — Web mixes pick their own color (v0.11.0)

Every exported mix came out in the same 2010 gold-and-brown skin: a `#c7b563`
player bar, `#ccc` progress fill, and a hard-coded `#8c764a` behind every hover.
Now the hover backgrounds and the progress fill are one color the user picks in
the export dialog, and the rest of the bar is deliberately colorless so that
choice is the only color in it.

- [x] **One accent, chosen per export.** A swatch button in `WebMixDialog`
      opening `QColorDialog`, plus Reset. Deliberately *not* persisted — it
      opens on `exporter.DEFAULT_ACCENT` (`#8c764a`) every time, so an export
      nobody touches still looks exactly like the mixes already online.
      `exporter.normalize_accent` is the injection gate, not a nicety: the value
      is substituted raw into the page's `<style>` block and `string.Template`
      escapes nothing, so anything that isn't `#rgb`/`#rrggbb` falls back to the
      default.
- [x] **Delivered as a CSS custom property**, `:root { --accent }` declared in
      `index.html`, which `player.css` reads as `var(--accent, #8c764a)`. That is
      what lets the stylesheet stay in the verbatim `shutil.copyfile` loop —
      `index.html` is still the only thing rendered.
- [x] **Hover text flips black or white** against the accent
      (`exporter.contrast_text`, the same luminance rule `theme.apply_theme`
      uses). The old page hard-coded white, which vanished the moment anyone
      picked a pale color.
- [x] **The player bar is fixed light gray with black text**: `#eee` behind the
      transport, `#000` for both elapsed and duration, a gray buffered segment,
      and a dark box-shadow in place of the near-white one that was invisible on
      the white page it always sat on.
- [x] **Black glyphs without touching the GIF.** The sprite's play/pause are
      pale lavender and the spinner is yellow — drawn for the dark gold bar and
      invisible on light gray. `filter: brightness(0)` zeroes every channel and
      leaves alpha alone, so they paint solid black and the loading frame still
      animates. `player-graphics.gif` still ships byte-identical.
- [x] `theme.swatch_icon()` — `preferences_dialog`'s private `_swatch` promoted
      so the export dialog isn't a second copy of it.

Verified in Chrome against two generated mixes: a dark teal (`#0f8a7e`) accent
gives white hover text, a pale yellow (`#f2e96b`) gives black, and both paint
the progress fill while the bar around it stays gray with a visible black
play/pause.

### Round 39 (2026-08-20) — Playlist merges stop losing your track order (v0.9.1)

The playlist half of the Round 36 rework, and what actually scrambled
`a nissa one`. It took three defects together: reorder it on machine A, open it
on machine B and resize the window, and B's file is newer, so the merge takes
B's order — the old one — wholesale.

- [x] **Anchor-based merge.** `merge_track_order` in `conflict_resolver` unions
      two orderings by re-inserting each side-only track after the nearest track
      both copies share, instead of appending it at the tail. `_merge_playlist`
      and `library_manager._reconcile_playlist` (the live-reload path) both use
      it. The union invariant is unchanged and property-tested over 300 random
      pairs: a merge never drops a track, duplicates and disjoint lists included.
- [x] **`Playlist.date_modified`, bumped only in `_set_track_ids`** — the single
      funnel for add / remove / reorder / undo, and deliberately *not*
      `mark_playlist_settings_dirty`. `_playlist_newer` prefers it over the
      file's mtime, falling back to mtime for playlists written before the field
      existed. The smart-playlist branch uses the same test, which told the same
      lie.
- [x] **A window resize no longer rewrites the playlist.** The last column is
      stretch-sized, so Qt re-fires `sectionResized` for it whenever the viewport
      width changes — a resize or a splitter drag rewrote the open playlist's
      JSON, moved its mtime, and handed Syncthing another conflict, all for a
      width `apply_settings` overrides on load. `_on_section_resized` skips that
      section; genuine drags on every other column still persist.

Replayed against the real playlists on a copy: on `a nissa one` (23 tracks) the
reorder survives a newer-by-mtime opponent, and on `a nissa ideas` (26 tracks)
the other machine's two mid-list inserts land at 5 and 12 rather than 26 and 27.

### Round 38 (2026-08-20) — One merge window, and play counts that can't conflict (v0.9.0)

Fifteen "Synced changes merged" windows were stacked on the desktop. Two
independent bugs, and the `.resolved/` backups said which mattered: every one of
the last nine `library.json` merges was ~98% play counts (43-47 of ~45 changed
tracks) plus exactly one real edit — the same single rating each time. The same
~45 tracks disagreed in *every* merge and the count only crept down (48 → 44 over
a day), so `max()` had been quietly discarding plays for at least that long.

- [x] **One window, not one per merge.** `show_conflict_summary` built a fresh
      `ConflictSummaryDialog` each time and only reassigned the attribute — the
      old dialog stayed a live child of the window. Since
      `check_for_external_changes` runs `resolve_conflicts` on every Syncthing
      watch tick, that was one window per merge for the life of the process. The
      dialog is now a session log: `add_event()` folds each merge in as its own
      timestamped entry (newest first), the restore button names the merge it
      would undo, and `finished` clears MainWindow's reference so a close lets
      the next merge open a fresh one.
- [x] **Per-machine play journals.** `library.json` now holds only a base count;
      each machine owns `plays/<machine-id>.json` with its own per-track totals,
      and the effective count is base + the sum of all journals. Only the owner
      writes its journal, so play data can't conflict; totals rather than an
      append log, so there's no compaction step to double-count in; and a machine
      still on older code keeps bumping its own base, which stays additive with
      our journal, so the version-skew window is safe too. On the real 21k
      library: three plays wrote **83 bytes** and left `library.json` untouched,
      where before each one rewrote 15 MB.
- [x] **The two hazards, pinned by tests.** `save_tracks` must write the base and
      `PlayJournal.load` must be handed a base-valued library — the second is why
      `reload_from_disk` folds the journals onto the `disk` copy *before*
      reconciling, or the max() against the effective in-memory count would win
      by exactly this machine's journal.
- [x] Journal conflicts merge by highest total rather than newest-wins. They
      shouldn't be possible; if a filesystem oddity makes one, falling through to
      `_keep_newer` would discard a machine's whole history.

Deliberately not done: lossless merges still open the window rather than
demoting to a status-bar line. With journals landing, a merge stops being
routine — the ones left are real edits, and worth seeing.

### Round 37 (2026-08-19) — Export a playlist: a folder, or a whole website (v0.8.0)

`File → Export Playlist…`, and the same item on a playlist's right-click menu.
Two destinations behind one planner, built as a sibling of `device_sync` (same
shape: a pure `plan_export`, then a worker on a daemon thread reporting through
signals, sharing the status-bar progress widgets and the cancel button).

- [x] **Folder export** — the audio files under `Artist - Title.ext` names next
      to an extended `.m3u`. No `.pls`; nothing reads it any more. Files are
      copied byte-for-byte, never re-encoded.
- [x] **Web mix export** — a self-contained static site reproducing the
      hand-made yearly mixes: `index.html`, `audios/`, a hero image, and a
      dialog for title / description / image. The description is deliberately
      passed through raw (the mixes lean on inline links right there); the title
      and track labels are escaped. Per-track liner notes stay hand-edited —
      `index.html` carries a commented-out block in the right spot.
- [x] **audio.js and jQuery are gone.** The old pages shipped ~293 KB: a build of
      audio.js whose upstream hasn't moved since 2012, plus jQuery 3.2.1
      (CVE-2019-11358, CVE-2020-11022, CVE-2020-11023 — not exploitable on a
      static page, since nothing untrusted ever reaches a jQuery HTML sink, but
      dead weight either way). The decisive detail: **audio.js never used
      jQuery** — jQuery was there for ~25 lines of tracklist glue. Replaced by a
      ~180-line dependency-free `player.js` + a `player.css` transcribed from
      the customized audio.js skin, so the page looks the same: same 250px
      `#c7b563` bar, same `player-graphics.gif` (shipped byte-identical — it's
      an *animated* GIF, the loading state is a spinner), same click-to-play,
      autoplay-next and ←/→/space shortcuts. **~293 KB → ~6 KB.** The Flash
      fallback went with it; audio.js gated it on `!canPlayType("audio/mpeg;")`,
      unreachable in any browser since ~2010.
- [x] **Conversion only when a browser genuinely can't play it, and never lossy.**
      `export/web_support.py` is a deny-by-default gate modelled on
      `cast/support.py`, using the iTunes `kind` string to disambiguate `.m4a`
      (plain AAC / Apple Lossless / FairPlay all wear that suffix). Bitrate is
      **not** a trigger — a 320 kbps MP3 is copied verbatim. Everything that
      does convert targets **FLAC**, so a conversion cannot cost a bit; a test
      asserts the exported FLAC's decoded PCM hashes identical to the ALAC
      source. Against the real library that is 105 Apple Lossless + 8 AIFF out
      of 21,382 tracks. DRM'd tracks (6 Protected AAC) are reported in a
      confirmation dialog, never silently dropped and never attempted.
- [x] **ffmpeg is detected, not assumed** — it's the CLI binary, which is a
      different thing from Qt Multimedia's ffmpeg backend. Missing, the export
      offers to go ahead without the affected tracks.
- [x] **The manifest is written last.** A cancelled or interrupted export leaves
      no `index.html` and no `.m3u`, so a half-finished folder never advertises
      files that aren't there. Cancel also removes the in-flight partial file.
- [x] Verified in **Chromium 151 and Firefox 153** driven over CDP/Marionette:
      all four exported formats decode (including the converted FLAC), the
      player builds, the gold bar and sprite render, click / space / ←→ /
      scrubber-seek / autoplay-next all work, and the network log shows no
      request for jquery, audio.min.js or any `.swf`.
- [x] `mix-example/` removed — it was the reference for the template and the
      template now reproduces it.

### Round 35 (2026-08-19) — Startup speed: the 21k-track library stops freezing (v0.7.0)

Reported as three separate complaints — "startup takes a minute or two and GNOME
offers to force quit", a playlist insert that jumped to the end, and the pile of
merge dialogs — which turned out to share one shape: every operation was
whole-library, whole-file, on the Qt main thread. Measured against the real
library (21,482 tracks, 506 playlists, 15 MB `library.json`).

- [x] **The track table sorts itself.** `TrackTableView` ran its model through a
      `QSortFilterProxyModel`, which asks `data()` for a value on *every
      comparison* — 580k Python round trips, **8.5 s per table load**, paid again
      on every reload. The model now keeps `_tracks` in canonical (playlist)
      order plus an `_order` index list, and sorts a key list computed once per
      track. Nothing used the proxy's filtering (the column browser filters by
      handing `set_tracks` a shorter list). Sorting by `#` is the identity order,
      so "source row" still means "playlist position" for drag-reorder.
      **8.5 s → 0.13 s.** `MainWindow()` **18.1 s → 0.79 s.**
- [x] **Smart rules compile to closures once per `evaluate()`** instead of being
      re-dispatched per track: the operator lookup, casefolding the query, and
      parsing the rule's own date constants all leave the 21k-iteration loop
      (`_match_date` was re-parsing its own constant 21,482 times per rule).
      Verified against the previous implementation on all 20 real smart
      playlists: **identical membership, 0 mismatches**. **2.54 s → 0.72 s.**
- [x] Smart recompute deferred until after the first paint (`main.py`), so the
      compositor always has a window that answers.
- [x] `_reconcile_track` skips the two `to_dict()` round trips when a track is
      unchanged (`MERGEABLE_FIELDS` in the resolver is now the single source of
      truth for what a merge can touch). A sync changes a handful of tracks out
      of 21k; this was most of the cost of a reload.
- [x] No git subprocess on the startup path: `Updater.enabled` is probed lazily
      on the background check thread (it was two `rev-parse` calls with 15 s
      timeouts in `__init__`), and the version button loads its commit-hash
      tooltip after the window is up.
- [x] `.resolved/` is pruned to the newest 10 snapshots. It had reached **1.7 GB
      across 73 snapshots**, never pruned — and it lives inside the Syncthing
      share, so every 15 MB pre-merge copy was being replicated to the other
      machine.

Net: **time-to-interactive-window ~15 s → 3.2 s**, and the mid-session freeze
when Syncthing delivers a change (which is what GNOME was actually offering to
force-quit — a full reload + recompute + table rebuild with the window already
on screen) **~16 s → 3.8 s**.

Not in this round, deliberately: the merge rework itself (playlist ordering,
per-machine play journal, quieting the dialog) — see TASKS.md.

### Round 34 (2026-08-15) — The parking brake: stop playing audio at 3am (v0.6.1)

The long-running "LinTunes plays by itself" haunting, finally attributed and
fixed. Five-plus incidents since July, always the same shape: a few seconds of
audio from the middle of a song, at some random hour, hours after the app was
last touched, never recording a play count.

It was never a control event. The v0.1.4 provenance log had **zero** entries
between the 17:48 pause and the 00:30 incident — no MPRIS, no media key, no
AVRCP ghost — while MPRIS still reported `Paused` at exactly `6974000µs`, the
same position it was paused at seven hours earlier. Meanwhile PipeWire showed
LinTunes owning a stream in state `running`, linked to the DAC, gain 1.0.

Cause: a paused (or stopped) `QMediaPlayer` on the FFmpeg backend keeps its
PipeWire stream open and never corks or drains it, so the few seconds the
backend had decoded ahead sit there live. When the audio graph is later rewired
— a USB DAC waking from idle suspend, a device appearing — that stale buffer
flushes to the speakers. It explains every observation: always a short burst
(it can only be what was buffered), always mid-song, never a play count (nothing
resumed), and why the Fedora machine never does it (no USB DAC to wake up).
Reproduced standalone on Qt 6.8.2 / FFmpeg 7.1.5 in ~20 lines.

- [x] `PARK_AFTER_IDLE_S` (30s) + `LocalSink._park()` / `_unpark()`. After that
      long idle, release the pipeline: `stop()` then `setSource(QUrl())`, which
      is verified to remove the PipeWire node outright — there is no buffer left
      that could ever leak. Resume rebuilds the source and rides the existing
      custom-start-time machinery to seek back.
- [x] Two independent layers, deliberately: gain goes to 0 *before* the
      teardown, so anything still buffered downstream drains silently even if
      the release misbehaves. `_apply_volume()` forces silence while parked, so
      the volume slider can't re-arm it.
- [x] `stop()` arms the brake too — Qt's `stop()` leaves the source loaded, and
      `Player._advance()` calls it when a playlist runs out, so "playlist ended
      at 1am" was a second, equally real leak path.
- [x] Parked state serves `position_ms()`/`duration_ms()` from a cache and
      suppresses the media object's position/duration/state/status signals, so
      the teardown never reaches the UI as a jump to 0:00 and a stray
      `EndOfMedia` can't advance the queue.
- [x] `seek()` while parked moves the resume point instead of poking a dead
      pipeline; `load()` discards parked state; `shutdown()` disarms the timer.
- [x] Verified end-to-end against the real `LocalSink` (silent WAV, zero gain,
      watched via `pw-dump`): stream present while playing, still present right
      after pause, **gone** once parked, rebuilt on resume with position and
      duration intact. Tests in `tests/test_round34.py` (17).

Note: this is a workaround for an upstream Qt Multimedia bug, not a LinTunes
design flaw — GStreamer-based players get correct pause behavior for free by
corking. See the backend note under "Parked / deferred".

### Round 33 (2026-08-14) — Delete songs from the library (v0.6.0)

An iTunes 12 habit LinTunes had no answer for: getting rid of a song you don't
want to keep. `LibraryManager` had `add_track` but no inverse, and nothing in the
app had ever deleted a local music file. Deletion goes to the desktop trash
rather than `unlink`, so it's recoverable both by Ctrl+Z and from the file
manager afterwards.

Two constraints shaped it. The trash is **per-filesystem** — the music sits on a
mounted volume, so the right destination is `<topdir>/.Trash-<uid>`, and using
the home trash would mean a cross-device copy plus a recorded original path
"Restore" can't reach. And playlist cleanup has to be **synchronous with the
removal**: playlist edits address tracks by row index into `track_ids` while the
view skips ids missing from the library, so a dangling id would desync the two
and make a later "Remove from Playlist" hit the wrong track.

- [x] `lintunes/trash.py` — freedesktop Trash spec 1.0 by hand, no new
      dependency (a new pip dep would need a manual `pip install -e .` on the
      other machine). Picks the trash by the file's own mount, writes the
      percent-encoded `.trashinfo` with `O_EXCL` first to claim the name, then
      renames the file in; a failed rename cleans up the info file. `TrashError`
      leaves the file untouched.
- [x] `LibraryManager.delete_tracks(ids, delete_files=)` — the single funnel.
      Removes from `library.tracks` and every non-smart playlist, prunes the
      dirs it emptied, invalidates the exported artwork, and pushes one undo
      Command covering the whole selection. A file that can't be trashed
      **keeps its track** rather than leaving an orphaned entry. New
      `tracks_removed` / `tracks_restored` signals.
- [x] Undo restores the file from the trash *and* the track's original position
      in each playlist; redo re-trashes (re-recording paths, since a redo can
      land on a different collision-suffixed name). If the trash was emptied
      behind us, the library entry is restored anyway — a visible broken track
      beats a silent second loss.
- [x] `Player.drop_tracks()` — stops if the deleted track is playing, otherwise
      keeps the current track's place in the shortened queue. Previously a dead
      id in the queue made `_load_current` stop everything with an error dialog
      once the walk reached it.
- [x] Context menu gains "Remove from Library" and "Remove from Library and
      Delete File", in **both** the library and playlist views. No keyboard
      shortcut — `Del` still means "remove from playlist". Confirmation uses the
      existing destructive-dialog idiom (DestructiveRole button, Cancel as
      default) and names the playlists affected.
- [x] `tests/test_round33.py` (26 tests) covers the spec details (volume vs home
      trash, percent-encoding, collision suffixes, no orphaned info file on
      failure), the manager (playlist cleanup, pruning, partial failure, undo of
      position, emptied-trash undo) and `drop_tracks`. Verified for real against
      `/run/media/trav/tummult/.Trash-1000` with a scratch file.

### Round 32 (2026-08-14) — Custom start times survive a track change (v0.5.2)

trav reported "Pretty Girls is a Motherfucker" starting at 0:00 despite its
imported 0:40 start time. Import and storage were fine (70 tracks carry a start
time, 72 a stop time); the seek was being thrown away. `QMediaPlayer.setSource()`
synchronously emits *two* status changes before it returns — a `LoadedMedia`
still reporting the **outgoing** source, then `LoadingMedia` for the new one —
and the stale first event consumed the one-shot `_pending_start_ms` armed by
Round 22, leaving nothing for the new track's real `LoadedMedia` ~5 ms later.
So it misfired on every track change; only the first track after launch worked,
which is why Round 22 looked green.

- [x] The armed seek is tagged with the URL it belongs to
  (`_pending_start_url`), and `_on_media_status` consumes it only when
  `source()` matches — a status change fired for other media can't eat it.
- [x] `LocalSink.load` restructured so the pending seek is armed only on the
  new-source branch; Round 22's same-source replay path still seeks directly
  and arms nothing.
- [x] `tests/test_round32.py` models the real Qt event sequence (a `setSource`
  side effect that fires the stale `LoadedMedia` before switching `source()`),
  which Round 22's plain `MagicMock` never did. All three behavioral tests fail
  on the old code. `test_round8` / `test_round22` stubs updated to report the
  new source by the time its `LoadedMedia` arrives, as real Qt does.
- [x] Verified against the real files headless: switching from a playing track
  to the Psychic Vagina mp3 with `start_ms=40000` now lands at 40.1 s and
  climbs; a track with no start time still starts at 0.

### Round 31 (2026-08-13) — One cast control, not two (v0.5.1)

The cast glyph appeared both under the volume slider and inside the visualizer,
which was redundant. Dropped the volume-slider indicator (`gui/cast_indicator.py`
deleted); the visualizer panel is now the single cast control.

- [x] **The visualizer panel is the indicator** — bigger glyph (20 → 40 px),
  always painted in the theme highlight rather than following the brightness
  mode, and clicking it stops casting instead of cycling on/dim/off (which
  meant nothing with no bars to dim). New `cast_stop_requested` signal.
- [x] **`transport_icon(kind, color, size=…)`** scales the painter instead of
  upscaling a 20px pixmap, so the panel-sized glyph is crisp; `size` joins the
  cache key.
- [x] Collapsed the `cast`/`cast_connected` glyph pair into one — only the
  connected state was ever drawn.

### Round 30 (2026-08-13) — Album art on the cast device (v0.5.0)

The Chromecast is on a TV, so it should show the cover. `play_media` now
carries `thumb=`, which pychromecast folds into `metadata["images"]` — the
field the receiver paints full-screen. Verified against the real device: it
fetches both the audio and the artwork URL from us on every track change.

- [x] **`TrackServer` serves in-memory blobs** — album art lives in the audio
  file's tags, not as a file of its own, so a token now resolves to an
  `_Asset` that is either a path or bytes. Audio and art get **separate
  eviction rings**, so a cover can't push out the previous track's audio while
  a device is still fetching it. Range and HEAD work on both.
- [x] **`support.image_type_for`** sniffs the cover's type from its magic bytes
  rather than trusting the tag — ID3 APIC mimes are routinely wrong or blank,
  and the receiver silently drops an image whose type doesn't match.
- [x] **Best-effort throughout** — no cover, junk where the cover should be, or
  an unreadable file all just play without art rather than failing the load.
- [x] Also sends `albumArtist` and `trackNumber` in the metadata.

### Round 29 (2026-08-13) — Cast to Chromecast (v0.4.0)

The Device menu is now **Connections**, with "Connect to Chromecast…" alongside
the Rabbit sync. Picking a device from the search dialog hands playback to it;
a small cast glyph appears under the volume slider and clicking it disconnects.
See `tests/test_round29.py` (67 tests).

Uses the **media-receiver model**: lintunes serves the original file over the
LAN and the Chromecast decodes it. Bit-exact (no transcode, no double-lossy on
already-lossy files) and the device buffers for itself; the cost is that
lintunes becomes a remote control while connected — no local PCM, so the
visualizer shows the cast glyph instead of bars, and transport actions land
with ~1 s of round trip.

- [x] **`lintunes/cast/`** — `support.py` (format gate, source-address
  selection, range parsing), `server.py` (token-addressed
  `ThreadingHTTPServer` with Range/HEAD), `discovery.py` (`CastBrowser` behind
  Qt signals), `sink.py` (`CastSink`), `controller.py` (session lifecycle +
  its own `SleepInhibitor`).
- [x] **`Player` sink split** — new `PlaybackSink` base with `LocalSink` and
  `CastSink`; `set_sink()` carries track/position/playing-state both ways, so
  connecting and disconnecting pick up mid-song. Play counts and Last.fm
  scrobbles fire identically on both paths.
- [x] **Format handling** — 12,610 MP3 + ~8,750 AAC cast natively; the ~119
  Apple Lossless / AIFF / protected-AAC tracks are skipped with a status-bar
  message rather than stalling the device.
- [x] **Failure handling** — a dropped socket gets a 15 s grace period
  (pychromecast retries on its own, so a Wi-Fi blip heals itself); a real loss,
  a foreign app taking the device, or a network change falls back to local
  playback **still playing**, at the same position. Quitting stops the device
  rather than leaving it fetching from a dead server.
- [x] **New dependency: `pychromecast>=14.0.10`**, imported lazily so the app
  still launches where it isn't installed; `python_requires` raised to >=3.11
  (its floor). The menu item explains the `pip install -e .` when missing.

### Misc (recorded 2026-07-02, moved from TASKS.md during the Round 17 rewrite)

- [x] Confirm Last.fm scrobbling works
- [x] Volume slider between the visualizer and the timeline
- [x] Preferences: per-area color adjustments (background, button
  round-rects, now-playing text + its backing, tracklist stripe gray), each
  with a live black↔white slider
- [x] Visualizer: discrete light-gray-on-light-gray mode
- [x] Cut/copy/paste tracks (Ctrl+X/C/V); paste inserts above the selected
  track, not at the end
- [x] Auto-scroll the track list when dragging a track above/below the
  visible area
- [x] Move data dir to `/run/media/trav/tummult/music/lintunes/` +
  relative track paths (see Round 15)
- [x] Real library import: 21,382 tracks, 462 playlists + 21 folders,
  18 smart playlists (3 kept as snapshot), 5 missing files, 1,324
  case/unicode path fixes (see Round 15)

### Round 16 (2026-07-02) — Live multi-machine sync + conflict alerts

Both machines now reflect each other's changes within a couple seconds, with
genuine conflicts auto-merged (backed up first) and surfaced in an alert. See
`tests/test_round16.py` (9 tests) + the known limitations below.

- [x] **Live external-change reload** — new `lintunes/sync_watcher.py`
  (`QFileSystemWatcher`, 600 ms debounce, re-arms after atomic-rename replaces).
  `LibraryManager.reload_from_disk()` re-reads and **reconciles** disk into memory
  (max play/skip counts, newest edit wins, playlist membership unioned), keeping
  local unsaved edits and object identity so open views stay valid; then refreshes
  the UI without touching the player. **Self-write suppression:** `flush()` records
  each file's `(mtime, size)` in `_own_sigs`; the watcher ignores changes matching
  our own writes so a save never triggers a reload.
- [x] **Auto-merge + backups + summaries** — `storage/conflict_resolver.py` now
  backs up *both* sides into `<data>/.resolved/<timestamp>/{original,incoming}/`
  before merging, returns `list[ConflictSummary]`, and adds `restore_backup()`.
  Conflicts are resolved at startup **and live** (via the watcher).
- [x] **Alert UI** — `gui/conflict_dialog.py` `ConflictSummaryDialog` (scrollable
  summary, Open backup folder, Restore pre-merge backup), shown modeless from a
  status-bar notice so a merge never interrupts playback. Wired in `main_window`
  (`_on_library_reloaded` preserves scroll+selection; `_on_conflict_resolved`).

**Known limitations (v2):** a *simultaneous* conflicting playlist edit unions
membership, so a deletion made on one side while the other edits the same file can
be resurrected (clean, non-simultaneous deletes reload fine) — proper fix is
per-playlist tombstones. No per-change accept/refuse yet (whole-file restore only).

### Round 15 (2026-07-01) — Go live: portable multi-machine paths + final import

Prepared LinTunes to become the canonical library, synced to a second machine via
Syncthing. See `tests/test_round15.py` (10 tests).

- [x] **Portable track paths** (`lintunes/paths.py`) — track locations are stored
  **relative to the data dir** (`to_relative`) and resolved back to absolute on load
  (`to_absolute`), applied only at the `json_storage` boundary (`save_tracks` /
  `load_library`). `Track.location` stays absolute in memory, so the player, tagging,
  and art code are untouched. Because the data dir and the music live inside one
  synced tree and move together, the library now resolves on any machine no matter
  where Syncthing mounts the folder — no per-machine `music_root` config. Absolute
  paths in older `library.json` files still load (back-compat).
- [x] **Final import + go live** — fresh import of the current `iTunes Library.xml`
  into the synced data dir `/run/media/trav/tummult/music/lintunes/` (inside the
  verified "music" Syncthing share), config saved via `--save-config`, preferences
  (UI tuning + Last.fm) carried over from the old `./data`, which is retained as a
  rollback backup. Git remote set to `git.autonomic.zone:2222/trav/lintunes` so the
  second machine can clone.

### Round 14 (2026-06-26) — Smart playlists (Phase 1)

Auto-populating, criteria-driven playlists with full iTunes 12 import. See
`tests/test_round14.py` (27 tests, incl. real captured blobs in
`tests/smart_blobs.json`).

- [x] **Criteria model + evaluator** (`lintunes/smart.py`) — recursive
  `SmartRule`/`SmartGroup`/`SmartLimit`/`SmartCriteria` (JSON round-tripping),
  a shared `FIELD_REGISTRY` (field → Track attr, type, operators) used by both
  evaluator and editor, and `evaluate()` (match all/any, nested groups,
  string/int/duration/rating/date/bool ops, relative "in the last N", and
  limit-by items/time/size with a "selected by" sort).
- [x] **iTunes import** — the binary "Smart Info"/"Smart Criteria" blobs are
  decoded by a **vendored, MIT-licensed parser** (`lintunes/itunes_smart/`,
  from github.com/cvzi/itunes_smartplaylist) and converted to our model by
  `parse_itunes_smart()`. Nested rule groups **parse and evaluate** correctly;
  blobs we can't represent (MediaKind/iCloud/etc.) flag `unsupported` and keep
  the imported track snapshot. Validated against all 14 real smart playlists.
  `loved` is deliberately dropped per user preference.
- [x] **Manager** (`library_manager.py`) — `create_smart_playlist` /
  `set_smart_criteria` (undoable) / `recompute_smart_playlist` /
  `recompute_all_smart`; field-scoped, coalesced live recompute hooked into the
  track-edit/play/skip/add funnels (honours each playlist's `live_update`); a
  no-op equality guard to avoid Syncthing churn; manual add/remove/reorder
  blocked on smart playlists. `main.py` recomputes on load;
  `conflict_resolver.py` takes newest criteria (no track_id union) for smart.
- [x] **GUI** — `❧ ` glyph on smart rows in the sidebar (with a rename-strip
  delegate), distinct context menu (New/Edit Smart Playlist), read-only track
  table for smart playlists, and `SmartPlaylistEditorDialog`
  (`gui/smart_playlist_dialog.py`): per-field rule rows, match all/any, limits,
  live-updating. New Smart Playlist on File menu (Ctrl+Alt+N).

**Phase 2 TODO:** nested-group **editing** UI in the dialog (imported nested
playlists are currently shown read-only with a banner; they still update/play).

### Round 8 (2026-06-19)

All four implemented in Round 8 (2026-06-19); see tests/test_round8.py.

- [x] the ability to right click on any track and within the right-click menu that comes up there's an item that says "show in playlist..." with a right arrow. Hover that and you get a list of all the playlists that that track appears in. Select a playlist and the app jumps to that playlist and highlights the first instance of that song in that playlist.
- [x] ability to edit the ID3 tags of multiple files at once and have it intelligently only modify only the id3 tags that the files share. Say we're editing all songs in an albumb: the song title isn't editable because it isn't the same between the tracks, but the album title would show and the artist. So we could make those changes to all songs at once. _(iTunes-style: differing fields show a "Mixed" placeholder but stay editable; only fields you actually touch are written to all selected tracks.)_
- [x] search, we need search. It only needs to appear in the library view. This should be a text box that takes up a third of that empty horizontal space between the tracks view and the top control panel. It should be a textbox that has in very light gray text that says "search". When you click into it that the "search" text disappears. As soon as you start typing it starts filtering the music. This should be compatible with the browser columns so the browser columns still show genres, artists and albums that match the search term. The search should search all fields for the search term(s). I could see this being really slow having to search all fields of all tracks at every keypress. So we can pause between key-presses if we want. So it's a search but really more like a filter. _(250 ms debounce.)_
- [x] I want support for custom start and end times of tracks like itunes has. We need to be able to import this data from how it's stored in the itunes library and we need to be able to respect it during playback. There should also be fields in the 'get info' screen that allows us to turn custom start/end times of the track on and off and set the value of how far into the song it starts/ends. This is a feature in itunes we're implementing. _(Import was already wired; added Get Info fields + playback seek-to-start/stop-at-stop. Stored in library JSON only — no standard ID3 frame, same as iTunes.)_

- [x] Search box over the library. _(Round 8.)_



### Rounds 1–4 (2026-06-12)

- **Spec 1–14** — full iTunes-replacement baseline:
  - iTunes XML import with Mac→local location remap, play counts/ratings/dates
    preserved, smart + system playlists skipped (`importers/itunes_importer.py`).
  - Syncthing-friendly JSON storage, conflict-file merge on startup
    (`storage/`); data dir lives in the synced music folder.
  - iTunes-style layout: sidebar + track view; genre/artist/album browser
    (Ctrl+B); per-playlist columns/sort/manual order; playlist folders.
  - PyQt6 GUI; playback (mp3/m4a/flac via Qt Multimedia); scrubbing timeline +
    transport buttons; Space/←/→ keys + MPRIS2 media keys.
  - Drag/copy-paste tracks; drop-to-import files/folders; Get Info tag editing
    via mutagen.
- **Round 2** — art paste in Get Info; BPM tap button; guessed ratings dropped
  + migrated; big-art window; 60fps EQ visualizer; cue-don't-play arrows;
  now-playing speaker icon.
- **Round 3** — Preferences (`preferences.py`, Edit ▸ Preferences, Ctrl+,);
  Last.fm scrobbling (`lastfm.py`, full-play-through only); theming
  (`theme.py`: 5 highlight colors, 3 UI scales); shuffle (walk-order);
  sidebar restructure (Library button + bottom art); MPRIS artUrl; painted
  transport glyphs; drag fix; app icon + `install-desktop.sh`.
- **Round 4** — drag chip + glowing drop line; Library button border; 8px BPM
  box; click-to-jump seek slider; vertical browser splitter; fixed-baseline
  visualizer (this also resolved the "vibrating bar bottoms" complaint).

### Round 5 (2026-06-13) — UI polish + status bar + browser normalization

- [x] **Visualizer rounded corners** — rounded gray panel + 1px `palette(mid)`
  border, bars clipped to the rounded shape (`gui/visualizer.py`).
- [x] **BPM button** flat inside its box, matching the transport icons
  (`gui/transport.py`).
- [x] **Bottom status bar** — permanent totals readout `N tracks · DD:HH:MM:SS`
  (trimmed leading units) for the visible track set; reflects browser
  genre/artist/album selection and playlist contents; transient
  import/scrobble/error messages still shown; height scales with UI size
  (`gui/track_table.py` `format_total_time`/`tracks_changed`/`total_stats`,
  `gui/main_window.py`, `theme.py` `status_height`).
- [x] **Browser normalization** — merge case variants (display the
  most-tracks spelling; ties: more capitals, then alphabetical) for genres,
  artists, albums; ignore leading "The" when sorting artists; case-insensitive
  filtering so a canonical entry matches all variants (`gui/library_view.py`).
- [x] **Header bold bug** — `setHighlightSections(False)`; column headers no
  longer bold when playback sets the current cell (`gui/track_table.py`).
- [x] **Library button** — light-gray rounded button, not bold
  (`gui/sidebar.py`).
- [x] **Playlist title** — name only; count/time moved to the status bar
  (`gui/playlist_view.py`).
- [x] Tests: `tests/test_round5.py` (format_total_time, _canonical_values,
  _artist_sort_key).

### 2026-06-18 — top control panel tweaks

- [x] **Faster tap-BPM commit** — the tapped tempo now saves to the track 3s
  after the cursor leaves the button, down from 6s (`gui/transport.py`
  `BpmButton.SAVE_DELAY_MS`).
- [x] **Control panel redesign** — bar height floored at `BAR_HEIGHT` (84px,
  ~10% under the old ~95px) via `setMinimumHeight`, giving the center column
  vertical slack; the title/artist block is centered with **equal** top/bottom
  borders (verified ~11px vs ~10px) using equal `addStretch` above and below,
  while the seek row stays pinned to the bottom so the timeline sits low. Key
  fix: the **bpm box was moved out of the seek row** into its own box on the far
  right (`layout.addWidget(_box(...))`). It was a 37px-tall box that inflated the
  timeline row, floating the 15px slider with a lopsided phantom gap below the
  artist; out of that row the seek row collapses to slider/label height so the
  stretches split evenly. Note: `BAR_HEIGHT` is a *floor* — setting it below the
  natural stacked height (~69px) has no effect. EQ visualizer panel background
  now matches the transport boxes (`palette(alternate-base)` instead of
  `window().darker(115)`). (`gui/transport.py`, `gui/visualizer.py`.) Verified
  by offscreen `QWidget.grab()` render + widget-geometry measurement
  (gnome-screenshot is blocked under Wayland).





- [ ] **Move data dir** to `/run/media/trav/tummult/music/lintunes/` once trav
  confirms the real import looks right (re-run import or copy `./data`, update
  config with `--save-config`).
- [ ] Run the real import on trav's library and eyeball the result (fixture in
  `./itunes-test-library/`).
- [ ] Album art beyond now-playing (grid/album view); embedded tags only
  (decision: no parsing of iTunes' .itc artwork cache).
- [ ] Search box over the library.
- [ ] Background/threaded bulk file import (current import is synchronous).
- [ ] Better duplicate handling on import-by-drop (currently matched by path).
- [ ] Volume control in the transport bar (MPRIS exposes a fixed 1.0).
- [ ] Smart playlists, if ever (skipped at import for now).
- [ ] Wayland edge-drag resize — needs trav's verification; if still bad, try
  `lintunes -platform xcb` and switch the .desktop Exec if that fixes it.