mirror of
https://github.com/Psychotoxical/psysonic.git
synced 2026-07-21 23:05:46 +00:00
cucadmuh
3ec65a6407
* fix(audio): make seeking work on streamed Opus/Ogg via on-demand HTTP Range Seeking inside an Opus/Ogg track streamed over ranged HTTP was a contained no-op (the seekbar snapped back); it only worked once the track had fully downloaded/cached. symphonia 0.6's Ogg demuxer seeks by bisecting the byte range (reading pages at midpoints across the whole file) and scans the last pages during the probe, but RangedHttpSource only filled the buffer linearly from offset 0, so any read ahead of the download front blocked until the linear download caught up. Keeping Ogg seekable through the probe without a real random-access source would have forced a full pre-download. Add an on-demand random-access fetcher to RangedHttpSource: when a read lands well ahead of the contiguous linear download (a seek, a bisection midpoint, or the end-of-stream probe), fetch the needed range over HTTP Range (1 MiB window) on the tokio runtime and let the read loop poll for it, instead of blocking on the linear filler. Ranged Ogg now stays seekable through the probe (records its byte range) so seeking works for real; the catch_unwind in try_seek stays as a safety net. - New OnDemand fetcher writes arbitrary ranges into the shared buffer (same bytes the linear download would write; idempotent under the buffer mutex, mirroring the existing MP4 moov tail-prefetch). It never touches downloaded_to/done, so full-download completion and the track-analysis seed are unaffected. - On-demand only fires on a forward gap > 512 KiB, so normal sequential read-ahead (and a slightly starved play cursor) still waits for the linear download without spurious range requests. - ranged-stream now passes random_access=true; preview keeps on_demand=None. Does not touch the Tauri boundary (no invoke/event changes). * docs(changelog): add 1.49.0 entry for streamed Opus/Ogg seeking (#1110) Also credit the streamed-seek work in settingsCredits. * fix(audio): require 206 for ranged Range fetches at a non-zero offset Address PR #1110 review note: ranged_write_http_range accepted a 200 the same as a 206. A server that ignored the Range header and replied 200 returns the whole body from byte 0; writing that at a non-zero offset would corrupt the buffer (affects both the on-demand seek fetcher and the MP4 moov-tail prefetch). Accept 200 only when the request started at offset 0; otherwise require 206.