The segment feeder spawned by play_track kept downloading to completion
after the user switched tracks, holding the link: a shuffle&play pressed
mid-stream measured 5441 ms for the new track's init segment (vs
423-760 ms on an idle link) because the init's connect/TLS/TTFB queued
behind ~15 MB of in-flight segments of a track nobody was listening to.
begin_play (every superseding intent: play_*, stop) now cancels the
registered feeder cooperatively via a watch flag the feeder selects on;
the in-flight request is dropped immediately. The abandoned buffer is
deliberately NOT errored or completed at cancel time, so the outgoing
engine keeps playing what is already buffered until the audio thread
installs the new source; the buffer is sealed (complete) once the new
source is in place (or on stop) so a parked reader wakes to EOF instead
of hanging. Cancelled partial tracks are not cached.
km
vicrodh
a561e7ae28