Add detail to log when a stream ends

[papabear99]

trafficstars

During this week's Water Cooler chat a side topic was raised about Orchestrators not knowing why streams end.

Describe the solution you'd like Add more detail for the current Segment loop timed out; closing message when a stream ends.

i.e. Broadcaster ended stream: closing session Transcoder did not return last segment: closing session Any additional info would helpful

[thomshutt]

Hey @papabear99, thanks for the suggestion! I think this is something we'd be happy to accept if someone in the community can do the work to populate the message with the info you want

[papabear99]

Thanks @thomshutt I will query the group in the Water Cooler today and then run it by the rest of the community in discord.

[Titan-Node]

@thomshutt In my opinion there are only 2 logs we really need to start:

1. Broadcaster gracefully ended stream
2. There was an error (of any kind)

Just adding the feature that notifies us that a Broadcaster ended a stream gracefully would be really helpful.

If we wanted to get more granular we could break down the specific logs of reasons we could respond to.

Examples of logs

Gracefully ended

1. Stream ended by Broadcaster - No errors

Orchestrator Error 2) Stream ended - Broadcaster switched Orchestrator due to performance 3) Stream ended - Could not provide transcoded segments back to Broadcaster - Transcoder error

Broadcaster Error 3) Stream ended - No more segments received from Broadcaster - Timed Out

[stronk-dev]

+1 for this feature request. It's common to have sticky sessions in one location while in another location streams are choppy and end after a few segments. It's good to be able to verify whether this is caused by an error in the O's setup, a bug in go-livepeer or on the B side.

Maybe we can also tag test streams in a certain way? You often see 36, 96, and 147 segment streams and while we expect these are tests done by Livepeer, this is not apparent and often cause spikes in transcode graphs as well

[stronk-dev]

Correct me if I am wrong, but doesn't the proposed fix simply print Transcoding session ended by the Broadcaster in each case, so not an actual exit reason?

[mjh1]

Yep sorry, the issue was auto closed along with the PR, I'll reopen this. We've addressed the "Broadcaster gracefully ended stream" point. We can address the exit reasons in further PRs.