lintunes/CLAUDE.md

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

What this is

LinTunes is an iTunes-replacement music library manager and player for Linux, built with PyQt6 / Qt Multimedia. It imports an iTunes 12 library, stores the library as plain JSON (syncable via Syncthing), and reproduces the iTunes UI (left sidebar + right playlist view, column browser, customizable per-playlist columns). spec.md is the original design brief. Tasks live on the kanban board at ~/Documents/projtracker/projects/lintunes/ (use the tasks skill); the old TASKS.md/tasks-done.md are archived there — don't recreate them.

Commands

pip install -e .                 # install deps (PyQt6, mutagen, numpy, requests)
python3 -m lintunes.main         # run the app straight from the checkout
python3 -m pytest                # run the whole test suite
python3 -m pytest tests/test_round9.py            # one test file
python3 -m pytest tests/test_round9.py::test_name # one test

The app needs a --data-dir; config persists to ~/.config/lintunes/config.json. One-time iTunes import:

lintunes --import-xml "iTunes Library.xml" \
         --music-root "/path/to/iTunes Media" \
         --data-dir /path/to/library-data --save-config

Runtime needs FFmpeg codecs for Qt Multimedia (qt6-qtmultimedia w/ ffmpeg). Tests run headless via the qapp fixture in tests/conftest.py (QT_QPA_PLATFORM=offscreen).

Architecture

Data flows in one direction through three layers: storage (JSON on disk) → model (Library/Track/Playlist dataclasses) → LibraryManager (mutations + persistence) → GUI (Qt widgets that read the manager and connect to its signals).

• lintunes/main.py — CLI entry. --import-xml runs a headless import and exits; otherwise run_gui() resolves Syncthing conflicts, loads the library, builds Preferences/LibraryManager/LastFm/MainWindow, wires MPRIS, and installs the window as a global event filter (for media keys).

• lintunes/models/ — pure dataclasses (track.py, playlist.py, library.py) with to_dict/from_dict round-tripping. PlaylistType is REGULAR | FOLDER | SMART | SYSTEM. Per-playlist PlaylistSettings holds visible columns / sort column / widths. Playlists are identified by an 8-char hex persistent_id (folder containment via parent_persistent_id).

• lintunes/storage/json_storage.py — the library is multiple files in the data dir: library.json (all tracks), library_metadata.json, one playlists/<persistent_id>.json per playlist, and one plays/<machine-id>.json per machine. Writes are atomic (*.json.tmp → rename). storage/conflict_resolver.py merges Syncthing *.sync-conflict-* files on startup: play counts take the max, edited fields take the newest, playlist membership takes the union except where a removal was recorded (Round 44, see tombstones.py). Since Round 39 that union is anchor-based (merge_track_order): a track only one copy has is re-inserted after the nearest track both share, not appended at the tail, so a middle insert stays in the middle. Whose order wins is decided by Playlist.date_modified, not by the file's mtime, which moves for cosmetic reasons. Since Round 43 a stamped copy also beats an unstamped one (a stamp exists only once LinTunes recorded an edit, so that is real evidence); mtime is the fallback only when neither side has ever been edited. Two rules follow: a merge that changes nothing writes nothing (an unconditional write reset the kept file's mtime and biased that fallback a little more every round), and a merge whose result is a union neither copy had stamps date_modified — that content is newer than both, and saying so is what stops two machines trading the same tracks back and forth. library_manager._reconcile_playlist is the same decision on the live-reload path and must read the stamps too; it is reached only for playlists in _dirty_playlist_content (real content edits), never for one that is merely cosmetically dirty from a column drag. Since Round 42 every ConflictSummary carries a level (WARNING / CHANGE / INFO): a merge that only reconciled column widths, or a smart playlist whose rules are byte-identical on both sides, is INFO and must never read as an edit the user made. The dialog (gui/conflict_dialog.py) shows one level and above and opens at the highest level in the batch, so a routine merge never steals focus but a blank window is impossible either. Round 43 made the summaries say something actionable: which copy won and when it was edited, who wrote the copy Syncthing set aside (the 7-char device token in the conflict filename, named via sync_identity.py), and every re-inserted track by Artist — Title and position — six in the window, all of them in what-changed.txt at the top of the backup snapshot. Never label a copy "this machine" from which file holds the plain name: that is Syncthing's choice, and it sets the local copy aside as readily as a remote one.

