Disconnection, retries, and task completion
Update:
URL streams and RTC use different retrieval and termination mechanisms. A single connection interruption does not necessarily end the task.
URL live streams
If the recorder exits and the task has not been explicitly stopped, the service runs up to 5 recording attempts, with delays of 2, 4, 6, and 8 seconds. Each attempt also includes stream retrieval/waiting time. HTTP chunk termination describes one transport case, not a universal end condition for all live protocols.
After attempts are exhausted and termination is determined, the service sends stream-closed according to callback settings and ends the task; failed notifications can be repeated. Media moderation/callbacks follow a separate flow and can pause during recovery.
RTC rooms and channels
RTC termination follows provider room entry, recording, idle, and exit events. ZEGO audio-idle and room-idle logout differ; Agora measures absence of remote channel users; TRTC measures absence of active recording users. For idleTimeMillis and provider switches, see the submission API. Do not apply URL-stream retry counts or timing to RTC.
Completion summary and reason codes
Newer stream-closed callbacks add a result summary and endReason; see the stream-closed payload for all fields. summaryComplete=false means the summary did not wait for all in-flight moderation. Tail segments and late results can arrive afterward; do not discard subsequent media results after receiving the notification.
endReasonMeaning
retry_exhaustedRecording attempts for a URL live stream are confirmed exhausted.
recorder_stoppedRTC recording has stopped; this does not identify a user departure, expired credentials, or a specific SDK error.
unknownNo confirmed termination condition is available.
Latest recording diagnostic
Optional lastRecordingReason returns a classified diagnostic for URL streams only. It may come from an earlier failed retry, followed by a successful attempt; interpret it separately from endReason. It is omitted when unavailable and does not expose raw errors, credentials, or authentication parameters.
lastRecordingReasonMeaning
stream_ended / stream_idleSource ended or disconnected after inactivity.
network_dns / network_timeout / network_connectionDNS, network timeout, or connection problem.
http_4xx / http_5xxSource returned the corresponding HTTP error; does not specifically indicate expired credentials.
invalid_input / codec_error / missing_stream / no_outputInvalid input, codec issue, missing media stream, or no output from that attempt. no_output does not mean the task never received media.
output_io / killed / process_crash / terminatedRecording output failure, killed process, crash, or termination signal.
expected_stopThe latest diagnostic recorded an expected stop; explicit-stop notification behavior is unchanged.
scheduler_rejected / process_start_failed / process_wait_interrupted / process_state_error / recording_exceptionRecording startup or execution error.
Explicit stop and resubmission
When your session ends, call the stop API; an explicit stop does not promise a stream-closed callback or retract already issued result callbacks. Wait for recorder finalization and cleanup before submitting new settings. Your application decides whether to restart after disconnection; an immediate repeat submission can still match the original deduplication record.
URL streams and RTC use different retrieval and termination mechanisms. A single connection interruption does not necessarily end the task.
URL live streams
If the recorder exits and the task has not been explicitly stopped, the service runs up to 5 recording attempts, with delays of 2, 4, 6, and 8 seconds. Each attempt also includes stream retrieval/waiting time. HTTP chunk termination describes one transport case, not a universal end condition for all live protocols.
After attempts are exhausted and termination is determined, the service sends stream-closed according to callback settings and ends the task; failed notifications can be repeated. Media moderation/callbacks follow a separate flow and can pause during recovery.
RTC rooms and channels
RTC termination follows provider room entry, recording, idle, and exit events. ZEGO audio-idle and room-idle logout differ; Agora measures absence of remote channel users; TRTC measures absence of active recording users. For idleTimeMillis and provider switches, see the submission API. Do not apply URL-stream retry counts or timing to RTC.
Completion summary and reason codes
Newer stream-closed callbacks add a result summary and endReason; see the stream-closed payload for all fields. summaryComplete=false means the summary did not wait for all in-flight moderation. Tail segments and late results can arrive afterward; do not discard subsequent media results after receiving the notification.
endReason |
Meaning |
|---|---|
retry_exhausted |
Recording attempts for a URL live stream are confirmed exhausted. |
recorder_stopped |
RTC recording has stopped; this does not identify a user departure, expired credentials, or a specific SDK error. |
unknown |
No confirmed termination condition is available. |
Latest recording diagnostic
Optional lastRecordingReason returns a classified diagnostic for URL streams only. It may come from an earlier failed retry, followed by a successful attempt; interpret it separately from endReason. It is omitted when unavailable and does not expose raw errors, credentials, or authentication parameters.
lastRecordingReason |
Meaning |
|---|---|
stream_ended / stream_idle |
Source ended or disconnected after inactivity. |
network_dns / network_timeout / network_connection |
DNS, network timeout, or connection problem. |
http_4xx / http_5xx |
Source returned the corresponding HTTP error; does not specifically indicate expired credentials. |
invalid_input / codec_error / missing_stream / no_output |
Invalid input, codec issue, missing media stream, or no output from that attempt. no_output does not mean the task never received media. |
output_io / killed / process_crash / terminated |
Recording output failure, killed process, crash, or termination signal. |
expected_stop |
The latest diagnostic recorded an expected stop; explicit-stop notification behavior is unchanged. |
scheduler_rejected / process_start_failed / process_wait_interrupted / process_state_error / recording_exception |
Recording startup or execution error. |
Explicit stop and resubmission
When your session ends, call the stop API; an explicit stop does not promise a stream-closed callback or retract already issued result callbacks. Wait for recorder finalization and cleanup before submitting new settings. Your application decides whether to restart after disconnection; an immediate repeat submission can still match the original deduplication record.