Ran into what is likely an obscure stream.mpg buffering bug. Have moved a couple of my network cameras (home observation/security/wildlife) to Channels via custom M3U h264 RTSP. Since Channels has no .strm support (hint hint), is only useful for live viewing. Use additional instances of ffmpeg (I-frame only extraction) into mjpeg-server (since ffserver is discontinued) into my existing custom home network camera software to provide last-x-hour recording and web-based viewing with last-x-hour fast-seek.
Mjpeg-server uses a combination of HTTP chunked (yuck) plus multipart plus content-length prefixed encoding. This standards-compliant though dubious approach has exposed a bug likely in my HTTP ingestion that causes a hang after many hours of running.
Unexpectedly, the latter impacts Channels. A slow/misperforming stream listener causes Channels to buffer the stream (to allow for catch up). A good idea, but if the slow listener fails and Channels runs out of buffer, it kills all streams and all listeners including Channels clients themselves fail (Channels TVoS get a "disconnect" failure).
2021/09/07 12:04:25.653946 [WRN] Buffer for M3U-Cameras ch7002 is more than 50% full (clients=2, len=33564016) 2021/09/07 12:05:37.948777 [WRN] Buffer for M3U-Cameras ch7002 is more than 75% full (clients=2, len=50351156) 2021/09/07 12:06:36.001105 [WRN] Buffer for M3U-Cameras ch7002 is more than 95% full (clients=2, len=63768472) 2021/09/07 12:06:47.532552 [WRN] Buffer for M3U-Cameras ch7002 is more than 99% full (clients=2, len=66443900)
Adding buffering to accommodate slow listeners is good. Killing the well-performing listener streams in favor of a broken listener seems like a bug. If a listener is too far behind, Channels should drop it and continue providing the steam to the functioning listeners.
While I will resolve my listener issue, seems like the underlying Channels buffering issue should be fixed to ensure robust stream playback. Thanks.