• lintunes/storage/play_journal.py — why play counts can't conflict. Since Round 38 library.json holds only a base count and each machine owns plays/<machine-id>.json with its own per-track totals; effective count = base + the sum of every journal. Only the owner ever writes its journal, so two machines never touch the same file — and finishing a track no longer rewrites 15 MB, which is what handed Syncthing a conflict once per song. Totals, not an append log, so there is no compaction step to double-count in. PlayJournal.load() must be handed a library whose tracks still carry base counts (the fresh load at startup, the disk copy inside reload_from_disk) — folding an already-folded library promotes the effective count to base. Mirror-image rule in json_storage.save_tracks(): it writes journal.base_fields(tid), never the Track's effective count. Those two places are the whole hazard; tests/test_round38.py pins both.

• lintunes/library_manager.py — LibraryManager(QObject) owns the Library, is the single funnel for all mutations, and persists them debounced (3 s) with per-area dirty tracking (a play-count bump rewrites only library.json; a playlist edit rewrites only that playlist file). User edits go through undo_stack (Ctrl+Z); the internal _apply_*/_set_* helpers do the real mutation + dirty-mark + signal and are reused by undo/redo without recursing. Widgets react to its signals (playlists_changed, playlist_content_changed(pid), track_updated(id), track_fields_edited).

• lintunes/player.py — Player(QObject) walks a queue through a swappable PlaybackSink. Player owns the queue, shuffle walk, per-track start/stop times and the play-count/scrobble bookkeeping; a sink owns only "make this file come out of something, and report where it's up to". LocalSink (the QMediaPlayer/QAudioOutput pipeline, with the QAudioBufferOutput PCM tee that feeds the visualizer) stays in player.py — the Player tests stub Qt Multimedia with patch.multiple(player_module, QMediaPlayer=..., …), so those names must resolve in this module. cast/sink.py::CastSink is the other implementation. set_sink() carries the current track, position and playing-state across a swap and deliberately does not re-emit track_changed (that would double-scrobble the same song). Player is also deliberately context-agnostic: playback context ("library" / "playlist:") is tracked in MainWindow, not the player.

• lintunes/gui/ — main_window.py assembles a top TransportBar over a horizontal QSplitter (SidebarPanel | stacked LibraryView/PlaylistView). The bar's second row (transport.HeaderRow, placed by hand) holds three things owned elsewhere: the sidebar's Library button (SidebarPanel.header, kept edge to edge with the playlist list — list_area, scrollbar included — via track_split), the shown view's header (search box, playlist name — mounted on the content stack's currentChanged, returned to its view when it goes), and the seek row, exactly under the now-playing panel. Everything in it stands on one floor (HeaderRow.BOTTOM above the lists): boxes by their bottom edge, text by its baseline. The row of boxes above floats — equal space before, between and after the controls, with the panel a fixed share of the width. Since the Library button left the sidebar, MainWindow must hand it the first focus, or the playlist tree takes it and opens its first playlist at startup. track_table.py is the shared track grid (drag/drop, copy/paste, drop indicator). playlist_ops.py::add_tracks_with_dup_check is the single funnel for every add-to-playlist path. theme.py applies the palette (highlight colors, UI scales) from prefs.

• lintunes/importers/itunes_importer.py — parses the iTunes XML plist. Remaps Mac file:///Volumes/... paths to the local --music-root with case/Unicode-normalization fuzzy matching (macOS is case-insensitive + NFD vs ext4). Imports user playlists, folders and smart playlists (criteria parsed by smart.parse_itunes_smart; criteria it can't model are kept as a static snapshot — report.smart_unsupported). System playlists are skipped (report.skipped_system). Album art is read live from embedded ID3 tags (tagging.py), never stored in the library JSON.

• lintunes/preferences.py — app settings in <data_dir>/preferences.json (rides the same Syncthing share). Preferences.set(key, value) saves and emits changed; MainWindow._on_prefs_changed re-applies theme/metrics live. Because it is synced, anything machine-specific belongs in config.py's config.json instead (see music_folder.py). now_playing_font has three states — None automatic (best available from theme.NOW_PLAYING_FALLBACKS), "" the app font, or an explicit family. Startup never prompts for it; the row in Preferences is the only place it's chosen.

