Two regressions ride together when gapless plays a chain of more than
two tracks:
- The pos/dur snapshot at the top of the audio-thread iteration is
captured BEFORE the gapless transition swap. After the swap
updates current_track_id and duration, the local pos/dur still
point at the outgoing track, and the "approaching end" check a
few lines below fires immediately for the new track with stale
299/299-style values.
- That spurious firing arms gapless_request_armed=true and sets
gapless_ready=true. gapless_request_armed only gets cleared again
on a future transition (which will never happen because the new
track has no prefetch queued) or on engine empty (i.e. when
playback has already stopped). gapless_ready also stays sticky-
true because nothing else clears it once the false-positive fires.
- End result: the new track plays through with the gate stuck
closed, the real "approaching end" check at ~T-10s never fires,
the frontend never gets prompted to call play_next_gapless for
track #N+1, and the audio thread reaches engine empty and stops.
Fix:
- Track whether a transition swap consumed pending in this
iteration via a local transition_consumed_pending bool. Skip the
"approaching end" check while that flag is set — the next
iteration will run with fresh pos/dur for the new track and
fire the trigger correctly.
- Reset gapless_ready=false in both transition swap paths
(mainline and ALSA Direct), mirroring the existing
gapless_request_armed=false reset, so neither flag survives a
transition.
cc
The marker becomes part of the queue state snapshot the frontend
already consumes via syncQueueState(). Single source of truth — no
parallel event channel, no separate store on the frontend.
Refs #356.
cc
Removes all tracks at indices > pivot, preserving the pivot itself.
Returns the count removed. Updates shuffle_order and history to
drop dangling indices. Auto-invalidates the stop-after marker if it
referenced any removed track.
Refs #356.
cc
set_queue, set_queue_with_order, and clear unconditionally drop the
marker (queue replaced/emptied → marked track may not exist anymore).
remove_track and remove_upcoming_track conditionally clear the marker
when the removed track matches it. move_track and add_* are unchanged
— a moved track is still the same track ID, and adding doesn't touch
existing tracks.
Refs #356.
cc
Auto-advance drivers (frontend natural-end handlers) call this with
the just-finished track ID. If it matches the marker, returns true
and clears the marker; the caller pauses instead of advancing.
Otherwise returns false — caller proceeds with normal advance.
Manual skip paths must NOT call this method.
Refs #356.
cc
Add `stop_after_track_id: Option<u64>` to InternalState plus three
methods on QueueManager: `set_stop_after(id)`, `clear_stop_after()`,
`get_stop_after()`. Setting on an ID not present in the queue is a
silent no-op so the marker can never reference a phantom track.
Refs #356.
cc
Qobuz returns a separate `version` field for tracks belonging to remix
albums, reissues, and deluxe editions (e.g. "Player's Ball Mix",
"Nine Inch Noize Version", "Remastered 2024"). The mobile app shows it
parenthesized after the title so remix albums are distinguishable from
originals; qbz only showed the bare title, making remix albums
impossible to navigate (issue #360).
Backend
-------
- Add `version: Option<String>` to qbz_models::Track (the V2 model
consumed by qbz-qobuz/qbz-library) and to api::models::Track (the
legacy struct still used by some V2 command paths).
- Add `version: Option<String>` to qbz_models::QueueTrack so the field
travels through the local queue, persistence, QConnect remote queue,
and frontend snapshots without being lost in conversion.
- Propagate `version` in every Track→QueueTrack converter:
qconnect::model_track_to_core_queue_track,
link_resolver::track_to_queue_track_from_api,
mixtape::enqueue::track_to_queue_track_from_api and the inline
builders. Plex/local builders set version=None (no edition concept
outside Qobuz).
- V2QueueTrack (the wire shape exposed to the frontend) gains the
field with serde default so older clients keep deserializing.
Frontend
--------
- New `formatTrackTitle(track)` helper in src/lib/utils/trackTitle.ts:
returns `title` when version is empty, else `title (version)`.
- Add `version?: string | null` to QobuzTrack, Track (UI), PlaylistTrack,
DisplayTrack, BackendQueueTrack, QueueTrack (UI), and PlayingTrack
so the field flows from the wire to the renderer.
- Propagate `version` through the four buildQueueTrackFrom* builders
in trackActions.ts and through the QobuzAlbum→AlbumDetail adapter.
- Use formatTrackTitle in the high-traffic renderers:
- NowPlayingBar (currentTrack derived in routes/+page.svelte)
- QueuePanel: now-playing label, upcoming-track rows, history rows
- VirtualizedTrackList: default getTrackTitle accessor
- AlbumDetailView: TrackRow title binding
- PlaylistDetailView: TrackRow title binding
- SearchView: popular-track card label and the two track-list
rows (Tracks tab + cross-search "All" view)
Tests
-----
- 196 lib tests pass (no behavior change for the no-version path).
- npm run check: 0 errors.
Follow-up: more views still pass `{track.title}` directly (HomeView,
ArtistDetailView, FavoritesView, ForYouTab, MixtapeCollectionDetailView,
LocalLibraryView, the various Suggest/Top/Label views, the immersive
panels, the miniplayer surface, and the Track*Modal stack). They all
render UI Track-shaped objects that now carry version, so each is a
mechanical "import formatTrackTitle + replace {track.title} with
{formatTrackTitle(track)}". Doing them in a follow-up commit to keep
this one reviewable.
cc
Path C: legacy CPAL output-sink enumeration was inlined directly in
commands/playback.rs (cfg-gated Linux + non-Linux variants), with
no equivalent in any domain crate. Extract a domain function
`qbz_audio::output_sinks::list_output_sinks` that returns the same
{name, description, volume, is_default} shape (mirrored as the new
public `OutputSinkInfo` struct) for both Linux and non-Linux
platforms, preserving the original logging cadence and the rule
that name == CPAL device name (so saved IDs reopen correctly).
Add v2_get_pipewire_sinks in commands_v2/audio.rs that calls into
qbz_audio directly — no `crate::commands::*` delegation. Updates the
two frontend call sites (AudioOutputBadges.loadStatus and
SettingsView.loadAudioDevices). Legacy command in
commands/playback.rs is preserved untouched; the audio-protected
files (pipewire_backend.rs, audio_settings.rs, player init_device)
are not modified.
cc
Path C: legacy command called client.get_releases_grid for the
artist detail view's release-type pagination grid. No existing
v2 equivalent, so add v2_get_releases_grid via QbzCore ->
QobuzClient::get_releases_grid directly.
cc
Path C: legacy command called client.get_artist_tracks (the
/artist/get?extra=tracks path) and returned a TracksContainer.
No existing v2 equivalent, so add v2_get_artist_tracks via
QbzCore -> QobuzClient::get_artist_tracks directly.
cc
Path C: legacy command called client.get_artist_detail with the
hard-coded mobile defaults of limit=1000, offset=0 to populate the
suggestions panel's playlists and tracks_appears_on. No close v2
equivalent existed (v2_get_artist_with_albums uses
extra=albums only), so add v2_get_artist_detail that goes through
QbzCore -> QobuzClient::get_artist_detail directly.
cc
Path C: legacy command projected `Artist.albums` from
client.get_artist_with_pagination(with_albums=true). The existing
v2_get_artist_with_albums returns the full Artist envelope, so
add a dedicated v2_get_artist_albums in QbzCore that performs the
same projection and exposes only ArtistAlbums to match what the
two callsites destructure.
cc
set_queue and set_queue_with_order unconditionally cleared history, which
wiped legitimate plays whenever QConnect echoed a queue version bump
(reorder, shuffle toggle, peer-driven snapshot) without changing track
identity. That is the missing-tracks half of issue #316.
Instead, remap history entries by track id: each pre-existing index is
resolved to its track id via the old tracks list, then looked up in the
new tracks list. Entries whose track id is no longer present are dropped.
When the new queue has zero overlap with the old, history clears
naturally; when the queue is a pure reorder, history survives intact.
Six unit tests cover pure reorder, additions, partial removals,
disjoint replacement, and verify the remapped indices (not just rendered
ids) point at the right new tracks.
cc
The MSG_TYPE_ERROR (cloud_type=9) arm previously logged only the payload
byte count, so when Qobuz cloud rejected a session (zombie session,
conflicting device, expired JWT, ...) we had no signal beyond an opaque
"bytes=13" TransportError. That hid the actual cause of the 2s flicker
loop seen after the app sat minimized for 1-2 hours (issue #358).
The qws.proto ErrorMessage (messageTypeId=9) carries:
uint32 msg_id = 1
uint64 msg_date = 2
uint32 code = 3
string descr = 4
Decode it via a local QwsErrorMessage prost struct, log a warn line with
the decoded code+descr, and emit a new TransportEvent::CloudError so
qconnect-app and qconnect_service can react. qconnect_service forwards
it as a "qconnect:cloud_error" diagnostic (level=warning) and logs it.
qconnect-app treats it as a no-op forwarder for now, matching the
existing pattern for other transport-only events. Decode failures fall
back to the previous TransportError path under a distinct stage name so
they are still visible.
Adds a tokio test that builds a real MSG_TYPE_ERROR frame and asserts
the transport emits CloudError (not the legacy TransportError).
Refs #358
cc
The native WS transport reset its reconnect counters as soon as the WS
upgrade succeeded. Qobuz cloud accepts the WS connection well before the
JOIN_SESSION exchange and rejects unhealthy sessions with MSG_TYPE_ERROR
right after, so the counter reset every cycle and the loop hammered the
endpoint at base backoff (~2s) forever (issue #358).
Move the counter reset to the moment the cloud emits a
MESSAGE_TYPE_SRVR_CTRL_SESSION_STATE event (the actual proof of a healthy
session-level join), and add a configurable maximum-attempts cap that
makes the transport stop and emit MaxReconnectAttemptsExceeded instead
of looping indefinitely.
- Add SessionEstablished and MaxReconnectAttemptsExceeded transport events.
- Add reconnect_max_attempts to WsTransportConfig (default Some(10)).
- handle_incoming_binary now returns whether SESSION_STATE was decoded.
- Reconnect helper returns a ReconnectOutcome enum (Continue/Shutdown/
Exhausted) instead of a bare bool.
- qconnect_service.rs logs the new events and emits a diagnostic when
the cap is exceeded so the higher layer can react (#358-fix-3 will
surface it in the UI).
- Unit tests cover the cap behavior and the unbounded fallback.
Refs #358
cc
Memory mitigations for issue #331 (Pi 3B / 1 GB hosts):
- qbz-core::system_capabilities reads /proc/meminfo at startup and
derives a MemoryProfile (Normal vs LowMemory). Cached in OnceLock.
- V2 prefetch (commands_v2/playback.rs) caps prefetch_count and
max_concurrent_prefetch from the profile, downgrades HiRes to
Lossless when allow_hires_prefetch is false.
- StreamingConfig::from_speed_mbps clamps the dynamic initial
buffer to a process-wide cap configured from the profile (256 KB
on LowMemory vs 2 MB historical max).
- AudioCache L1 cap also scales (50 MB on LowMemory vs 400 MB).
- Tokio watchdog spawned on LowMemory hosts polls MemAvailable
every 10 s; flushes audio caches when below 5 % to break the
swap-thrash loop codehd7 reported.
Includes the rodio 0.22 NonZero test fix (also in the bugfix
merge above) so the branch validates standalone.
cc
rodio 0.22 tightened SamplesBuffer::new to require NonZero<u16> for
channels and NonZero<u32> for sample_rate, but the visualizer test
fixtures still passed bare integer literals — so the qbz-audio test
binary stopped building. Wrap both call sites in NonZero::new(...)
.unwrap() so cargo test -p qbz-audio compiles again.
Pure test-only change; runtime visualizer code was already migrated.
cc
Add audio_cache_l1_max_bytes to MemoryProfile and wire it into
AppState's AudioCache constructor. Normal hosts keep the historical
400 MB cap; LowMemory hosts drop to 50 MB.
Without this, a Pi 3B (1 GB total) starts with the L1 cache cap set
at ~40 % of physical RAM. Even with the Feature #3 prefetch caps
already in place, the runtime watchdog from the previous commit
ends up firing more often than necessary because nothing prevents
a single L1 fill cycle from claiming 400 MB. Capping at 50 MB caps
how much the cache can grow before either: (a) eviction picks up
naturally, or (b) the watchdog steps in if the rest of the system
is also under pressure.
Pure refactor in lib.rs — replaces a hard-coded 400 * 1024 * 1024
with a profile field read. The default-constructed AudioCache
fallback (when disk-spillover init fails) keeps its own crate
default; no need to thread the profile there since the failure
path is rare.
Two tests added: a presence-bound assertion in the existing Pi 3B
case, and an explicit comparison that LowMemory's cap is strictly
smaller than Normal's.
cc
Extend qbz-core's system_capabilities with a parse_meminfo_available_kb
helper plus a small MemoryPressure value object that classifies the
host's current available memory against thresholds derived from
MemoryProfile. The watchdog (src-tauri side, next commit) polls this
to decide when to evict caches.
Thresholds intentionally simple for v1: is_low triggers under 15 %
available, is_critical under 5 %. Both are strict-inequality so the
exact-percent boundaries don't flap.
The pure pressure_from_figures(avail_kb, total_kb) factors out the
math from the /proc read so threshold behavior is tested without
touching the filesystem. Refactors the existing
parse_meminfo_total_kb to share a parse_meminfo_field_kb helper with
the new available-memory parser.
Adds 9 tests covering the parser, the threshold boundaries, the zero-
total divide-safety guard, and the codehd7 issue #331 scenario
(Pi 3B, ~25 MB available out of 938 MB → critical).
cc
StreamingConfig::from_speed_mbps inflates the initial buffer to 2 MB
on slow connections (< 1 MB/s) to absorb network jitter. On a healthy
desktop that's fine, but on a memory-constrained host the slow link
is itself a symptom: when QBZ on a Pi 3B starts allocating ~300 MB
of Hi-Res prefetch the kernel swaps, networking stalls, the speed
detector reports < 1 MB/s, and the buffer code reacts by allocating
ANOTHER 2 MB — exactly the wrong direction.
Add a process-wide AtomicUsize cap (defaults to usize::MAX, i.e.
no-op) plus a small public set_max_initial_buffer_bytes setter.
Refactor from_speed_mbps to clamp through the cap; extract the
speed-to-bytes ladder into a pure raw_initial_buffer_for_speed
helper plus a from_speed_mbps_with_cap variant that exposes the
clamping for unit tests without touching global state.
src-tauri/lib.rs's run() wires the cap into qbz-player from
qbz-core's MemoryProfile right after logging the profile. Effective
on Pi 3B (issue #331): all StreamingConfig::from_speed_mbps results
pin to 256 KB regardless of detected speed.
Re-export max_initial_buffer_bytes / set_max_initial_buffer_bytes
from qbz_player::player so external callers don't need to reach
into the private streaming_source module.
Adds 5 unit tests: ladder behavior, pass-through when cap is loose,
clamp at the LowMemory cap (the issue #331 case), no-op at the
Normal cap, and that max_buffer_bytes stays unchanged.
cc
New module in qbz-core that probes /proc/meminfo at startup and
classifies the host into Normal (>= 2 GB RAM) or LowMemory (< 2 GB)
buckets, then derives runtime caps for memory-sensitive subsystems:
prefetch_count, max_initial_buffer_bytes, max_concurrent_prefetch,
allow_hires_prefetch.
Detection is split into a pure parse_meminfo_total_kb +
detect_profile_from_meminfo pair (testable with synthetic input)
and a thin detect_profile wrapper that reads the file. The
process-wide profile is cached in a OnceLock and logged once at
first access, so subsequent callers pay zero filesystem cost.
The Normal-fallback path covers macOS, Windows, and any Linux where
/proc/meminfo is missing or unparseable — we never accidentally
throttle a system whose memory we couldn't measure.
This commit only ships the module; wiring into the prefetch loop
and streaming buffer follows in the next commits.
Adds 10 unit tests covering the parser, the threshold boundary
(exactly 2 GB → Normal, just under → LowMemory), the Pi 3B and
Pi Zero 2W cases that motivated this work (#331), and the
unparseable-input fallback.
cc
The hw:CARD=…,DEV=… fallback added in 1.2.8 (commit 927fabbd7) only
fired when the helper chain
extract_card_name_from_device(device_id)
.and_then(|card| get_hw_supported_rates(&card))
.is_some()
returned Some — but get_hw_supported_rates parses
/proc/asound/cardN/stream0, which is only emitted by the USB-audio
driver. I2S, PCI and built-in cards (HifiBerry HATs, intel-hda, etc.)
don't have a stream0 file at all, so the gate evaluated to false for
the very devices that needed the fallback the most. The reporter's
HifiBerry Digi2 Pro on Raspberry Pi OS hit this exactly: 1.2.8's
ALSA Direct path logged "Looking for device: iec958:CARD=…", failed
the lookup, and dropped straight to the proc_found=false error
branch without ever attempting hw:CARD=sndrpihifiberry,DEV=0.
Extract a small is_card_present_in_proc helper that uses
find_card_number_by_name (which reads /proc/asound/cards — present
for every registered card regardless of bus) and use it for both
gate checks: the fallback trigger and the proc_found error message
selector. get_hw_supported_rates keeps its three legitimate uses
(actual rate validation in create_output_stream, and the two public
device_supports_sample_rate / get_device_supported_rates queries).
Adds 8 unit tests covering build_hw_fallback_id, the alias-prefix
branches of extract_card_name_from_device, the short-circuit cases
of is_card_present_in_proc, and the existing is_known_pcm_id filter.
The /proc-touching branches stay covered by hardware testing on the
reporter's Pi when v1.2.9-rc ships.
cc
rodio 0.22 tightened SamplesBuffer::new to require NonZero<u16> for
channels and NonZero<u32> for sample_rate, but the visualizer test
fixtures still passed bare integer literals — so the qbz-audio test
binary stopped building. Wrap both call sites in NonZero::new(...)
.unwrap() so cargo test -p qbz-audio compiles again.
Pure test-only change; runtime visualizer code was already migrated.
cc
build_cpal_device_map iterated every PCM that cpal's ALSA host exposes
(dmix:, route:, surround51:, pulse, null, …) but only five name shapes
are ever looked up downstream: default, sysdefault:CARD=*, and
{front,hdmi,iec958}:CARD=*,DEV=*. Dropping the rest avoids holding
Device handles we never query and, combined with the new error
handler, removes another source of spurious libasound probes on
systems where PipeWire owns the hardware exclusively.
cc
libasound's default error handler prints directly to stderr. During
device enumeration probes, PCMs that wrap dmix or surround routes emit
benign errors ("unable to open slave", "no matching channel map") that
cluttered the app log without indicating a real problem.
Install a process-wide snd_lib_error_set_handler shim from
AudioBackendFactory::create_backend (idempotent via std::sync::Once)
that forwards the file/line/function/err/fmt tuple to log::debug. The
messages stay available with RUST_LOG=debug and disappear during
normal runs.
Adds alsa-sys 0.3 as a direct Linux-only dependency on qbz-audio
(previously transitive via alsa/cpal). The handler is declared
non-variadic and transmuted into libasound's variadic function pointer;
ignoring the unused varargs is ABI-compatible on every platform we
support.
cc
Fixes GHSA-cq8v-f236-94qc (low: rand unsound with custom logger using
rand::rng()). Transitively bumped across both src-tauri and crates
workspaces via cargo update.
cc
Adds an is_network_mount flag to local_tracks. Populated by reading
/proc/mounts (falling back to /run/host/proc/mounts for Flatpak
sandboxes) and matching the file path's longest-prefix mount against
a list of network filesystems — nfs/nfs4, cifs/smb/smb3, fuse.sshfs,
fuse.rclone, fuse.gvfs, davfs/webdav, 9p, ceph, glusterfs, afs, afp.
Motivation: the earlier offline-awareness commit used a frontend
heuristic that matched /mnt, /media, /run/media and Windows UNC. That
catches the classic cases but misses the common sandbox case — a user
on Flathub or Snap mounts their NAS via GVFS at /run/user/1000/gvfs/…
or bind-mounts it into /home/user/music, and neither of those
triggers the frontend check. The backend sees the mount type
directly, so flagging the row at index time gives the UI ground truth.
Changes:
* new crates/qbz-library/src/mount_info.rs — is_network_path(&Path)
helper with /proc/mounts parsing, longest-prefix mount matching,
and a NETWORK_FS_PREFIXES list. Guarded with cfg(target_os =
"linux"); stubs return false on macOS / Windows (frontend keeps
its string-match heuristic there).
* LocalTrack gains is_network_mount: bool (serialized camelCase).
* local_tracks table: new is_network_mount INTEGER NOT NULL DEFAULT
0 column, both in the initial CREATE TABLE and a migration for
existing DBs.
* insert_track calls mount_info::is_network_path(&track.file_path)
and writes the flag. Qobuz cached-download inserts rely on the
column default (always 0) since those land inside the app's own
data dir.
* TRACK_COLUMNS + row_to_track pick up the new column. The two
inline LocalTrack builders in get_playlist_local_tracks and
get_playlist_local_tracks_with_position are updated the same way,
plus the playlist_position index shifts by one.
cc
First half of the Plex-tracks-in-playlists fix. Adds a dedicated
playlist_plex_tracks table alongside the existing playlist_local_tracks
so Plex content (TEXT rating key, owned by a remote server) doesn't
collide with the i64 filesystem id used by local_tracks. No foreign
key to plex_cache_tracks — the cache can be purged independently and
the user's intent should survive.
Database methods added:
* add_plex_track_to_playlist(playlist_id, rating_key, position)
* remove_plex_track_from_playlist(playlist_id, rating_key)
* get_playlist_plex_tracks_with_position(playlist_id) ->
Vec<(rating_key, position)>
* get_playlist_plex_track_count(playlist_id) -> u32
get_all_playlist_local_track_counts now merges plex counts into the
same HashMap so the sidebar's hasLocalContent signal stays a single
number and covers Plex-populated playlists without a second round
trip from the frontend.
cc
Adds InMemorySource — a Symphonia FormatReader+Decoder backed by an
in-memory Cursor — and wires it into the cached branch of the Seek
handler so FLAC Hi-Res and MP3 seeks on LRU-cached / local-library /
offline-cached tracks jump via seek table instead of decoding every
sample from byte 0. Matches the streaming path's behavior, eliminates
the CPU spike during long seeks that was producing audible stuttering
after the streaming seek fix landed.
Falls back to the previous decode_with_fallback + skip_duration path
when Symphonia can't probe the format (rodio-only MP4/AAC container)
or when the native seek itself fails, so nothing regresses for those
formats.
Part of #335.
cc
Replaces skip_duration's decode-every-sample-from-zero loop with
FormatReader::seek(SeekMode::Accurate, SeekTo::Time) on a fresh
IncrementalStreamingSource. For FLAC this jumps via the seek table to
the nearest seek point, then decodes forward to the exact sample —
instead of grinding through millions of samples under the buffered
source's mutex (the cause of post-seek stuttering).
Added IncrementalStreamingSource::seek_to(Duration) which also resets
the decoder, clears the sample queue, and rearms the finished flag so
the source is cleanly re-primed for the iterator.
Non-streaming seeks (cache, offline-cache, local library) still use
skip_duration — they hit in-memory bytes with no lock contention, so
the linear decode is effectively free and there's no reason to change
the path.
Part of #335.
cc
Relaxes the seek gate added in 2dc1ee9e so seeks that fall inside the
already-downloaded portion of a streaming track succeed instead of being
rejected wholesale. The cutoff is approximated from download fraction ×
track duration with a 10% safety margin (0.90) to cover FLAC/VBR byte
density variance; exact for CBR.
Seeks past the watermark still reject cleanly with a warning log — they
would block the audio thread since skip_duration reads samples
sequentially. Cache, offline-cache, and local-library seeks are
untouched (they don't hit the streaming branch).
Part of #335.
cc
Tightens the streaming-seek handler to the simpler contract signed off
by the user: seek works after a streaming track finishes downloading
(buffered_source.is_complete()), but is rejected cleanly with a warning
log while the download is still in progress. Avoids skip_duration
blocking the audio thread on past-watermark seeks without adding
watermark-tracking complexity.
Cache, offline-cache, and local-library seeks are unaffected — they
reach this handler with current_audio_data Some and skip the streaming
branch entirely.
Fixes part of #335.
cc
The audio thread's Seek handler bailed on `current_audio_data.is_none()`
with a warning and returned. That field is intentionally None during
streaming playback — the bytes live inside current_streaming_source's
Arc<BufferedMediaSource>. Effect: every seek on a streaming track with
the CMAF download still in progress was silently dropped; the UI sent
the command, the player ignored it, and the seekbar snapped back to
whatever position the playback timer had reached (issue #335).
Branch the handler on the live source kind. Streaming: build a fresh
IncrementalStreamingSource from the shared buffered_source (new reader
at byte 0, same downloaded bytes — no re-download), then skip_duration
to the target. Non-streaming path unchanged.
Within-watermark seeks now work. Past-watermark seeks currently block
the audio thread while the decoder waits for more bytes; the clamp to
prevent that lands in the next commit.
cc
Minimal distros (the reporter's Raspberry Pi OS case in issue #331) ship
a trimmed /etc/asound.conf that defines only `!default` and doesn't pull
in the broader alias set most desktop distros provide. A card like the
HifiBerry Digi2 Pro — S/PDIF-only, so its selectable PCM is
`iec958:CARD=sndrpihifiberry,DEV=0` — then fails to open even though
the card is present and usable via the raw `hw:` device.
When CPAL's primary lookup by id returns None AND /proc/asound confirms
the card exists, rebuild the id as `hw:CARD=<name>,DEV=<n>` and retry
the lookup. The raw `hw:` PCM is exposed by the kernel driver for every
registered card, so it's a safe last resort — same card, same channel
routing, just skipping whichever userspace alias layer was missing.
Log both the alias failure and the fallback at warn/info so users can
see what happened without needing to diagnose ALSA config by hand.
Original error path is preserved when no fallback is possible (unknown
id shape, card not in /proc/asound, or hw: equally unavailable).
cc
Device enumeration produces four "CARD=" alias shapes (front:, sysdefault:,
iec958:, hdmi:) but the extractor only handled the first two. When a user
selected an S/PDIF or HDMI device id, the downstream proc_found check
always returned false, so the device-not-found error message dropped to
the generic "disconnected, renamed, or handled by another app" wording
even when /proc/asound showed the card present.
Part of issue #331 — reporter's HifiBerry Digi2 Pro is S/PDIF-only, so
its id is iec958:CARD=sndrpihifiberry,DEV=0, and the missing prefix match
obscured the real cause of the open failure.
This commit is a pure parsing extension; behavior changes only in the
error message accuracy. The hw:/plughw: fallback attempt lands in the
next commit.
cc
QueueManager::clear previously always preserved the current track;
plus bridge.play_index only mutates queue state, never triggers
audio. Result: when the user hit Clear Queue with nothing playing,
a stale track stayed in NOW PLAYING across app restarts.
- QueueManager::clear(keep_current: bool) — existing callers pin to
true (legacy behavior). New test covers the false path.
- QbzCore::clear_queue / CoreBridge::clear_queue take the flag through.
- v2_clear_queue accepts an optional includeCurrent flag from the
frontend; when true, calls bridge.stop() first so the audio pipeline
actually stops, then wipes the current slot too.
- qconnect sync path + qbzd daemon pin keep_current=true (no behavior
change).
cc
Twelve v2_* commands wrap mixtape::repo with the standard app state
pattern used by commands_v2/playlists.rs. Enum values travel as
strings across the Tauri boundary; camelCase for frontend, snake_case
for Rust.
Also adds LibraryDatabase::with_connection_mut for the reorder command,
which needs a transaction (&mut Connection).
cc
Two new tables (mixtape_collections, mixtape_collection_items) with
CASCADE on delete and indexes for the two common query patterns. One
additive column on session_queue_state for queue-source tracking.
Idempotent (CREATE TABLE IF NOT EXISTS, ALTER only when missing),
safe on every app start. The ALTER is skipped gracefully if
session_queue_state hasn't been created yet.
Adds LibraryDatabase::with_connection() helper (qbz-library) so
src-tauri can run external DDL on the shared Connection without
exposing it as a field. Migration is wired in session_lifecycle
immediately after library.init_at() in both the online and offline
activation paths.
cc
Reserved for upcoming Mixtape/Collection enqueue paths to mark item
boundaries. Existing enqueue paths populate it with the track's
album_id as a safe fallback so skip-to-item commands behave
correctly even for queues built via "play album" today.
cc
Offline-cache v2 bundles need runway for the decrypt pipeline. At 10
MB/s (software AES fallback) a 58 MB track needs 6 seconds, which
blew past the old 5s pre-emptive window and missed the gapless handoff
entirely. With AES-NI active the decrypt is ~500ms, so 10s is
harmless overkill — the decrypted bytes just sit in L1 a few seconds
earlier.
Design note: this is complementary to the AES-NI target-feature fix,
not a substitute. A too-small lead time makes gapless brittle even on
fast hardware (any hiccup blows the window); a too-large one is
wasted memory but otherwise fine. 10s is comfortable for every
realistic hardware/track-size combo we'll see.
If we ever want user-visible control, plumb a `gapless_lead_secs`
through AudioSettings and read it at the hot site.
cc
CMAF decrypt was the bottleneck for offline-cache gapless. Live
testing showed a 208 MB HiRes bundle took ~22 seconds to decrypt end-
to-end, which made gapless for anything longer than a 3-minute track
impossible (the gapless pre-emptive window is ~5s before track end,
so a 22s decrypt can't land in time regardless of how early we start).
Two changes, complementary:
1. `.cargo/config.toml` with `target-cpu=x86-64-v3` (Haswell baseline).
The `aes` crate ships both a software implementation and an AES-NI
hardware path, runtime-dispatched via `cpufeatures` — but the
AES-NI path is only compiled in when the appropriate target-feature
is enabled at build time. Default dev builds compile ONLY the
software path, which hits ~10 MB/s on a modern CPU. Haswell+ (2013
and up, every realistic QBZ user) supports AES-NI and clears
400 MB/s+. For prebuilt distribution binaries we'll want runtime-
dispatch via subfunction build or dynamic linking, but for self-
built and release-source-from-tag scenarios this is the right
default.
2. `decrypt_segments_into` no longer allocates a Vec per frame. Was:
frame = seg_data[..].to_vec(); // alloc
decrypt_frame(&mut frame); // in-place
output.extend_from_slice(&frame); // copy back
Now:
let start = output.len();
output.extend_from_slice(&seg_data[..]); // single copy
decrypt_frame(&mut output[start..]); // in-place
For a HiRes FLAC with ~50K frames this saves 50K small allocs +
50K double-copies. Output Vec is already pre-sized via
with_capacity(total), so no reallocation growth during extend.
Combined expected impact: 22s decrypt on a 208 MB track → under 500ms,
which fits inside the 5s gapless window with headroom to spare.
cc
The CMAF session cache is an Arc<RwLock<Option<CmafSession>>>. The old
ensure_cmaf_session did a read-check then dropped the guard then did
its POST unlocked, which meant two concurrent callers would each see
"no session", each POST /session/start, and each receive a different
session_id + infos. The second to finish stored its session as the new
cache, clobbering the first.
That was a problem because file/url wraps the per-track AES key against
whichever session_id the X-Session-Id header carried. If task A got its
wrapped key under session X but the cache got overwritten to Y before
decrypt time, the HKDF over Y-infos produced the wrong session_key and
the AES-CBC unwrap failed with "Unpad Error" — which is exactly the
warning that showed up in prefetch runs during parallel downloads and
caused the >3s gap between offline-cached tracks when the next track's
prefetch had silently fallen back to legacy.
The symptom in logs:
[CMAF] Starting new session ← task A
[CMAF] Starting new session ← task B (same ms)
Session started: id=bHoSYBFx...
Session started: id=bJ-w2wgm... ← cache now holds B
[PREFETCH] CMAF failed for track N: Content key unwrap failed:
AES-CBC unwrap failed: Unpad Error
Fix: double-checked lock pattern. Fast path stays on the read guard
for existing-valid sessions. Slow path takes the write guard, re-checks
under exclusive ownership, and only the first caller actually hits
session/start. Everyone else wakes up and returns the freshly-cached
value.
Compile check only — full behaviour validation in the running dev
session after this commit.
cc
The UI's offline-download progress ring listens to
'offline:caching_progress' events. The legacy StreamFetcher::fetch_to_file
emits those per HTTP chunk via app_handle. The new CMAF path went
silent because cmaf_download_raw lives in the qbz-qobuz crate with no
Tauri access — the user saw the completion toast but never saw the
ring fill.
Fix:
- Add an optional CmafProgressCallback to the qbz_qobuz::cmaf public
API. Typed as Arc<dyn Fn(CmafProgressUpdate) + Send + Sync>.
- New download_full_with_progress and download_raw_with_progress
variants; the callback-less versions delegate to them with None.
- fetch_all_segments fires the callback once per completed segment
with cumulative (k, n, bytes_this_segment). Callback is invoked on
the worker thread after the bytes land, before the rate-limit
cooldown.
- try_cmaf_offline_download passes a callback that emits
'offline:caching_progress' events in the exact shape the UI already
expects (trackId, progressPercent 0..100, bytesDownloaded,
totalBytes: null, status: 'downloading'). Also emits one
zero-progress event up front so the ring doesn't sit at "queued"
while the first segment fetches.
Percentage is computed as (segments_completed / n_segments) * 100,
rounded and clamped. It's segment-granular rather than byte-granular
so the ring advances in N discrete steps (typically 8-20 for a 4-min
track) rather than smoothly — matching what the CMAF pipeline can
actually observe, which is segment-complete events.
cc
Foundation for the offline-cache hardening story. The offline cache
needs to persist per-track AES content keys to disk, but storing them
plaintext would make copying the SQLite DB enough to decrypt the
cached audio on another machine.
qbz-secrets provides a uniform wrap/unwrap API backed by:
1. **OS keyring** (preferred): libsecret/gnome-keyring on Linux,
Keychain on macOS, DPAPI on Windows. A 256-bit master AES key
lives inside the OS secure store; all wraps go through it. This
is the gold-standard device binding used by commercial music
apps (Spotify, Apple Music, Tidal) for the same class of data.
2. **HKDF fallback**: when the OS keyring is not reachable (headless
setups — Raspberry Pi, Docker, the future qbzd daemon on a
server), the master key is derived on demand via HKDF-SHA256
over service_name + machine_id + a persistent per-install UUID.
Weaker than keyring (reversible by anyone with filesystem access
to both sources) but still device-bound against cross-machine
copy attacks, and lets daemon/headless variants work at all.
Every wrap uses AES-256-GCM with a fresh random 12-byte nonce. The
on-disk envelope carries a version byte + backend marker + nonce +
ciphertext+tag, so (a) we detect tampering via GCM, (b) we refuse to
silently unwrap a blob produced by a backend we can't reach, and (c)
we have a forward-compat path for future key rotation.
4 unit tests cover: small-secret round-trip, 16-byte content-key
round-trip (the exact CMAF use case), GCM tamper detection, and
nonce-randomness (two wraps of the same input differ).
This crate intentionally has zero QBZ dependencies — it's a generic
primitive. Next commits wire it into the offline cache schema + the
DB migration.
cc
Prep work for offline-cache CMAF hardening. The full CMAF pipeline
(init-segment setup, full-download, decrypt) used to live in
src-tauri/src/commands_v2/helpers.rs — fine for playback but unreachable
from the offline-cache code without dragging Tauri deps around.
Moves:
- try_cmaf_full_download → qbz_qobuz::cmaf::download_full
- try_cmaf_streaming_setup → qbz_qobuz::cmaf::setup_streaming
- CmafStreamingInfo struct → qbz_qobuz::cmaf
Adds:
- qbz_qobuz::cmaf::download_raw + CmafRawBundle — fetches the same track
but returns the ENCRYPTED segments + init bytes + the unwrapped
content_key + the session infos, ready to be persisted to disk as-is.
The offline cache will use this so that cached files are bit-identical
to what Qobuz delivered (no decrypt-to-disk), with the content key
stored separately under an OS-keyring-wrapped blob. Coming in next
commits.
- qbz_qobuz::cmaf::decrypt_segments_into — shared decrypt helper used by
download_full and (in the next commits) by the offline-playback path
that reads encrypted segments from disk instead of CDN.
In-tree behaviour is unchanged: try_cmaf_full_download /
try_cmaf_streaming_setup in helpers.rs are now thin wrappers that hand
the CoreBridge's QobuzClient to the crate functions. Same API surface
for playback.rs callers, same log tags, same on-wire behaviour.
v2_cmaf_stream stays in src-tauri because it binds to qbz-player's
BufferWriter + qbz-cache's AudioCache — those are playback-only deps
that don't belong in qbz-qobuz.
Net: -100 LOC out of src-tauri, +390 LOC in a properly-layered crate
module with docs explaining the two variants and why the raw one exists.
cc
/label/get is gone from the Qobuz v9.7.0.3 Android app (source:
c30/b.java doesn't declare it anymore). With the Qobuz beta rollout
the server-side deprecation timer is probably running, so we yank our
dependency now.
Removed:
- LABEL_GET path constant (qbz-qobuz + src-tauri/api)
- get_label() client method (qbz-qobuz + src-tauri/api)
- get_label() wrapper in QbzCore + CoreBridge
- v2_get_label tauri command + its lib.rs registration
- LabelDetail backend type (qbz-models + src-tauri/api/models)
- commands::search::get_label (dead, was never registered)
- Unused LabelDetail import in src/routes/+page.svelte
Preserved:
- Frontend LabelDetail interface (it's a UI view-model shaped by
LabelReleasesView, not a backend contract)
- /api/labels/{id} HTTP route on qbzd — now composes /label/page +
/label/getAlbums internally so external HTTP clients still see the
same { id, name, description, image, albums: { items, total, ... } }
shape
cc
Closes the gap between our client and the Qobuz Android app's current
label API (source: c30/b.java). Qobuz is rolling out a web beta so the
legacy /label/get is likely on borrowed time — adding the v9.7.0.3
endpoints now so the migration can happen in follow-up commits.
New endpoints (paths + client + core + bridge + v2 command + registered):
- /label/getAlbums → v2_get_label_albums
paginated catalog with sort/order/genre_ids/from_date/to_date
- /label/getNextReleases → v2_get_label_next_releases
- /label/getAwardedReleases → v2_get_label_awarded_releases
- /label/getPlaylists → v2_get_label_playlists
- /label/getTopArtists → v2_get_label_top_artists
- /label/story → v2_get_label_story
- /label/getList → v2_get_label_list (POST, mirrors
track/getList signing)
New response types in qbz-models:
- LabelListPage<T> — generic { has_more, items: [T], total?, offset?,
limit? } envelope, tolerant to either V2 list or SearchResultsPage
shapes until samples land
- LabelStoryResponse, LabelGetListResponse — best-effort with optional
fields so a shape mismatch is non-fatal
The legacy /label/get + get_label() + v2_get_label + LabelDetail are
retained untouched for now; frontend migration and deletion come next.
cc
Fix#327 — clicking a track in the queue panel now plays that exact
track even under shuffle. Adds play_upcoming_at with shuffle-aware
index resolution, plus dead From-impl cleanup.
vicrodh