Luke Strickland

Slight error on watching `ingest1` stream from `combo1`: ``` janus[66953]: [2022-06-21 12:47:23.805] [info] New request watch janus[66953]: [2022-06-21 12:47:23.805] [info] Request to watch channel 16791 janus[66953]: terminate called after throwing...

Seems to be fully functional now, but would appreciate feedback on a better way of handling the switch between interacting with the EdgeNodeServiceConnection (if using a relayed stream) vs XServiceConnection...

Getting back to this now, if I remember correctly there's a single remaining bug: > Viewer opens stream, combo server adds them to the pendingViewerSessions, then a new stream connects.......

I've confirmed it's possible to have this issue occur both: 1. When starting your stream 2. Randomly in the middle of your stream

I'm tracing a channel I just watched it happened to. It looks like the `Stream.ended_at = '2021-03-19 13:28:17'`. The user is streaming to `do-nyc3-ingest2.kjfk.live.glimesh.tv`. Here's the surrounding log, which don't...

Last bit of info I noticed on do-nyc3-ingest1 (which the streamer is not connected to). ``` [2021-03-19 13:51:12.104] [warning] Glimesh service connection HTTP request failed with error 4 [2021-03-19 13:51:12.104]...

We do seem to still have this bug, or a slight variation, where certain streams stay online instead of going offline even after the video content has stopped. I checked...

Confirmed this morning that the exact original bug is still occurring. A user was still transmitting data packers, orchestrator still had knowledge of them, and edges properly distributed the video....

Worth mentioning we already maintain a [go-rtmp fork](https://github.com/Glimesh/go-rtmp).

Well, these metrics are used to debug the quality of the stream that the streamer is pushing to us. So they should exist either at, or right after the video...