nathan
320eaa1b28
continuous-integration/drone/push Build encountered an error
- src/buffer_state.go replaces the two sync.Maps plus a global RWMutex with one bufferMu guarding a map of *Playlist. Each stream has one shared bufferStream (URL, folder, status, client count, error, cancel hook); downloaders keep a private ThisStream and publish through helpers. Playlist.Clients / ThisClient / ClientConnection are gone: there was one client counter per stream in two places that could disagree. - bufferAcquireStream does the tuner check and the registration under the same lock, so two clients tuning at once cannot both pass the limit. bufferReleaseClient removes the stream when the last client leaves, cancels its process and deletes its segment folder. - bufferingStream rewritten: waits on r.Context() instead of the deprecated CloseNotifier, sets Content-Type before WriteHeader (the old code set headers after and one was literally named "Content-Length:"), flushes each segment to the client, no defer inside the segment loop. - connectToStreamingServer: shared streamHTTPClient with dial, TLS and response-header timeouts (no overall timeout, bodies are endless); the deferred Body/segment closes inside the redirect and read loops are now explicit closes, so a multi-hour stream no longer accumulates them. - thirdPartyBuffer rewritten around exec.CommandContext: the process is killed when the last client leaves or when no usable data arrives within 20 s (time.AfterFunc watchdog, no leaked goroutine); cmd.Start error is checked; no panic; one file handle per segment. ffmpeg and VLC command lines come from buildFFmpegArgs / buildVLCArgs, which are unit tested. - Data.Cache.StreamingURLS is guarded by streamingURLsMu and persisted from a snapshot. - Tests (src/buffer_test.go, run with -race): restream shares one provider connection, six concurrent tunes against a tuner limit of two, 50-way acquire/release contention, cleanup and cancel on last release.