• lintunes/music_folder.py — where the organized tree lives on this machine. The library stores it three ways (models/library.py): music_folder absolute (what pre-0.10 code reads — kept forever as the shared floor between versions), music_folder_rel relative to the data dir (the portable one, same trick as Track.location), and music_folder_set_at, a stamp so a merge prefers the newest setting rather than the newest file. resolve() tries rel → legacy → the per-machine override in config.json (both music_folder_override and the older music_root that --music-root … --save-config writes — an imported library already knows where its music is on this machine, so don't ask), and every candidate must exist — the override is consulted last so a machine that once needed one isn't pinned to it forever. Two rules that bite: LibraryManager.set_music_folder must call mark_library_settings_dirty() (without it reload_from_disk reverts the change on the next sync tick), and organize_root() can return None, which every caller must handle rather than inventing a relative path — MainWindow._music_import_dir used to fall back to Path("Music"), which resolved against a working directory GNOME's dash doesn't set predictably.

• lintunes/tombstones.py — why a deletion sticks. Two copies with no common ancestor cannot tell "A added this" from "B removed it", which is why every merge was a union — and why a song removed on one machine came back from the other forever. So removals are recorded: Playlist.track_events ({track id: [when, "add"|"remove"]}) and Library.deleted_tracks ({track id: when}, in library_metadata.json). A merge takes the newest event per track across both copies and applies it, so a removal beats a copy that merely still had the song and a later re-add beats the removal; a track with no event still merges as a union. Events are recorded in the same single funnels as everything else — _set_track_ids for playlists, _remove_tracks for the library — and pruned after RETENTION_DAYS (30) at the save boundary, so a machine offline longer than that can resurrect something. Three rules: track ids are never reused (_highest_track_id counts deletions, or a new track would be dropped on sight by the dead id's own tombstone), library_metadata.json is merged before library.json (it carries the record the library merge is filtered against — resolve_conflicts sorts for it), and a merge applying a deletion never touches a music file; it only drops the library entry, and reports at WARNING.

• lintunes/sync_identity.py — turns a conflict filename's 7-char device token into a device name, by reading Syncthing's config.xml and deriving our own device ID from cert.pem (base32 of the SHA-256 of the DER cert). Stdlib only, cached, and every failure path returns None — a machine with no Syncthing must still merge, just without naming anyone.

• lintunes/art_search.py — Download Album Art. Queries both the iTunes Search API and Deezer's public album search (neither needs a key) and merges them through rank_candidates: album match beats artist match, so a right-artist, wrong-album hit never wins. Two sources because neither catalog is complete: iTunes has no copy at all of Digable Planets' Reachin', which Deezer finds on the first query (Round 60). One source failing is not an error while the other answers. Embedding, whether from there or from Get Info, goes through gui/art_ops.embed_artwork: write, mpris.invalidate_artwork, size refresh. Get Info's ArtSquare never stages bytes that don't decode (clipboard_image checks every candidate with QImage.loadFromData), because a clipboard can advertise image/png and hand over nothing. Every paste attempt is logged at INFO (lintunes.gui.info_dialog), so it shows up in the journal.

• lintunes/fingerprint.py — "Identify Track…": Chromaprint's fpcalc CLI (detected with shutil.which, the ffmpeg_available() pattern — a runtime tool, never a pip dep) fingerprints the file, and AcoustID's web API says what it is. Shaped like art_search.py: pure parse/rank helpers first (tested offline against canned JSON), then subprocess/network, then TrackIdentifier(QObject) on a daemon thread emitting a dict carrying either candidates or error. The year rule is the point of the feature: every candidate carries the recording's original year — the earliest release across all its release groups — even the candidate proposing a later compilation as the album, because a 60s song must not sort by the year its CD reissue came out. _releasegroup_sort_key separately ranks a plain studio Album above EP/Single above anything with a Compilation/Live secondary type, so the default proposal is the real album. An AcoustID result's score belongs to the audio, not to any one recording: every recording linked to it carries that score, mis-tags included, and a song whose title another artist also used collects them (Round 52: trav's Dionne Farris "I Know" is linked to Jay-Z's, Marisela's, David Essex's and New Atlantic's). What tells a real link from a stray is sources, the submission count — 475 against 6 and three 1s — so the lookup asks for it and _link_tier sinks anything under a tenth of the strongest link in that result. Hence the key order who, then which take, then which release: stray tier, agreement with the artist the file's own tags name (artist_hint_for), duration bucket, hint overlap, release rank. Artist before duration is the point — Jay-Z's take was 1.5 s closer to the file than Dionne's own, and that used to decide it. gui/identify_dialog.py is passive (the AlbumArtDialog contract — nothing written until accepted); the caller applies result_fields() through LibraryManager.edit_track_fields, which is what buys tag writes, undo and artist/album file relocation for free. A row is pre-checked only where the proposal differs from the current value, so an unchecked field can never quietly blank a tag. The API key is the user's own, in preferences.acoustid (the Last.fm precedent — preferences.json syncs, so it never belongs in git). Audio under ~3 s has no fingerprint at all ("Empty fingerprint"), which is a reported failure, not a crash.

• lintunes/filename_tags.py — the offline half of Identify Track, and the answer to its biggest limitation: AcoustID only knows music somebody submitted, so an underground/SoundCloud rip fingerprints perfectly and matches nothing (verified: "B. Clem — Zuuso" returns zero results from AcoustID, zero from a MusicBrainz text search, zero from iTunes). Its filename, though, says exactly what it is. Pure string work, no network, no Qt: strips yt-dlp's trailing id ([1025657891], -WC7gK2kgyTQ — an 11-char token is only treated as a YouTube id if it carries a digit, an underscore, or repeatedly flipping case, or "Underground" would be eaten), drops (Official Video)-style noise, splits Artist - Title on a spaced hyphen only (so "Jay-Z" and "350-440-DialTone" survive), collapses a doubled uploader, reads a leading 1-04, restores _s→'s, and falls back to the iTunes tree (<root>/Artist/Album/NN Title.ext), ignoring placeholder dirs like "Unknown Artist". fingerprint.candidate_from_filename wraps it as a candidate with source="filename", appended to every lookup and standing alone when there are no matches — the dialog then says where the guess came from instead of quoting a fabricated confidence. The same filename also feeds hint_for(track), which ranks real lookup results: token overlap (words worth double, bare numbers single — "alhambra" identifies a release, "1961" appears in every compilation spanning it), a coarse duration bucket off the recording lengths AcoustID returns (which is what separates a 150 s studio take from a 155 s live one), and a year named in the filename that predates anything the database knows. That last one is not a nicety: MusicBrainz's own first-release-date for "Ahmad Jamal's Alhambra" is 2002, because its three original 1961 pressings are in the database undated — so a second MusicBrainz call would return the same wrong year, and the file's own name is the only place 1961 exists.

• lintunes/url_import.py — File → Import from URL… (Round 49): trav's song shell helper (yt-dlp --extract-audio --audio-format mp3 "$@") run from inside the app. Those flags are passed verbatim; everything else on the command line is plumbing: -P <tempdir>, --print before_dl:LTSTART …, --print after_move:LTFILE %(filepath)s and an LTPROG progress template, so output is read from markers rather than scraped. yt-dlp is a runtime CLI tool (shutil.which, the fpcalc pattern), never a pip dep, and needs ffmpeg for the mp3. No -o: yt-dlp's default Title [id].mp3 is what filename_tags parses. UrlImportWorker (daemon thread, ExportWorker's shape, shares the status-bar progress widgets and so _busy_worker()) downloads into a private mkdtemp, emits downloaded(path) per song, and the GUI imports each one as it lands, through the normal import_files (a copy into the organized tree) and straight into the Identify queue, so song 1's dialog can be up while song 5 downloads. The GUI deletes the temp dir only on finished/failed, which are queued after every downloaded. resolve_target is the rule for "and add to current playlist?": above the selected song in the shown playlist, else the end of the playing playlist, else the end of the shown one, else the checkbox is grayed. Smart/folder/system playlists are never targets. A batch keeps the link's order (position + songs already inserted). With no AcoustID key, TrackIdentifier proposes from the filename alone and never touches fpcalc or the network. Only a URL import reaches that path, since the menu route still insists on setup first. YouTube's "Sign in to confirm you're not a bot" is about the network (song hits it too), and yt-dlp's cure is the browser's cookies: a run that downloads nothing for that reason is retried once with --cookies-from-browser (default_cookies_browser, Firefox first), and a browser that worked is saved as ytdlp_cookies_browser in config.json, not preferences — which browser holds a YouTube login is this machine's business (Round 59).

• lintunes/mpris.py — registers org.mpris.MediaPlayer2.lintunes over D-Bus so the desktop's media keys / now-playing popup control playback. Spacebar and arrow keys are handled locally via MainWindow.eventFilter, which ignores auto-repeat: on Wayland repeats are generated client-side until the compositor delivers the release, and a busy gnome-shell turned one held arrow into 1,676 track skips (Round 56). Every list sent over D-Bus must be a typed QDBusArgument (mpris.string_array) — a plain Python list goes out as av, which GDBus rejects. That was xesam:artist, and the error flood it caused is what kept gnome-shell busy.

• lintunes/trash.py — freedesktop.org Trash spec 1.0, hand-rolled (no new dep). The trash is per-filesystem: music usually lives on a mounted volume, so the file belongs in <topdir>/.Trash-<uid> with a topdir-relative, percent-encoded Path=, not in ~/.local/share/Trash (which would be a cross-device copy the file manager can't "Restore"). The .trashinfo is created with O_EXCL first to claim the name atomically, then the file is renamed in; a failed rename unlinks the info file so there's never a half-trashed pair. Raises TrashError without touching the file, so a caller can treat failure as "not deleted". Only LibraryManager calls it.

• lintunes/device_sync.py — one-way playlist sync to the Rabbit R1 (Device menu). The Rabbit mounts via MTP/gvfs (a FUSE path under /run/user/<uid>/gvfs), not mass storage — so plain file I/O, but never copystat and never trust mtimes (diff by name+size). Sync owns exactly Music/<Playlist Name>/ on the device (creates/overwrites/deletes there, plus an Auxio-importable .m3u); it never deletes outside that folder and only ever reads local library files. Its menu item ("Sync Playlist to Rabbit (Auxio)") was retired in Round 51, once andTunes could play what it syncs; the module stays because find_device and its sanitize_name / track_display / track_filename / build_m3u / CHUNK are imported by both export/exporter.py and andtunes/, so their signatures are load-bearing.

• lintunes/andtunes/ — the desktop half of andTunes, a music player for the Rabbit R1 (Round 47; the app itself lives in andtunes/ at the repo root, R1 measurements in andtunes/DEVICE.md, tasks tagged andtunes on the board). The premise: the app never scans anything. Auxio re-reads Android's MediaStore on every launch, which is the "your songs will show up here" hang — but LinTunes already knows the artist, album and year of every file it just copied, so it writes them into Music/andTunes/library.json and the app parses one file instead of indexing a filesystem. layout.py is the on-device shape (Media/<Artist>/ <Album>/04 Song.mp3 — one copy per song however many playlists hold it — plus Art/, Playlists/, library.json); manifest.py is pure and Qt-free; art.py renders one 480 px JPEG per album (not per track) via QImage — safe off the GUI thread, unlike QPixmap — cached under $XDG_CACHE_HOME/lintunes/andtunes-art and invalidated by the audio file being newer, which is exactly what embedding new art does. sync.py is a third sibling of plan_export/ExportWorker: pure planner, then a daemon thread with KiB progress. Three rules that bite: planning must not render art (a mutagen open per album, and planning runs on the GUI thread — the worker does it, and those bytes are absent from the progress total); the index (m3us then library.json) is written last and after a cancel is rewritten to list only tracks whose files actually landed, so the app never opens a manifest with holes in it; and every delete goes through layout.assert_inside, which refuses anything not strictly inside the andTunes root. That guard is why the old Music/<Playlist>/ folders are structurally unreachable rather than merely un-referenced, and Buttons/ (the user's own menu artwork) and plays/ (written by the app) are skipped by the device scan entirely — sync reads those, it doesn't own them. Which playlists go on the device lives in preferences.json under device_sync (so it rides the Syncthing share and both machines agree); keeping it off the Playlist keeps it out of the conflict-merge machinery, and unticking is the only way a playlist comes off the device. A fully ticked folder is stored as device_sync.folder_ids and follows the folder — playlists added to it later sync too (device_sync_dialog.resolve_sync_playlists is what both the dialog and the sync read). The device's filesystem is case-insensitive, so "RJD2" and "Rjd2" are one folder there and one artist here: since Round 54 the app's Library.group() keys both albumsByKey and artistsByName case-folded (and fetches the artist before the album block, holding it — the raw-case lookup afterwards is what NPE'd on the second track of a two-spelling album and blanked the whole library), and plan_andtunes_sync folds both the collision rule and the device diff, which had been re-copying every such file over MTP every sync. plan.stale still carries the device's own spelling — that is what _delete_stale unlinks by. A gvfs-MTP mount can hold a phantom directory — one it lists happily while the device has no such folder — and every write into it fails EIO forever, because mkdir(exist_ok=True) sees the phantom and does nothing. Only remounting clears it (gio mount -u mtp://… then gio mount). Two rules came out of it (Round 55): a copy that raises OSError costs that song, not the sync (it lands in the unwritable summary list), and the song is then left out of the m3u and library.json — a manifest naming a file that isn't there is worse than a short one, because the app skips to the next track and the user sees the wrong song play. Planning is a worker too (AndTunesPlanWorker): plan_andtunes_sync is pure, but it walks every file on the device, and over MTP that froze the window long enough for GNOME to offer to kill LinTunes mid-sync. Anything after the last album (_write_index, buttons, pruning) must keep emitting progress — it was minutes of silence with the line stuck on Album art 501/501, and _write_index reads Art/ in one listing, never a stat per album. The art pass is held to the same rule (Round 70): it compares each cover against plan.art_sizes, the sizes the planner's scan already read, never a stat per album, and art.album_art_jpeg caches "this album has no art" as a <key>.none marker, so an unchanged library costs the art pass no device I/O and no mutagen opens. Since Round 50 the app exists: andtunes/app/ is plain Java against the Android framework, built by andtunes/build.py (aapt2 → javac → R8 → zipalign → apksigner) — no Gradle, no Kotlin, because platform 33 + build-tools 34 were already on disk and trav didn't want a 1 GB download over cell for tools that make the same APK. --ship copies it to lintunes/android/andTunes.apk with its version in andTunes.json; re-run --ship whenever the app changes, since the committed APK is what the self-updater carries and what install.py installs. andtunes/andtunes.keystore is committed on purpose (both machines must sign identically or adb install -r refuses the update). install.py is Connections → Install andTunes on Rabbit…: adb as a runtime tool, then the all-files + notification grants (a refused grant is not a failed install — the app's first-run screen covers it), or an MTP copy to Download/ with no adb. Sync copies buttons/*.png (rendered by andtunes/tools/make_buttons.py) into the device's Buttons/ only where the file is missing — those names are a contract with the app's Ui.button(), which prefers the device copy. proguard.pro keeps no debug attributes because R8 8.2 NPEs on javac 21's. Round 51 closed the loop. The planner runs every track through export/web_support.conversion_for (Android decodes the browser set), so FairPlay is refused and ALAC/AIFF land as .flac — converted once into $XDG_CACHE_HOME/lintunes/andtunes-flac/<track id>.flac and size-diffed from there on, so a converted song isn't re-copied every sync. And the app keeps plays/andtunes-<install id>.json in the play-journal shape, counted on a natural finish like Player; plays.bring_back folds it into <data_dir>/plays/ with play_journal.merge_totals (per-track max — that file has two homes and both desktops may bring it back) before anything is copied, writing nothing when nothing moved. PlayJournal.load then treats the R1 as one more machine. A wedged gvfs-MTP mount blocks in uninterruptible FUSE waits: timeout can't kill a process stuck on it, and find_device() — called on the GUI thread every time the Connections menu opens, and by the GUI tests — freezes with it. USB re-enumeration (lock/unlock with mtp,adb, an adb install) is what wedged it in Round 51. Recovery: kill the gvfsd-mtp process, then gio mount mtp://<device>/.

• lintunes/export/ — File → Export Playlist… (also on a playlist's right-click menu). A sibling of device_sync, reusing its filename helpers and build_m3u: pure plan_export() first, then ExportWorker on a daemon thread. Two destinations — a folder (files as Artist - Title.ext plus an .m3u) or a web mix (index.html + audios/ + hero image, from templates/; no m3u — it's a folder you upload, not one you open in a player, so plan.m3u_name is "" there). The manifest is written last, so an interrupted export never leaves a page or m3u naming files that aren't there. web_support.py is the format gate, shaped like cast/support.py: deny-by-default on the suffix with the iTunes kind breaking the .m4a tie. Bitrate never triggers a conversion — only unplayability does — and every conversion targets FLAC, so it can't cost a bit; DRM'd tracks are reported, never attempted. ffmpeg is the CLI binary here (not Qt's ffmpeg backend), so it's detected at runtime and its absence is offered as "export without them". The templates ship a ~180-line dependency-free player.js/player.css that replaced audio.js + jQuery (abandoned since 2012; jQuery was only ever glue — audio.js never used it). player-graphics.gif must ship byte-identical: it's an animated GIF whose loading frame is a spinner, not a flat sprite sheet — which is why Round 41 recolors its pale glyphs to black with filter: brightness(0) in CSS rather than editing the file. The one user-chosen color (link/row hover backgrounds + the progress fill) travels as a :root { --accent } custom property declared in index.html, so player.css can read it while staying a verbatim shutil.copyfile — the page is still the only rendered template. exporter.normalize_accent is a hard gate, not politeness: the value lands raw inside a <style> block and string.Template escapes nothing. The accent is not persisted, so an untouched export still renders the original #8c764a. Templates are registered in setup.py via package_data; loaded with importlib.resources so an installed copy finds them.

• lintunes/cassette/ — friend library sharing (Round 63+; the spec is Cassette friend library.md). LinTunes never talks to a friend: it drives the local Syncthing's REST API (syncthing_api.py, key/address from Syncthing's config.xml, overridable in config.json) and Syncthing moves the bytes. Every failure is a SyncthingError(step, detail, kind), because the UI promises never to fail silently. One of trav's machines is the host (host.py: config.json flag + a synced preferences.json record naming it); everything lives in the machine-local ~/.local/share/lintunes/cassette/ (state.json + friends/<token>/ {out,in,cache}), never the synced data dir — Syncthing folders must not nest. A friendship is two folders, lintunes-cassette-<token>-a (inviter → invitee) and -b, each send-only for its writer and receive-only for the reader. Syncthing hides an unknown device's folders (verified on 1.30: a stranger is only a pending device), so while an invite is open the inviter's CassetteService probes a new knock — adds it with nothing shared, reads which folder it offers, completes on the right -b token or removes and remembers it (state.rejected). With no open invite nothing is probed and knocks stay pending, untouched. The paste side can't tell "their computer is off" from "their LinTunes is closed" (Syncthing briefly reports a stranger's connection as up), so it shows one combined status. scripts/cassette_pair.py starts throwaway Syncthings on loopback (no discovery there, hence CassetteService(addresses_for=…)); tests marked syncthing run a real handshake with pytest --syncthing. The service starts from run_gui, never from constructing MainWindow — tests build windows by the dozen and must not reach a real Syncthing. Friend mode (gui/friend_mode.py, entered from the ▾ beside Library) shows a friend's library.json through a second LibraryView over cassette/friend_library.FriendSource — the slice of LibraryManager that view reads, read-only. Their track ids are theirs: the table is set_read_only(True) (no play, no drag, no copy into my playlists, only "lookup on youtube"), and the cassette column is track_table.CASSETTE_FIELD (registered in COLUMN_MAP, deliberately not ALL_COLUMNS), live only where cassette_hooks is set. Nothing is written until Save and Close (service.save_requests → requests.json); any other exit with changes asks "Save changes?". cassette/matching.py is best effort (exact vs fuzzy); cassette/space.py judges the music disk (red) and Syncthing's minDiskFree floor on the cassette disk (orange) separately. Delivery (cassette/delivery.py + gui/cassette_delivery.py) is rebuilt from the folders on every pass, both directions: sender = their requests.json ∩ what I offer now → outbox/<id> ~ <name> (copied to a .part the .stignore hides, then renamed), and anything no longer requested is deleted — a request vanishing is the delivery receipt. Receiver: planning on the GUI thread (it reads the library), copying on DeliveryWorker's thread (file_importer.stage_file — the import split so the copy is off the GUI thread), manager.add_track back on the GUI thread (track_from_file: date added now, no listening history). An exact match already in my library is never imported twice, which is what makes a crash between import and requests-rewrite harmless; a missing library.json prunes nothing. Followed playlists (a UFO in friend mode) are never Playlists of mine: PlaylistTree.followed_provider injects them (mixed alphabetically or in a friend folder, per Friend.layout), and gui/followed_view.py plays them from friends/<token>/cache/. Player queue entries may be string keys (cassette:<token>:<their id>) resolved by Player.track_resolver; a key scrobbles (track_finished) but never calls record_play. Requests are always computed by service._write_requests (cassetted ∪ followed songs not yet cached), so a save never re-asks for what's already in the cache, and a pass prunes cache files no followed playlist uses.

• lintunes/cast/ — Chromecast playback (Connections menu), using the media-receiver model: server.py runs a ThreadingHTTPServer on an ephemeral port for the life of a session and the device fetches the original file itself (bit-exact, no transcode). URLs carry an opaque random token, never a path, so traversal is structurally impossible; Range + HEAD are mandatory (the device seeks by re-requesting ranges and won't report a duration without them). A token resolves to an _Asset that is either a file on disk (audio) or an in-memory blob (album art, which lives in tags rather than as its own file); the two have separate eviction rings so a cover can't push out the previous track's audio. Art is passed as play_media(thumb=…), which pychromecast folds into metadata["images"] — that's what a TV paints full-screen. support.py is the format gate — ALAC, AIFF and protected AAC are refused and Player skips them with a status-bar message. discovery.py wraps CastBrowser; sink.py is the PlaybackSink; controller.py owns the session and its own SleepInhibitor. pychromecast is imported lazily, never at module scope, so the app still launches where the dep isn't installed yet. While casting there is no local PCM, so the visualizer panel doubles as the cast indicator: it shows the cast glyph instead of bars and a click there stops casting (the brightness cycle is suppressed — it means nothing with no bars). That is the only cast control in the transport bar. Position comes from a 500 ms poll of adjusted_current_time (only trusted while PLAYING — it creeps while paused).

Conventions & gotchas

• The Rabbit R1's screen is not what the internet says. Measured: 480 × 640 px, physical density 320, override density 160 — so an app sees a 480 × 640 dp canvas on a 2.88" panel (~278 real ppi). One dp is about half its usual physical size, so andTunes doubles every stock value (rows ≥ 88 dp, text 28–32 sp). Don't "fix" it by changing the device density; trav has it where he wants it. Android 13 / API 33, arm64-v8a. The scroll wheel emits KEY_UP/KEY_DOWN (KEYCODE_DPAD_UP/DOWN).

• Tests are organized as tests/test_roundN.py — each development round adds a new test_roundN.py alongside the topical files (test_models.py, test_itunes_importer.py, etc.). New feature work follows the same pattern.

• Keep Player and track_table manager-free where they already are — cross-cutting data is injected via callbacks/signals (e.g. track_table takes a playlists_for_track callback rather than importing the manager).

• Cosmetic table settings must not look like edits. The last column is stretch-sized, so Qt re-fires sectionResized for it on every viewport width change; track_table._on_section_resized ignores that section, or resizing the window would rewrite the open playlist's JSON (and hand Syncthing a conflict) purely for a width apply_settings overrides on load anyway. Round 42 is the same rule one level down: a live smart playlist's membership is never persisted (Playlist.has_derived_membership gates it in json_storage.save_playlist, which writes track_ids: [] + derived_membership: true) and recompute_smart_playlist passes touch=False to _set_track_ids so it marks nothing dirty and moves no timestamp. Membership is rebuilt from the criteria on every load (recompute_all_smart), so storing it only bought a conflict per song — one per finished track, on the same file, from both machines. The exceptions are live_update=False and unsupported criteria: their track_ids are the content (a snapshot), so they still persist and still count as edits.

• Qt/Wayland gotchas (GNOME/Mutter): QDrag.setPixmap / setDragCursor / QCursor.pos() are unreliable during a drag — gui/drag_ghost.py paints its own child-widget overlay instead. QAudioOutput must not be constructed before a QMainWindow exists (Qt 6.10 deadlock). Some PyQt signal relays need explicit types/lambdas.

• Music files are only touched deliberately: tag edits via tagging.py, and — since Round 18 — artist/album_artist/album edits relocate the file inside LibraryManager.organize_root() (<music_folder>/Music) to keep the tree organized iTunes-style (_maybe_move_file; undoable; files outside the root are never moved; the new path syncs cross-machine via the location newest-wins merge in conflict_resolver). Since Round 33 the only other path is an explicit user delete (LibraryManager.delete_tracks), which moves the file to the desktop trash via trash.py — never unlink, so it stays recoverable. Nothing else may move, rewrite or remove music files. The library JSON is the source of truth for everything else.

• Versioning & self-update: __version__ in lintunes/__init__.py is the single source of truth (setup.py regex-reads it, never imports the package). Claude bumps minor for feature rounds and patch for fix-only rounds as part of each round's final commit; trav decides major bumps. The status-bar version button (gui/version_button.py + lintunes/updater.py) checks origin shortly after launch and every 4 h, and a click runs git pull --ff-only then re-execs the app — pushing master is effectively releasing to the other machines (a new pip dependency still needs a manual pip install -e . there). Every round ends with commit AND push (trav's standing request, 2026-07-03: both machines ride the bleeding edge, sync as often as possible) — so never leave master in a half-working state between commits you push.

• Never develop or verify against trav's real library. It is 21,531 tracks of irreplaceable music and no amount of read-only care makes it the right thing to point a half-finished feature at. scripts/make_dev_library.py builds a synthetic one that has the same shapes — every playlist type (regular, folder, live/non-live/unsupported smart, system, empty, duplicates), six container formats, art on some albums and not others, a play journal, a tombstone, and a deliberate pile of naming edge cases (a collision pair differing only by id, an emoji album, a 208-character title, forbidden characters, a dangling location). Build it with python3 scripts/make_dev_library.py --out dev-library and run against it with --data-dir dev-library/data; it's gitignored, the generator isn't. When a feature needs a shape the fixture lacks, add it to the generator rather than reaching for the real library.

• scripts/ holds one-off maintenance tools (audit_artwork.py, recover_artwork.py, clear_computed_ratings.py) run manually against a data dir; most default to dry-run and need --write to mutate files.

• Not under version control until recently — the *~ files are editor backups (gitignored). data/ and itunes-test-library/ are gitignored (the user's real library + large import fixture).