69ed612077a40f3689e3b54c2ae208ffb89ec824
6432
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 vicrodh
|
e1a11bbc99 |
chore(i18n): the Font row says it takes effect at the next start
The msgid IS the English string, so adding "(requires restart)" to the description re-keys the entry in all seven non-English catalogues. Same wording Interface size two rows above already carries. cc |
||
|
vicrodh
|
750c59034b |
feat(qt): Excel-style multi-select — Shift ranges across every surface
Selection existed but had no keyboard: every click was a single toggle,
so picking 40 tracks meant 40 clicks. Slint and Tauri have had ranges
since 2026-06; this is that port.
NINE surfaces, not the five the track views suggested: Album, Artist,
Playlist, Label, Local Album, plus Library's tracks and albums and Local
Library's tracks and albums. Each carried its own hand-copied `selected`
map and its own `toggleSelected`, so the rule went into
controls/SelectionModel.qml and the maps stayed where they were — the
smallest change that stops it being copied a tenth time.
The rules are Tauri's `applyShiftRange`, unchanged: a plain click
toggles one row without clearing the rest, Shift fills the range from
the anchor ADDITIVELY (so re-dragging a range cannot eat the set) and
leaves the anchor where it is, and Ctrl/Cmd is the same as a plain click
— not a shortcut, but the behaviour both references already have,
because an accumulating click is what "add without disturbing" means.
Qt makes this CHEAPER than Slint, and the difference is worth recording:
Slint had no modifiers at click time and had to read a thread-local set
from a ModifiersChanged handler, with a documented stale-read edge case
when the window lost focus mid-chord. A QML MouseArea delivers
`mouse.modifiers` on the event itself, so the modifier and the click can
never disagree and no such seam exists here.
Three judgement calls, stated because they are not forced:
- Library gets TWO models, one per kind. Its rows are mixed, and one
anchor would let a Shift-click on a track sweep up the albums drawn
between it and the anchor.
- Ranges run over the VISIBLE rows. Local Library's search box is a
view filter, and a range over rows the user cannot see is not the
range they asked for — the same call `select-all` already made.
- The Local Library tree rail keeps plain toggles. Its selection lives
in Rust (QbzLocal.treeToggle*Select), so there is no QML map to hang
an anchor off; teaching the Rust side about an anchor is its own
change, and the file says so where a reader would expect otherwise.
The anchor is an ID, not an index, because every one of these views can
re-sort or filter under a live selection — an index anchor silently
points at a different track the moment the order changes. Slint's
selection.rs made the same call for the same reason.
Verified by driving the app: in Abbey Road, click row 1 then Shift-click
row 5 selects exactly rows 1-5 and leaves 6-8 untouched, with the bar
reading "5 selected"; the same in a playlist, additively over a row that
was already selected.
cc
|
||
|
vicrodh
|
7fc7605887 |
feat(search): the Tracks results use the app's full track row
Search already mounted the shared TrackRow, but had never switched on any of its affordances: no artwork, no artist link, no album column. So the one surface where people are most often hunting for an album gave them no way to reach it except the context menu's "Go to", three clicks deep, while every other track list in the app links straight through. Turning the arms on is most of it. The missing half was in Rust: `search_qt::TrackRow` carried `albumId` but not the album TITLE, and the row draws `item.album` as the column's label and uses `item.albumId` for the click — so without the title the column would render empty and the link would be invisible. `track.album` was already being read one line above for the id. No layout work: TrackCols already reserves the album cell and its gap behind the same `showAlbum` flag, so the widths redistribute themselves. Verified by driving the app: a search for "beatles", the Tracks tab, and a click on "Abbey Road" in a row opens Abbey Road (Super Deluxe Edition). cc |
||
|
vicrodh
|
cf07f10a59 |
fix(settings): make the Font row actually change the font
It shipped doing nothing. Measured on the built binary: picking a face
persisted the pref and changed ZERO of 600600 pixels in the settings
label column. The row was a control that lied.
Two measurements say why, and both were run against this Qt build rather
than reasoned about:
- `ApplicationWindow.font.family` propagates through Qt Quick CONTROLS
only. In a standalone scene with a family set on the window, a
`Label` resolved to it and a sibling `Text` stayed on the
APPLICATION font. This tree is 1082 plain `Text` items against 13
that name a family, so the app's typeface IS the application font.
- The application font is read when an item is CONSTRUCTED. Driving
PySide6 against the same Qt, `QGuiApplication::setFont` updated
`QGuiApplication::font()` and left an already-built `Text` on its old
family.
Together those close the door on changing it live, so the ordering in
main() is the feature: FontPreload.qml registers the bundled faces (a
family does not exist until its file is loaded, and `load()` returns
with its FontLoaders already in the database), the application font is
set from the persisted choice, and only then does Main.qml build the UI.
Swap any two of those and the setting silently does nothing again.
The row now says "(requires restart)", the same wording Interface size
two rows above already uses, in all eight catalogues.
"System" resolves to "" and takes no branch, so anyone who never opens
the row gets exactly the font this app rendered before — verified by
capturing the window on both settings: 0 log lines and an untouched
frame for System, 27065 changed pixels for Montserrat.
NOT ADDRESSED, and worth its own decision: those 1082 Text items have
never used the bundled Inter either. `Main.qml` has always named it, but
that only ever reached the Controls, so the app renders in whatever Qt
picks. Making "System" mean Inter is a one-line change and a visible
one, so it is left alone here.
cc
|
||
|
vicrodh
|
bbe9f25689 |
refactor(settings): Plex gets the same header as Jellyfin and Subsonic
The three media servers sit one under the other and Plex was the odd one out: a small-caps "PLEX" eyebrow with no brand mark in a 64px band, against the 44px SourceIcon + 14px DemiBold title the other two use. SourceIcon already draws the full-colour Plex mark untinted, so this is the same header, the same metrics and the same glyph pipeline. NOT folded into MediaServerSettings.qml: that component is one form twice — address, account, password, connect, sweep — and Plex's body is a different shape, a PIN pairing flow with a server picker and a per-library table. Only the header is the same. One affordance the other two have is deliberately not copied: the "· <server name>" suffix. PlexFields carries no name — pairing stores a url and a token — so the row would be permanently invisible. An empty binding is not parity, it is a dead branch. cc |
||
|
vicrodh
|
002231b46b |
fix(settings): the Library > All select is the same size as every other
`sm: true` made this the ONE select in Settings drawn at the small size, which reads as a rendering bug sitting directly under the full-size Album grouping select. The control-alignment standard has one size for a settings row. cc |
||
|
vicrodh
|
f50c1b5188 |
feat(settings): the library folder table becomes its own page
The folder block — toolbar, add-path row, filter, the row-per-folder
table and the scan progress — is the tallest thing in Settings and it
sat at the TOP of Local Library, pushing Albums view, Library > All,
Maintenance, Danger zone and the three media servers off the first
screen. Behind a Manage row, the whole panel fits one screen again.
The shape is the one Blacklist already uses for its manager, and this
view is deliberately its twin: same 64px summary row, same metrics, same
route-recorded-by-the-caller contract.
Nothing about the table changed. LibraryFolderTable.qml is mounted
verbatim, still driven by the settings document and still acting through
the settingsString action keys.
Two things had to travel with it, because SettingsView used to supply
them and a routed page has no access to that:
- LibFolderEditModal, or the per-folder pencil would open nothing,
silently.
- the refresh on entry. A view reached by Back runs no per-view load,
so it asks for its own, where BlacklistManagerView puts its reload.
Verified in a running window: the route mounts, the seven folders render
with their per-row actions, and Back returns to Local Library with the
section intact.
cc
|
||
|
vicrodh
|
2e659d421c |
chore(i18n): the regrouped Appearance headers and the folder subsection
Five new group headers, the Font row's description, and the two strings the Library folders subsection needs, in all seven non-English catalogues. The English catalogue carries only overrides, so a msgid whose English form IS the string needs no entry there. Checked by switching a running app to Spanish: every new header renders translated. cc |
||
|
vicrodh
|
e90369d931 |
refactor(settings): regroup Appearance around what each row answers
Row wiring is untouched — every block moved verbatim and nothing here
changes what a control does. What changed is the grouping, so the group
order can no longer be read out of AppearanceSettings.slint:
THEME the picker and the rows that exist only for it
TYPOGRAPHY & LANGUAGE Language, Interface size, Font
NAVIGATION was LIBRARY & VISUALS minus the visual rows,
plus the three Purchases/menu rows
SEARCH new: Intelligent Search came out of THEME,
Immersive search out of TYPOGRAPHY & LANGUAGE
PLAYER & VISUALS was PLAYER VIEWS, plus the visual rows
WINDOW WINDOW TITLE + TITLE BAR + WINDOW CONTROLS
SYSTEM INTEGRATION NOTIFICATIONS + SYSTEM TRAY
RENDERER unchanged
Four rows are now ABSENT rather than rendered-and-disabled, because a
control that cannot do anything should not be on screen: Purchases in
title bar (Show Purchases off), Window controls position (system title
bar on), Close to tray and Tray icon variant (tray icon off). Each keeps
its stored value, so turning the parent back on restores the answer
already given.
The My QBZ row loses its fixed logo preview: it renames the hub and
never picked an icon, so the image was decoration in a control column.
Verified in a running window, English and Spanish.
cc
|
||
|
vicrodh
|
3c4c2dae20 |
feat(settings): an app-wide typeface, picked from the fonts already shipped
Settings > Appearance > Typography & Language gains a Font row. The catalogue is the SAME five the lyrics panel offers and the same slugs, because they are the same files: everything is bundled in qml/assets/fonts/, so a choice cannot fail on a machine that lacks the face and looks identical everywhere. "System" resolves to the window default, which is Inter. It applies LIVE, with no restart: the family sits on the ApplicationWindow, which every Text that does not name its own family inherits. The index rides its own qproperty rather than the settings document, because the consumer is the root window and making it parse the whole settingsJson on every republish to read one integer is the wrong trade. Same shape as theme_filter beside it. The loaders are lazy, exactly like the lyrics picker: a family nobody selected is never loaded, and one that has not finished loading falls back to Inter rather than rendering the app in a wrong face for a frame. Only the first label is translated — a typeface name is a proper noun. cc |
||
|
vicrodh
|
58fa77a390 |
feat(qt): fade artwork in as it arrives
Artwork appeared in one step the instant its pixels were ready, which reads as a glitch on a page where covers land a few at a time. It belongs in this file and nowhere else: AlbumCard, PlaylistCard, TrackCard, ArtistCard, SlimCard, LabelCard and RadioCard all mount a RoundedImage, and 81 files in the tree do. Per-card animations would be seven copies that drift, and would still miss the detail headers and the rows. The trigger is `ready`, not the path and not `status`. `ready` is this file's readiness contract, MONOTONE WITHIN ONE SOURCE, which is exactly what a fade needs: the derivative swap sends `status` back to Loading mid-life, and fading again there would flash a cover already on screen. A recycled delegate does re-fade, which is correct — it is a different cover. The Component.onCompleted arm is not belt-and-braces: an already-cached pixmap reaches Image.Ready DURING creation, before onReadyChanged is connected, and without it that cover would sit at opacity 0 forever. Measured against the repaint doctrine rather than argued: at rest 0 presents/s (byte-identical frames over 3 s) during a page load Home 5.7 -> 6.0/s, Library 11.1 -> 12.4/s Qt advances every running animation on one tick and the window presents once per frame however many items are dirty, so fifty covers arriving together cost the same presents as one. OpacityAnimator, not a Behavior, so the fade keeps advancing while the GUI thread is still paying off a mount — which is precisely when covers land. cc |
||
|
vicrodh
|
b970e8f853 |
perf(qt): mount the settings panel in view, not all nine
The nine panels were siblings gated only by `visible:`, so every mount of Settings built the 30 KB Appearance panel, the 19 KB Plex panel and the rest in order to show one of them. Measured before the change, Settings was the slowest route in the app. A Loader with `active:` is the fix that shipped for the Discover tabs and it is the fix here. Measured after: built 326 -> 167 ms, to-idle 392 -> 224 ms. The two overlay modals (LibFolderEditModal, DacWizardModal) are still built unconditionally and are the next item of the same kind; they own their own open state, so gating them is a separate change. cc |
||
|
vicrodh
|
dc8cb1fa32 |
perf(qt): build only the discover rails that fit the viewport
2026-08-17 fixed the four Discover tabs, which were all instantiated because `visible: false` hides an item without stopping QML from building it. This is the same disease one level down and it is what was left: a Repeater builds EVERY delegate in its model, so a ten-section tab built ten rails, each rail's horizontal ListView then created its own delegates during the first layout pass, and the viewport has room for about two and a half. That work is what `to-idle` was made of — the rails nobody could see paying for their cards before the GUI thread could reach the event loop and let a frame out. The seed is one viewport and the rest arrive after the first frame. A rail is ~328px with the Column spacing against a ~740px pane, so three covers the fold; +2 per tick reaches even the twelve-section For You tab inside ~80 ms. The `active &&` on the visibility gate is load-bearing: a Column skips invisible children entirely, but an active:false Loader is visible and 0px tall, which would reserve a spacing slot per pending rail and collapse it as the rail lands. Honest limit: this did NOT turn out to be what fills the blank stretch between the acknowledgement frame and the content. Library has no such ramp and shows the same shape, so that hypothesis is refuted and the remainder is unattributed. cc |
||
|
vicrodh
|
5b274cab57 |
perf(qt): acknowledge a route change on the next presented frame
Measured by driving the real window and diffing the captured frames: a
click on Discover > Home left the window with ZERO pixels changing for
590 ms — the flyout did not even close. The click handler, the flyout
close, the sidebar highlight, the page blank and the whole mount all ran
inside ONE turn of the event loop, so the first frame that could be
presented was the one that already had the finished page in it.
The breakdown matters more than the total, because only one part of it
is what it looks like:
navigate_to (Rust, GUI thread) 7.6 ms
bridge queue hop 1 ms
the QML mount (`built`) 263 ms
post-mount work before a frame ~290 ms <-- `to-idle`
`built` is under half of it. `to-idle` is the number that matches the
freeze, and any future work here should be judged on that one.
So the route is now committed in two phases: arm on the change, build on
the next PRESENTED frame (frameSwapped). Frame N carries the cheap half
— flyout gone, highlight moved, page blanked — and frame N+1 pays for
the mount. Acknowledgement measured at 73-90 ms across five routes and
repeat runs, against 590 ms before.
Two things this had to get right, both caught by capturing frames:
- The backstop timer was a RACE at 32 ms. Render-at-next-vsync
(16.67 ms here, per QSG_INFO=1) plus a QUEUED frameSwapped delivery
lands in ~16-33 ms, so Home acknowledged at +90 ms while Library got
nothing at all on the same build. 250 ms puts the guard outside that
range; it now only covers the hidden-window case it was written for.
- During the armed frame `viewLoader.item` is still the OUTGOING view,
so the incoming route's discriminators were applied to it. The
activeTab Binding wrote "home" onto LibraryView — which has an
activeTab, so the typeof guard passed — emptying its body and
restarting the page fade over the blank. Both Bindings now require
the commit to have happened.
Not asynchronous: incubation is time-sliced and was reverted the day it
was tried; every view is still built synchronously.
cc
|
||
|
vicrodh
|
a11b302e5d |
chore(qt): an env-gated probe for what a navigation costs the GUI thread
The route stopwatch in ContentRouter.qml starts when QML sees the new route, so everything before that — the invokable, the prefs write inside nav_qt::record, the per-view hydrate — was outside every instrument this track has. That is not a small remainder: measured with this probe, a navigation spends single-digit milliseconds there, which is what rules the Rust side OUT as a cause of the dead click and points at the mount. QBZ_QT_NAV_PROBE=1 turns it on. Unset it costs one OnceLock read per navigation and emits nothing, the same discipline the qbz.nav.timing LoggingCategory already follows. cc |
||
|
vicrodh
|
64f0382153 |
chore(i18n): the disc batch's strings, in all eight catalogues
481 entries across en, es, de, fr, pt, ru, ja and nl: the rip wizard and its progress panel, the metadata modal, the per-disc blocks and the track filter, every new toast, and the tooltips. Spanish is Mexican/neutral and was scanned for voseo and Castilian before landing. cc |
||
|
vicrodh
|
2273db9184 |
feat(qt): the disc surfaces — rip wizard, metadata correction, and a pane that
can be read RIP WIZARD, three steps, each answering something the first version got wrong by not asking. What will happen — which disc, how many tracks, and that the output is FLAC, stated rather than implied. The tracks, editable, because a CD-DA carries no titles at all so "named wrong" is the ordinary case and once files are on disk it is a rename job. And what happens afterwards: a ripped album the library cannot see is a folder full of files, so the destination is compared against the registered folders — by path COMPONENTS, not by string prefix, since /music-backup starts with /music and is not inside it — and the right follow-up is offered, naming the folder it would re-scan. "Do nothing" is an explicit choice rather than the silent default. The follow-up runs only on success. Tracks can be deselected. Everything is ticked on arrival and the user goes from all to fewer; a wizard that starts empty makes the common case the one that costs the most clicks. On the Rust side an absent `selected` means yes, so an older form cannot silently rip nothing. A PROGRESS PANEL behind the ripping chip, which is a door rather than a label: it is the only thing on screen during a rip and the two questions it could not answer are the ones that matter. A soft lock says not to eject — soft because nothing here can hold a tray shut, so the honest move is to say it and keep saying it. Per-track state with a bar on the row that is actually moving. Stopping is offered, deletes nothing, and says so; a cancelled job does not jump to 100 %, which is the one lie a progress bar must not tell. CORRECT DISC DETAILS, for a CD and a SACD image and for neither on a folder, which has no identity to write a correction under. The list shows what distinguishes four pressings of one album rather than four identical titles, and flags a track count that disagrees with the disc. Selecting is not applying: the candidate is fetched in full and its track list shown, because that list is the only thing proving a plausible title is the right pressing. Applying renames the live session without renumbering ids — a re-open would orphan a playing track — and writes a user row. Only MusicBrainz re-resolves the cover; Discogs ids are not Cover Art Archive keys and a wrong cover is worse than the old one. The correction can be dropped, because without an escape a bad apply is permanent and that makes people afraid of the button. THE PANE SPLITS BY DISC. A box set scans as one album — measured on a 34-track set whose album_group_key is the box root for every file while the disc number sits in the data unused — so the pane was a flat list 247 rows long. The key carries the disc, unconditionally, because it round-trips through the play-album lookup. Its own client-side filter over what is already rendered, since finding one track meant scrolling past the other 246. EPHEMERAL TRACKS LOSE WHAT CANNOT OUTLIVE THEM. queue_qt has published isEphemeral on every row for a while and the queue panel respected it; the bar never read it. The heart goes inert, the add menu keeps only its queue actions, and the row menu comes back with those three and nothing else. Absent rather than rendered-and-inert. Also: a spinner on Open that blocks a second click onto a drive already being read, held by a counting RAII guard because opening is a relay and the chip must not blink off in the seam; the now-playing card routes a disc to the pane it came from instead of to an album id no catalogue can open; the file pickers use rfd, the platform's own dialog, which the POC-NOTE said was a five-line change once the dependency existed — it existed, Settings had been calling it from this crate for weeks, and on macOS the four Linux choosers do not exist so Open folder and Open SACD image opened nothing at all, in silence; the empty state stands down for the Open pane, which on a machine with no library drew both fully painted; tooltips on every disc control through one hover() helper, since two call sites had already mismatched their key, which does not fail — the bubble simply never goes away. cc |
||
|
vicrodh
|
b69a058bc3 |
feat(rip): a provenance log and the cover, beside the tracks
qbz-rip.log is deliberately NOT an EAC log. An EAC or XLD log is trusted for what it PROVES — test-and-copy, a drive read-offset correction, an AccurateRip cross-check against thousands of other rips of the same disc — and QBZ does none of the three. A file that imitated the format without the method would be worse than no file: it invites a claim this ripper cannot back, and the people who read rip logs are exactly the people who check. So the header says what it is and is not in the first block, not in small print. What remains is true and useful: which disc (DiscID and TOC fingerprint, both recomputable by anyone holding it), which drive, and per track the audio md5 that already lives in the file's own STREAMINFO — verifiable with flac -t without QBZ. Verified end to end: metaflac --show-md5sum prints exactly what the log claims, and flac -t passes on every track. "0 read errors" is a real promise and is stated as one: an unreadable sector ABORTS the rip rather than being written as silence, which is stronger than a burst-mode EAC rip. Where the OS did the reading there is no drive to name, and the log says that instead of printing a volume as though it were hardware. A partial rip declares itself partial: three tracks with no such line read as the whole album. cover.jpg keeps the source's EXTENSION — renaming a PNG to .jpg is how a picture stops opening. Neither sidecar can fail the rip: the audio is the deliverable, and a missing extra is a blemish on a folder of correct files. Five tests, including that the log states all three things it does not do, that the logged digest IS the file's own, and the calendar arithmetic that is the only thing here that could be quietly wrong for years. cc |
||
|
vicrodh
|
b38d6bd867 |
fix(player): attach a cover to queued rows that were enqueued without one
The sibling of patch_plex_quality, for the other thing a row can learn after it was enqueued. A disc carries no artwork — it is fetched, and the fetch outlives the click that started playback — so a CD queued at second two is still holding artwork_url: None when the cover lands at second ten. Every consumer downstream reads the QUEUE row (the now-playing bar, the miniplayer, MPRIS through art_url_for), so patching the session store alone left all of them blank. Rows that already have art are left alone: this fills a gap rather than overwriting a cover somebody else resolved. It answers two questions separately, because they drive different work — any patch makes the queue panel's thumbnails stale, only the current one needs the now-playing stamp re-pushed. cc |
||
|
vicrodh
|
b6deec0aaf |
feat(integrations): search and fetch remote album metadata
The pure converters have been here for a while; what was missing was the thin async layer that puts a client in front of them. It lives here rather than in the frontend for the reason ADR-006 gives: which provider answers, how a query is built and what an empty answer means are domain decisions, and a second frontend must not re-derive them. The Tauri reference is v2_remote_metadata_search / _get_album with its State arguments removed. A provider that is disabled, rate-limited or simply silent answers with an empty result set rather than an error, because "nobody has this record" and "the server said no" look identical to someone staring at a list — and the distinction that does matter rides its own flag. Discogs needs no credentials wired: its client already goes through the proxy. cc |
||
|
vicrodh
|
57ae465668 |
feat(disc): remember a disc after it has been ejected
A disc is the one medium QBZ can play that leaves nothing behind: no path, no row, no file. Everything learned about it was thrown away when the tray opened and re-derived from the network next time. That is fine for names that came from MusicBrainz and not fine for names that came from a human. One DiscID can name several pressings — this album answers with four — so the moment there is a button to pick the right one, or a wizard that lets a title be fixed before it is written, the choice has to outlive the eject. Otherwise correcting a disc is a toy: fix it, take it out, put it back, it is wrong again. A CACHE, not a second source of truth, with one rule that makes it safe: a row the user edited is never overwritten by an automatic lookup. put_auto refuses to touch an edited row and only put_user can replace one, enforced in the store rather than at the call sites so a future third lookup path cannot forget. Identity is the TOC fingerprint: pure geometry, no network, available before anything has been looked up, and identical on both platforms. It names the GEOMETRY rather than the pressing, which is the point — "for this geometry the user chose pressing 2" is the fact worth keeping. Global rather than per-user, because which record is in the drive does not depend on who is logged in. Seven tests, including the one this exists for. disc_identity carries WHICH disc is open for the two features that name the medium rather than the session; nothing there persists. cc |
||
|
vicrodh
|
8d4ed8e959 |
feat(disc): read a CD on macOS, through a reader split by platform
The disc feature was built entirely on Linux in a day, and the result did not
COMPILE on macOS at all: qbz_disc::cdda was cfg-gated to Linux while qbz-rip,
cdda_qt and audible_qt used its names unconditionally. Any macOS build has been
broken since qbz-disc landed.
ONE SET OF NAMES, two implementations that share no code. Linux talks to the
drive through ioctls and reads raw sectors; macOS does not have to, because the
OS mounts the disc and exposes one AIFF per track plus a .TOC.plist. qbz-rip,
audible_qt and cdda_qt needed no change, which is the test of whether the seam
was in the right place. Every other platform compiles and reports "no drive".
VERIFIED against the owner's Tool — Fear Inoculum, the USB drive moved from the
Linux box to the Mac mini:
- the plist's Start Block includes the 150-sector lead-in that the kernel
omits. Subtracting it reproduces the ioctl's numbers exactly, so both
machines compute DiscID BeNBMsD8Du5NO2W61Yk.B2jwwIs- and fingerprint
38bef21351f7fca3 — which is what lets a disc corrected on one be found on
the other;
- all seven tracks read on macOS md5 to exactly what metaflac reports for the
FLACs the Linux path ripped from the same disc hours earlier.
TWO THINGS ONLY MEASUREMENT CAUGHT.
Byte order. "AIFF is big-endian" is true of the format and wrong here: macOS
writes AIFC with compression sowt, which is twos backwards and means the
samples are already little-endian. An unconditional swap produced audio that
passed every cheap statistic — 97 % non-zero, full-scale peak — and matched the
Linux rip nowhere. The COMM chunk is read and the swap is conditional.
Track resolution. audible_qt rebuilds its TocTrack from a CdRef, which carries
a device and a sector range and no track number, so it passes zero. Matching on
the number meant every CD track on macOS answered "could not read the disc"
while ripping, which passes a real number, worked — two paths disagreeing with
only one of them exercised. Resolution is by start_lsn, the address the seam
actually carries, with a regression test on a synthetic volume that fails with
NoDisc under the old rule.
One transient disagreement is recorded rather than smoothed over: reading all
seven tracks back to back once produced a different digest for the last track,
and three further reads matched. The read is not perfectly reproducible on a
marginal region, which is exactly the caveat this approach already states.
cc
|
||
|
vicrodh
|
70defb2e86 |
fix(dsd): the SACD stereo area is byte-interleaved, not block-per-channel
Reported: a SACD image played as white noise with the music distorted behind it, identically in all three DSD modes. That the three agreed was the clue — DoP and native never touch the PCM filter, so the damage had to be upstream of the delivery choice, in how the bits are pulled out of the image. THE LAYOUT WAS DECIDED BACKWARDS. The first measurement converted twelve seconds and looked at where the energy landed: block-per-channel put 23 % above the audible band, byte-interleaved 0.2 %, and the reasoning was that real DSD64 must carry a large ultrasonic component. That argument does not hold for this pipeline. DsdPcmConverter low-passes and decimates to 88.2 kHz, so it REMOVES sigma-delta noise shaping by design — a correct decode has nothing above 24 kHz. The 23 % was aliased garbage from bits read out of order: the symptom was being read as the proof. The ratio does not discriminate either, since scrambled bits and shaped noise both put energy up high. Re-measured with a statistic that can come out differently: decode with the real converter, then ask whether the audible band has the shape of music and whether the two channels are a stereo pair at all. layout spectral flatness L/R correlation BlockPerChannel 0.038 … 0.107 -0.17 … -0.06 ByteInterleaved 0.0036 … 0.0093 +0.24 … +0.48 Tracks 1, 4 and 13 of disc 1 and track 5 of disc 2. A negative correlation between the channels of an orchestral recording is not a subtle hint, and a spectrum ten to twenty times flatter is noise. Two earlier instruments are recorded in the doc as non-discriminating rather than deleted quietly: the energy ratio, and the variance of the raw stream's 64-bit local mean, which answers the same for clean and scrambled bits because the local mean of a byte-level mix of two correlated channels is still roughly the audio. Also lands a real framing bug found on the way, which was NOT the cause: the packet descriptors carry a frame_start bit that the reader ignored, and frames begin 0, 672 or 1344 bytes into a track's payload depending on the track. With byte interleaving an even offset is harmless, which is why it hid; an odd one would swap the channels. FrameSync makes the reader hunt for the boundary, and keeps the unsynced path so a probe can reproduce the broken stream. cc |
||
|
vicrodh
|
cd8f8e6443 |
fix(qt): the CD cover arrives, and it stops blocking the disc from opening
Reported: the CD opened with its names but no artwork. The log said why, because the previous commit taught it to — "no cover art (500 Internal Server Error)" — which is a better failure than the silent one it replaced, and it pointed straight at two separate bugs. WRONG KEY. Cover art was asked for by RELEASE, and a release is one pressing. The owner's Fear Inoculum answers 500 for its release and 200 for its RELEASE GROUP, which is the album as a work and where the canonical art lives. The lookup now asks for `release-groups` too and tries the release first, the group second. WRONG PLACE. The fetch was awaited BEFORE the session was published, so a click produced ten seconds of nothing — measured: the Cover Art Archive took 9.4 s to answer, because it redirects to archive.org. The tracks now land immediately and the art is patched in when it arrives. Patching it in needs `replace_tracks_preserving_ids`: re-running `open_tracks` would renumber every row from the synthetic floor, and the queue may already hold the old ids — a playing track would lose its source mid-song. A late cover for a session that has since been closed or replaced is dropped rather than painted onto whatever is open now. cc |
||
|
vicrodh
|
a922bdd316 |
feat(qt): disc covers, a corner close, and an icon for Rip
Three things the owner asked for after driving the first build. COVER ART. A SACD image carries none, but the file it was downloaded as almost always sits beside one — `cover.jpg` next to the `.iso`, or one level up when the rip is split into "Disc 1"/"Disc 2" folders, which is the shape of the owner's Rheingold. `find_folder_artwork` already knows that walk, so this reuses it rather than growing a second rule about where covers live. CLOSE moves to the pane's top-right corner, for all three media. It used to sit in the action row beside Shuffle — a destructive action one pixel from "play", which is where a hand goes without looking. It is also OUTSIDE the Flickable now: scrolling a 24-track disc must not carry the only way to close the session off the top of the screen. THE RIP ICON is a disc with a folder, drawn as a Lucide-style outline rather than traced from the owner's PNG. The argument is the size it renders at: at 15px a solid, detailed glyph turns to mush while an outline still reads, and the comparison was rendered at both sizes before choosing. Adding it also found a gap in my own tooling. `icon_tint_qt.rs` re-tints from MASTERS at theme-change time, and `masters_cover_every_shipped_glyph` failed the build for a glyph that was baked but had no master — six files written, one line forgotten. `bake_icon.py` now registers the master itself, because a step that has to be remembered is a step that eventually is not. cc |
||
|
vicrodh
|
bbce651d79 |
feat(qt): a Rip button on an open CD, and it asks where to put the album
The button lives on the ephemeral pane's header and appears only for a
PHYSICAL disc — an image is already a file, so offering to rip one would be
offering to copy something the user already has. Whether the session is a disc
is DERIVED from its rows rather than passed in: a flag somebody has to
remember to set is a flag that eventually is not.
The destination is always asked. The app knows several plausible music folders,
which is exactly why it must not pick one — a ripper that decides where your
music goes is a ripper you clean up after.
While a rip runs the button gives way to its progress ("3/7 · 45%") and a
spinner: one control, one state, rather than a button that looks pressable
during a job it cannot start twice. The bar is per-DISC and not per-track,
because a listener watching a 79-minute album wants to know how far the ALBUM
is, and a per-track bar that resets seven times reads like a stall.
Driven end to end on the owner's Fear Inoculum: seven tracks written into
"Tool - Fear Inoculum/", every one decoding clean and seekable, all tagged,
no `.part` left behind.
Four new strings in all eight locales.
cc
|
||
|
vicrodh
|
5d3d51a882 |
feat(rip): rip a CD to tagged FLAC, bit-exact and seekable
New crate `qbz-rip`: CD audio in, tagged FLAC out. Frontend-agnostic — it
knows discs, samples and files, and reports progress through a callback so a
UI can drive it without this crate depending on one.
`flacenc`, pure Rust: no libFLAC to build, nothing extra to bundle into
Flatpak, Snap or AppImage, and macOS gets it for free. `lofty` (already in the
tree) writes the Vorbis comments.
`RipSource` is the portability seam, and it is the only part that differs
between platforms: Linux reads sectors through ioctls, while macOS MOUNTS an
audio CD and presents each track as an AIFF under /Volumes — so there a "read"
is a file read. Everything after the seam is shared.
Two defects were found by ripping a real disc and looking at the result, and
neither would have failed a test:
1. The tags were never written. Tagging happened on the `.flac.part` file,
and lofty identifies a file by its EXTENSION — so it wrote nothing, and
said nothing. Tagging now happens after the rename, with a test that
reads the bytes back and asserts the strings are in them.
2. The files could not be SEEKED. `flac -d --skip=2:00` returned
FLAC__STREAM_DECODER_SEEK_ERROR and `flac -t` warned 3102 times over 3103
frames. The cause is precise: a stream's last frame is short (12 709 620
samples at a 4096 block leaves 3828), flacenc reports that honestly as
min_blocksize 3828 / max 4096 — but in FLAC `min != max` MEANS
variable-blocksize, and a decoder reading one expects SAMPLE numbers in
the frame headers while the frames correctly carry FRAME numbers.
libFLAC's own encoder writes min == max for exactly this reason. Two
bytes of STREAMINFO, and now: zero warnings, seek works.
Verified against the drive, not inferred: 176 400 bytes decoded out of the
FLAC are byte-identical to the same sectors read straight off the disc. The
whole album ripped from the UI — seven tracks, 436 MB, every one decoding
clean, tagged with TITLE/ARTIST/ALBUM/TRACKNUMBER/TRACKTOTAL/DATE/ALBUMARTIST,
and no partial file left behind.
Filenames are sanitised for the strictest filesystem the library might be
copied to, including Windows' reserved DEVICE names and its habit of silently
dropping a trailing dot — which would turn two tracks into one collision.
cc
|
||
|
vicrodh
|
50469ccc57 |
chore: lock the new disc dependencies
sha1 and base64 for the MusicBrainz Disc ID, and the qbz-disc path entries. cc |
||
|
vicrodh
|
452589ddaa |
feat(qt): open a SACD image and play it — the disc names itself
`Open > Open SACD image…` picks a .iso, reads its stereo area and publishes it as the ephemeral session. Nothing lands in library.db. Unlike a CD, a SACD needs no network to be named: the Master TOC carries the album title and artist, and the area TOC a title per track. The owner's disc opens as "Wagner: Das Rheingold", 24 tracks, every one with its German title and "Berliner Philharmoniker, Herbert von Karajan, etc." — all of it read off the image. Routing is one line in `LocalSource::playback` and none in the player: a `sacd:` reference rides the existing DsdFile ticket, because `open_dsd` is the funnel all six player-side DSD constructions already go through. Teaching it there is what makes the PCM, DoP, native and gapless paths inherit disc images for free. Driven end to end on the owner's Rheingold: the tab reads "Wagner: Das Rheingold 24", the badges read HI-RES / DSD64, and pressing play took the DoP route — Player: DSD track — DSD64 via DoP (176400 Hz carrier) [ALSA Direct] DoP hardware configured: 176400Hz, 2ch, S32_LE Audio thread: DoP playback STARTED which is the outcome that matters: the disc's DSD bits reach the DAC without being converted to PCM at all. Six new strings in all eight locales. Unsupported cases are named rather than approximated — a multichannel-only area, a DST-compressed one and a file that is not an image each get their own message. cc |
||
|
vicrodh
|
06405969e9 |
feat(disc): read a SACD image's stereo area, measured against two real discs
Adds an ISO 9660 walk (no mounting, no privileges) and a Scarlet Book parser
for the stereo audio area, plus the `DsdDemuxer` adapter that lets every DSD
delivery the player already has — PCM, DoP, native — play a disc image.
The parser exists because the previous account of this format, written in this
repo, was WRONG: it said the per-sector header was a fixed 8 bytes, derived
from looking at one sector. Every structure below was re-derived by a CENSUS —
3 066 893 sectors across both of the owner's Rheingold discs, zero exceptions —
and each claim is falsifiable rather than asserted:
- byte 0 carries packet_count = (b>>5)&7 and frame_info_count = (b>>2)&7,
so the header is 1 + pc*2 + fic*3 and takes the values 5, 8 or 10;
- packet descriptors are BIG-endian, and the length field is ELEVEN bits,
not the twelve every published layout shows. The first descriptor on both
discs is 0x181B, whose low twelve bits are 2075 — larger than the sector
it lives in. With eleven bits it is 27, and 5 + 27 + 2016 = 2048;
- the proof of the whole decoding is the sum rule
`header + SUM(packet lengths) == 2048`, which the parser CHECKS on every
sector rather than trusting;
- the area is uncompressed, proven from the data and not from a flag: the
audio-packet bytes divide by 9408 (one uncompressed DSD64 stereo frame)
exactly — 350 495 frames on Disc 1, 306 696 on Disc 2. DST is
variable-length; those could not be integers.
Track geometry comes from SACDTRL1/TRL2, tied together by an identity that
holds for 44 of 44 tracks: start_lsn == area_start + start_time * 350. The
ISO 9660 extents mirror SACDTRL1 byte for byte, so the one-sector overlap
between consecutive tracks is the disc's own accounting, not a bug to fix.
The channel layout inside a frame was the last unknown, and three statistical
probes could not settle it — they were measuring the DSD noise floor. What
settled it was physics: converted with the real filter, block-per-channel puts
23 % of its energy above the audible band while byte-interleaving puts 0.2 %
there. A correctly decoded 1-bit stream MUST carry that rising noise floor,
and no filter puts it back once scrambling has folded it away.
Also in this commit, from the same measurements: `2C_TAREA.2CH` on Disc 1 is
recorded in FOUR extents, so `IsoImage::find` REFUSES a multi-extent file
rather than returning its first quarter as if it were the whole thing.
cc
|
||
|
vicrodh
|
d9893b659a |
feat(qt): open the audio CD in the drive and play it
`Open > Open audio CD` reads the disc, builds an ephemeral session and lands
on its tab. Nothing touches library.db, which is the whole point of the
ephemeral path: a disc is content from outside the index that leaves with the
plastic.
It does not invent metadata. CD-DA carries no titles, and the disc measured
here reports its MCN as all zeros, so tracks are "Track N" and the album is
"Audio CD". A DiscID lookup is the obvious next step and is deliberately not
faked: a wrong title is worse than an honest number.
The feeder is the interesting part, and its liveness check took three designs
because the first two were wrong in opposite directions — both caught by
driving the app, neither by any test:
1. `current_track_id() != play_id`: `play_streaming` posts to the audio
thread and returns, so the id is not ours yet and the feeder retires
before reading a sector. Nothing played at all.
2. The same test with a wall-clock grace: a DEADLOCK. That field is stored
only once the audio thread starts playback, which needs the initial
buffer, which is what the feeder is filling. Waiting on it is waiting on
ourselves; the grace expired and the track stopped mid-play.
3. A feeder slot the audio thread plays no part in. A newer disc play claims
it and the older thread retires on its next block. The acknowledgement
path stays for "something else superseded us", but only AFTER the player
confirms our id, and with no timeout — a timeout is what kills a healthy
feeder.
A 16-bit WAV header, not `qbz_dsd`'s: that one is hardcoded to 24-bit, and
reusing it would either lie in the header or promote 16-bit samples to 24.
The shift is arithmetically lossless but it makes the DAC open at 24 bits for
a 16-bit source, which is precisely the silent conversion a bit-perfect path
must not contain. `play_streaming` also does not publish bit depth, so the CD
states 44 100/16 explicitly instead of inheriting the previous track's.
Driven end to end on the owner's disc: seven tracks with the right durations,
CD / 16-bit / 44.1 kHz badges, ALSA Direct opened at 44100 Hz in exclusive
mode, playback past 2:25 with no read errors, and two rapid skips retiring
their feeders in ~160 ms each.
Seven new strings in all eight locales.
cc
|
||
|
vicrodh
|
3ba476b43c |
feat(source): a CD track is a ticket of its own, not a file
`PlaybackTicket::CdTrack { device, start_lsn, sectors }`. No path-shaped
variant fits: a track on a disc is a device plus a sector RANGE, and the bytes
only exist while that medium is in that drive. `File` and `DsdFile` would both
hand it to something that opens it.
`LocalSource::playback` answers it FIRST, before the extension tests, through
`CdRef::is_cd_path` — the encoder's own predicate rather than a second
`starts_with` written out at the call site. That is deliberate: a hand-copied
prefix list is exactly how six bugs of the same shape shipped on 2026-08-20,
and a fold to a valid-looking answer is invisible to every test.
The match in `audible_qt::play_ticket` is exhaustive on purpose, so the new
variant broke the build until somebody decided what a CD means. It now means:
read the sectors and feed them as 44.1 kHz / 16-bit / stereo PCM.
`EphemeralLibraryState::open_tracks` installs a track list that did not come
from scanning a directory. `open_folder` cannot serve a disc — it takes a
`&Path`, rejects anything that is not a real directory, and derives every
field by reading files off a filesystem. A disc has no filesystem to read.
Ids come from the same synthetic range, so every playback caller keeps routing
them without knowing a disc exists.
cc
|
||
|
vicrodh
|
db0999bf6f |
feat(disc): read CD-DA off a real drive, measured before it was written
New crate `qbz-disc`: table of contents and raw audio sectors through the
kernel's own cdrom ioctls. No libcdio — not because libcdio is worse (it is
better at RIPPING than this will ever be) but because this path PLAYS a clean
disc, and for that the kernel interface is enough while a native library would
have to be built into Flatpak, Snap and AppImage. Both need the same --device
permission in a sandbox; only one needs the library shipped.
Every claim below was measured on the owner's USB drive with Tool — Fear
Inoculum BEFORE a line of this crate existed, so the design answers evidence
rather than the other way round:
- the TOC reads back 7 audio tracks, lead-out at LSN 356568, and the track
lengths match the record exactly (10:21, 11:52, 12:44, 13:37, 10:05, 4:48,
15:44 — 79:11 total);
- CDROMREADAUDIO over 20 frames from LSN 4000 returned 47 040 bytes, 99 %
non-zero samples, peak 14559: real audio, not silence;
- the drive hands back LITTLE-endian samples. Neighbouring-sample deltas
average 73.5 read as LE against 20 971 read as BE, a 285x margin, so the
bytes go straight into a little-endian WAV with no swap. That is one
drive, so `looks_byte_swapped` keeps the test available as a diagnostic
instead of an article of faith;
- the disc's MCN is all zeros, which is why identity is a digest over the
track table and not the catalogue number.
What this is NOT is accurate extraction: no overlap synchronisation, no cache
modelling, no jitter verification. On a clean disc that is fine for playback,
and an unreadable sector surfaces as an ERROR rather than a hole full of
zeros — silence that pretends to be audio is the one outcome a bit-perfect
player must never produce.
`/dev/sr0` is nowhere in the code: drives are enumerated, because a box can
have several and /dev/cdrom is a symlink that may point at any of them. Data
tracks of a mixed-mode disc are skipped by their control bits.
`CdRef` is the typed reference (`cdda:/dev/sr0#285735+70833`) with ONE parser,
not prefix tests copied around — the scattered version is a known failure mode
here and cost a whole session on 2026-08-20.
11 tests, several asserting against that real table of contents.
cc
|
||
|
vicrodh
|
0e9721d24b |
refactor(qt): reorder the Local Library header and label the Open menu
Owner's layout: the two maintenance glyphs sit together and the action that
produces new content reads last —
Local Library (settings) (resync) [folder] Open v
Open also stops being a bare glyph. A folder icon on its own reads as "browse
folders" when there is a tab literally called Folders two rows below, and this
control is the one door for every medium the pane can hold: a folder now, a CD
and a SACD image next. It is a 30px / radius-6 chip with icon, label and
chevron — the same small toolbar-control contract this header's selects use.
cc
|
||
|
vicrodh
|
9666ef129e |
feat(qt): give the ephemeral pane an album header, a shuffle and zebra rows
The pane opened on a bare title, a track count and the folder PATH — a filesystem readout for something the user is about to listen to. For the common case this pane IS an album page: one folder, one album, one cover. It now reads like one. The cover is 224px, the size LocalAlbumHeader uses, so an opened folder and an indexed album never present the same record at two different scales; the cell collapses entirely when the session has no art rather than reserving an empty square. The second line trades the path for the total playing time, formatted by the same `total_duration` helper every other Local Library surface uses. Play gains a Shuffle beside it, with the same `(shuffle)` shape `play_album` has, and the Clear stays — it is the only way to close a session, and with it the only way to make the tab go away. The per-block header now draws only for MULTI-album sessions. Adding the big header made it a stutter for single-album ones: the same cover, the same title and the same count, twice on one screen. Track rows get `zebra: true`. `TrackRow` already had the property; this pane was simply the surface that never set it. The shuffle's generator was replaced before it shipped. The first version was a bare xorshift with a comment claiming a folder shuffle "is not a place that needs a good generator" — measured over eight consecutive shuffles of a ten-track album, one track opened FOUR of them. It is splitmix64 now, seeded with a counter as well as the clock so two shuffles inside one clock tick cannot repeat, and there is a test asserting no position is pinned over 2000 runs. Shuffle quality is something the listener sees directly. cc |
||
|
vicrodh
|
45c686fab0 |
fix(qt): take the view to the session you just opened, every time
Reported: opening a folder left the view on whatever tab was already showing. The handler watched `ephemeralActive`, and that flag is ALREADY true when you open a second folder over a first — or when the boot restore opened one before you ever touched the view. So it fired exactly once in the life of the app and then never again, which is precisely the symptom. It now watches an open SEQUENCE that changes on every open. The discriminator was already in the code and did not need inventing: `open()` and `open_path()` pass a runtime to `scan`, `rehydrate()` passes None. Bumping only for the former is what keeps a remembered folder from stealing the tab you actually navigated to at startup. Also restores `onEphemeralActiveChanged`, which I deleted by accident in the label commit: a range replacement swallowed the handler sitting between the two edits. It is the fallback that sends you to Albums when the session closes under you, and without it closing a session left `activeTab` pointing at a tab that no longer exists — a blank content area. It had been smoke-tested BEFORE that edit, so the test was valid when it ran and stale by the time it landed. Verified in the reported scenario: standing on Albums with one session open, opening a different folder switches to the tab, the label changes and the count follows. cc |
||
|
vicrodh
|
ffc2d7d664 |
build(qt): gate on a fifth audit — every icon name must have a baked svg
`QbzIcon` does not draw an SVG by path: it picks a pre-baked, per-tint copy out of `qml/assets/icons/<tint>/`. A name with no bake renders NOTHING. The row keeps its 15px slot, the label sits where it always did, and no test, audit or compiler says a word. That is how three rows of the new Refresh menu shipped iconless through a clean build, 434 green tests and four green audits: `"icon": "server"` looked obvious and has no bake. It was caught by driving the app and LOOKING. The audit checks literal `name:` / `"icon":` assignments against the union of the tint directories, and it is deliberately a floor, not a ceiling: an icon chosen by expression is out of reach for a static pass, and a first draft that also flagged names absent from SOME tints produced ~90 findings, all noise — amber/green/orange/favorite are status tints that hold a handful of glyphs by design. An audit that cries wolf gets ignored, and then it protects nothing. Proven in both directions before landing: with "server" reintroduced it fails and names the file; without it, 101 names across 288 files pass. The tool itself lives in qbz-nix-docs (planning/tooling stays out of the repo). cc |
||
|
vicrodh
|
85ece130e7 |
feat(qt): name the ephemeral tab after what is open, with no verb
"Open", "Now Playing" and "Playing: <album>" were all tried and dropped. A verb is a claim the tab cannot keep: a folder can sit open while something else plays, and then the tab and the now-playing bar name different tracks on the same screen. The content's own name cannot go stale that way, and the tab appears the instant you open something, so nothing has to explain it. The chain lives in Rust so the tab and the nav flyout read ONE value (`localEphemeralLabel`) instead of deriving it twice — the flyout does not parse the ephemeral document and should not start: single album -> its title (a folder IS an album, and so is a disc) otherwise -> the medium's display name, what the pane's header shows neither -> "Media" Elided at 24 CHARACTERS, not bytes: `QbzTabBar` sizes a segment to its text, so an unbounded folder name pushes the whole bar off screen — and slicing a UTF-8 string by byte index panics mid-codepoint on a Japanese album title. There is a test for exactly that. New msgid in all eight locales. Verified on screen: the tab reads "Live 8". cc |
||
|
vicrodh
|
cb4c03ca46 |
feat(qt): one Open menu and one Refresh menu in the Local Library header
The ephemeral pane used to be a third arm of the Folders tab, reachable only
through a folder-open icon buried in the tree rail — one arm of one mode of
one tab. It also HID the folder browser while it was open. Neither survives
the media this pane is about to hold (a CD, a SACD image).
Row 1 of the header now carries two menus, both `CardMenu` (the shared menu
surface, no new component):
- `Open`, always present, is the one door for every medium. Only "Open
folder…" is wired here; the disc entries land with their readers.
- `Refresh` replaces the Plex-only re-sync icon (#573). Rows are APPENDED
per configured source rather than rendered disabled, so a user with no
media servers sees local folders and nothing else. It needed no new Rust:
`plexAvailable`, `mediaHasJellyfin`, `mediaHasSubsonic`, `syncPlex()`,
`mediaSync()` and the settings' own "library-scan" all already existed.
The ephemeral session becomes a tab of its own, present only while a session
is. Two failure modes are handled because the tab can VANISH under the user:
closing the session falls back to Albums instead of leaving `activeTab` on a
tab with no body, and opening one navigates to it — while the pane was an arm
of Folders that was implicit, and with a tab of its own, opening a folder from
Albums would otherwise do nothing visible.
`load_tab_impl` gains an "ephemeral" arm: nothing to load (the session is in
memory), but without the arm every switch to the tab logged "unknown tab",
which is what a real routing bug looks like.
Driven under Xvfb, not inferred: both menus open, the gated rows match the
configured servers, opening lands on the tab, the badges read DSD64, closing
removes the tab and falls back to Albums, and the folder tree is now visible
WITH a session open.
cc
|
||
|
vicrodh
|
a0ed0d752f |
fix(player): cancel the DSD-to-PCM conversion when its track is superseded
The conversion thread relied on `push_chunk` returning `Err` to notice the
track had changed — the comment said so in as many words ("Reader gone (track
changed/stopped) — just stop"). That check could never fire: `push_chunk`
only extends a Vec and fails solely on a poisoned mutex, and `BufferState`
carries no reader-gone flag and no Drop.
So skipping a DSD track left the thread converting to the END of the file,
growing a buffer nothing would ever read. A 60-minute DSD64 album track is
~1.9 GB of 88.2 kHz/24-bit PCM held for nothing, on a box that hard-freezes
under memory pressure.
The fix reuses the contract that already exists for the CMAF feeder:
`register_stream_feeder` with the play generation, plus a cooperative check
once per converted block. Registration happens AFTER the spawn and carries
the generation the play was born under, so a supersede that lands in between
cancels the thread instead of registering it. Like the network feeder's own
cancel, it neither errors nor completes the buffer — the outgoing engine keeps
playing what is already buffered until the new source is installed.
Confirmed in a live session log, not inferred:
[CMAF-STREAM] Cancelling feeder for superseded track 5672
Player: DSD conversion for superseded track 5672 cancelled
cc
|
||
|
vicrodh
|
71f8d08970 |
refactor(qt): hoist the quality badge into one classifier and teach it DSD
`myqbz_builder_qt.rs` carried its own copy of the reference's `quality::badge` plus three helpers, and its own note called hoisting them out a named follow-up that "must not be done in a domain commit". This is that commit: they move VERBATIM into `quality_qt.rs`. The hoist is not tidying. Local Library never had those helpers, so it read a DSD row's nominal 1-bit depth and 2 822 400 Hz bit rate literally: the CD badge, and "1-bit / 2822.4 kHz" where MyQBZ printed DSD64 for the same file. Six surfaces disagreed with a seventh about the same track. `local_rows` gains a `detail_of` to pair with `tier_of`, and all SIX call sites are routed through the pair — the pairing is what stops the two halves of one badge from drifting again. `tier_of` keeps its extra "max" tier on purpose: `LocalLibraryView.qml:435` filters hi-res on that word and `QualityBadge.qml:66` folds it back to "hires". Measured before/after on the same album: CD + "1-bit / 2822.4 kHz" -> hi-res + "DSD64", on the grid, the rows, the album header and the playlists. cc |
||
|
vicrodh
|
6328994c00 |
fix(library): read "DSD" back out of the database as DSD, not Unknown
`LibraryDatabase::parse_format` is the inverse of `AudioFormat`'s Display,
which is what the scanner stores. It had no arm for "DSD", so every DSD row
came back out of the DB as `Unknown`: the album header printed "UNKNOWN" as
its format, the quality badge said CD (depth 1 IS a known depth below 24) and
the detail line read "1-bit / 2822.4 kHz". The now-playing bar was right all
along because it reads the decoder, not the row — which is exactly the clue
that separated the two data sources.
A fold to `Unknown` is a VALID answer, so nothing failed: not the build, not
`cargo check` (it cannot see the match at all), not a single test.
Three sites had the same hole and all three are fixed:
- `database.rs`, the one that bit;
- `local_plex.rs`, same fold for a Plex server serving DSD;
- `media_servers_qt.rs`, worse than the others — its fallback is `Flac`, so
a .dsf from Jellyfin or Navidrome was not losing its format, it was being
mislabelled as lossless PCM.
The guard is a round-trip over EVERY variant rather than a "DSD parses" test:
adding a variant without an arm now fails here instead of shipping the same
silent loss again. Verified against the real rows: format is stored as "DSD",
so this is a READ-side fix and no rescan is needed.
cc
|
||
|
vicrodh
|
a7b7c1b236 |
fix(qt): light the playing row for a downloaded track, in every track list
The now-playing affordance — the accent pill on the row's left edge and the eq bars in the number cell — never appeared for an offline row on the very view it was played from. `TrackRow` asked one question, QbzPlayer.npTrackId === item.id and for a `qobuz_download` row the two sides come from different id spaces: the queue id is the QOBUZ CATALOG id (the offline tier is keyed on it) while every Local Library list draws the row with its `library.db` id. They never matched, so the row sat dark while its own audio played. The reference has a second published id for exactly this and the port never carried it over: `NowPlayingState.local-track-id` (playback.rs:1978-1986). This adds its twin, `QbzPlayer.npLocalTrackId`, and makes the row match either. Published for Offline rows ONLY, and that restriction is the safety of it: `source_item_id_hint` is a shared slot carrying a Plex ALBUM key and a media server's own item id for those sources, so publishing it unconditionally would hand a list a number from another id space and light the wrong row. It stays empty elsewhere, which makes the second test inert there. Scope checked by driving the window rather than reasoned about: the pill and the play glyph land on the right row for local user files, Plex, Jellyfin and Subsonic both before and after this change — offline was the only source whose id diverged. The other three surfaces that ask the same question need no alias: the queue panel and the kiosk album carry queue ids, and the purchases list carries catalog ids. qbz-qt 431/431, 4 QML audits green. cc |
||
|
vicrodh
|
8c3514b899 |
fix(qt): play a downloaded album from Local Library through the offline tier
A CMAF download's `local_tracks.file_path` is the BUNDLE DIRECTORY (`tracks-cmaf/<qobuz_id>/`, holding `init.mp4` and an encrypted `segments.bin`), not a playable container. `LocalSource::playback` handed it back as a `PlaybackTicket::File`, the read failed with EISDIR, and the audible step reported it as audible: file not available at …/tracks-cmaf/266725026 (drive unmounted?) — a message about a drive, for a bundle sitting on the local disk. The bar adopted the track anyway, so the album looked like it was playing and no audio came out. Three funnels reach the audible step and only two excluded an offline row: `play_current_if_local` (auto-advance) and `playback_qt::play_resolved_offline_aware`. The Local Library PLAY funnel did not, nor did its hand-copy in `local_album_actions`. Only qbz-core's offline tier can decrypt the bundle, and the row carries the real Qobuz catalog id precisely so that tier can be asked for it. - `local_playback::play_audible` is now the ONLY copy of the audible step and routes an offline row to the offline tier; `local_album_actions` drops its copy and calls it. - `LocalSource::playback` refuses an offline row with `BadIdShape` instead of emitting a ticket that lies. The test is on the row data, never `is_dir()`: a stat there would block for the mount timeout on the unreachable share the audible step's bounded probe exists to survive. - Tests run the row through the real `local_queue_track`, because the two halves that must agree are its source word and the badge the router reads. Verified by driving the window: album play, track-row play and skip-next all log `[Core] track ... served from OFFLINE cache` and decode at 44.1 kHz / 24-bit; a plain user-file album still plays through the local audible step at 96 kHz / 24-bit. qbz-qt 431/431, qbz-source 91/91. cc |
||
|
vicrodh
|
900517db57 |
fix(qt): size the filter flyout to its content, not to 372px
The Slint original sized a fixed card around THREE source chips. This port now has five — Plex plus the two media servers — and the row ran to the card's edge, with the last chip all but touching the border. The 372px becomes a floor and the width is derived from the widest chip row plus the 16px padding on each side, capped so the card can never run past the left edge. That also survives a UI-scale bump or a language whose labels are longer, neither of which a fixed number can. `implicitWidth` is safe to measure here: a Row sums its children and a non-wrapping Text reports its natural width, so nothing in the chain reads the card width back and there is no binding loop. An invisible chip contributes nothing, so the card is narrower when a server is not configured. cc |
||
|
vicrodh
|
021b5609e1 |
feat(qt): the Albums funnel survives navigation and restarts
The filter worked but forgot itself twice over: leaving Local Library
reset it, and so did closing the app. The first one is not a bug in the
view, it is what this port does — navigating away DESTROYS the view
(project_qt_nav_eager_tabs), so a `property var filter: ({})` cannot
outlive a trip to Discover.
Both follow from one move: the funnel lives on the BRIDGE, mirrored into
the shared ui_prefs.json. The bridge outlives the view, and the file
outlives the process, so one property buys both kinds of persistence.
`setFilter()` is the only writer, so a mutator cannot change the funnel
and forget to persist it, and the view re-seeds from a Connections on
the qproperty rather than only at construction — a republish has to
reach a view that is already open.
The saved funnel is pruned where the source GATES are published, not
somewhere else, so the two can never disagree: a restored `jellyfin`
tick with no Jellyfin configured would match zero rows while the chip
that clears it is hidden by the same gate — an empty grid with a badge
counting a filter the user cannot see. Only the media-server keys are
pruned; local/offline/plex are always meaningful words.
Verified: ticked Jellyfin, went to Discover and back (badge and grid
held), restarted the process (held), pressed Clear (ui_prefs went to
{}). The prune is reasoned, not exercised — both servers are configured
on this box, so no gate is off to test it against.
cc
|
||
|
vicrodh
|
1a2ebcf146 |
fix(qt): re-seed a line edit on the CHANGE, never on the focus loss
`QbzLineEdit` restored the owner's value with
Binding { target: input; property: "text"; value: root.text
when: !input.activeFocus }
and a Binding re-asserts whenever its condition flips, so BLURRING the
field wrote `root.text` back over whatever had been typed.
A SEARCH field never noticed: it fires `edited()` per keystroke, the
owner republishes, and `root.text` is already what the user typed. A
FORM field is the opposite — it reports on `committed()` and the owner
holds the value until Save — so `root.text` is still the stored value,
which for a password is the literal `""` that is deliberately never
prefilled. Every blur erased the field.
Measured in the media-server panel: username and password wiped each
other, so a Subsonic server could not be signed into by hand at all.
The stored state was in fact correct the whole time — `onCommitted`
fires on focus loss and captures the value before the Binding clears
the view — which is why this survived the Jellyfin round: the form
worked, it just did not look like it.
A republish IS a change to `root.text`; a focus loss is not. Reacting
to the change alone keeps the documented case (an external Reset
re-seeds an unfocused field) and drops the destructive one.
Verified in the window: password survives blurring into the username
box; the Tracks search keeps its query after a blur; the × still
collapses the expandable search with no stale query snapping back.
cc
|
||
|
vicrodh
|
4ba4d336d0 |
fix(qt): route every server album key to the local view, not /album/get
`open_album` asks `is_local_feed_id` whether an album id belongs to the local detail view or to the Qobuz catalog, and that gate's whole vocabulary was the literal prefix `"plex:"`. A `jellyfin:<itemId>` key answered NO, went to Qobuz's `/album/get`, 404'd, and the view NAVIGATED AND LANDED EMPTY — not only from the now-playing bar: every caller of that router shares the gate (the queue, "go to album" in a row menu, the Library ALL feed). None of the other clauses caught it either: a Jellyfin item id is 32-char hex, so it carries neither `/` nor `|`. Spelled through `SourceId::from_word` instead of a second prefix list, so the Subsonic brand spellings come along and the next source does not have to remember this site. `qobuz:` stays excluded — it is a legal word and a catalog id. Verified on the bench: playing a Jellyfin track and clicking the album in the bar opens KARAOKE FIRE!! with its 17 tracks and the playing row highlighted. cc |
||
|
vicrodh
|
8b4e0e92b8 |
fix(qt): treat every server source as non-catalog, not just Plex
Three places still spelled "not a Qobuz row" as "local or plex", which made a Jellyfin or Subsonic row fall into the catalog class: - Library ALL feed stamped the album source from the ID PREFIX (`plex:`), so every media-server album came out as "local" and drew the local hard-drive badge. Reads the row's own `source` word now — byte-identical for local and Plex, correct for the rest. The same failure `local_rows::badge_source` had. - TrackRow's `localSourceRow` gated "Add to playlist" and the offline download entry. A Jellyfin row counted as a catalog row, so the menu offered to send a namespaced synthetic id to the Qobuz playlist API, which adds an UNRELATED track. An allowlist, not `!== "qobuz"`: "offline" is an offline-CACHED Qobuz row whose id IS a catalog id. - AlbumCard hid "Block this album" on local/plex only, so a server album offered to blacklist an id the Qobuz catalog never had. `feed_track_to_queue` is taught the words too. Media-server TRACKS do not ride that feed today (only their albums do), so that one is the guard learning the vocabulary before it is needed rather than a live fix — its existing test, which pins that a local id must never resolve as the Qobuz track carrying the same number, now covers all of them. cc |
||
|
vicrodh
|
13e938727c |
feat(qt): merge media-server rows into both local search paths
`media_servers_qt::search_tracks` was written with the rest of the stack and never called — the compiler's dead-code warning was the only thing that said so. Both places that merge Plex now merge the media servers too: the Local Library Tracks tab and the cortinilla's local section. Two asymmetries are deliberate: - Page 0 only, in the Tracks tab, for the same reason the Plex arm is page 0 only: these caches are bounded sets read whole, so re-merging them per page would repeat every remote row once per local page. - BOUNDED in the cortinilla, unlike the Plex arm. The Plex cache is read whole because it always was; a media-server mirror can hold 50k rows and that path runs on every keystroke, so it takes the same limit the caller asked the local query for. Verified on the bench: "totsugeki" in the Tracks tab returns Jellyfin rows first, then the Plex ones. cc |