mirror of
https://github.com/Vateron-Media/XC_VM.git
synced 2026-10-09 20:02:34 +02:00
Divarion_D
4902e953a0
For continuous-TS delivery (/play/<token>/ts) the client's whole playback buffer is the initial prebuffer burst — the feed loop then runs in real time, so the buffer never grows past it. On a cold on-demand start the server began serving the instant the playlist first appeared, when only the 1-2 fast-start (2s) segments existed, so selectSegments could only return ~2s and the client was stranded at ~2s of buffer regardless of client_prebuffer. Wait until the playlist actually holds client_prebuffer seconds (bounded by on_demand_wait_time, bailing if the stream stops) before the first read. Clients only — restreamer chains keep their low-latency behaviour; warm streams already satisfy the condition and don't wait. Adds SegmentReader::playlistBufferedSeconds() (sum of #EXTINF) as the gate. Validated live on stream 567: at cold start OLD served 1 seg / 2.0s; NEW served 5 seg / 10.0s after a 0.2s wait (fast-start pre-generates segments, so the added startup latency is negligible). Verified: php -l, phpunit (SegmentReaderTest 10/10), make gates.