Keeping Long Live Recordings Running Through Deepgram Stream Recovery
Telli.sh now rolls Deepgram live transcription streams on a proactive schedule so Pro and Pro+ recordings can continue without forcing a browser restart.
Live meetings rarely end at a neat infrastructure boundary. Some customer calls, lectures, interviews, and multilingual reviews run longer than an hour, and the recording tool should not make the user think about upstream connection recovery.
Telli.sh now handles that recovery inside the server-side live transcription pipeline. On a proactive long-stream schedule, Telli.sh closes the current Deepgram STT WebSocket, opens a fresh one, and replays the small amount of audio received during the reconnect.
The browser recording session stays open. The user's raw audio continues writing to the same recording file. The transcript stream continues from the new Deepgram connection.
What changed
Before this update, a long Deepgram live session relied on one server-side transcription connection staying healthy indefinitely. The browser could still be sending audio, but the transcription connection needed a better recovery path for long-running meetings.
The new rollover path adds three safeguards:
- a proactive reconnect before a long-running stream becomes fragile
- a short server-side audio buffer while the new Deepgram WebSocket opens
- a replay step so the current audio chunk is not dropped during rollover
This is especially important for Pro and Pro+ users because speaker diarization starts at Pro. Pro+ still mainly differs by available recording minutes, but both paid tiers should be able to run long live notes without manually stopping and starting a meeting just to refresh an upstream stream.
What users should expect
For normal meetings, nothing changes. The reconnect happens behind the scenes.
For long meetings, the live transcript may briefly pause while the server opens a new Deepgram stream. Audio capture continues during that pause, and the saved recording remains continuous. When the new stream is ready, buffered audio is sent into it.
Telli.sh still applies speaker labels according to the user's plan and the current transcription provider settings. For long recordings, the final saved note remains tied to the full recording so the post-recording pipeline can keep the transcript and note reviewable.
Why this matters
The point of live notes is not only fast text. It is trust in the workflow:
- a user can stay in one recording session
- the transcript is not silently cut at a provider boundary
- speaker-aware notes stay available for Pro and Pro+ conversations
- the final note remains connected to the source audio
That reliability matters more than adding another visible control. The best version of this feature is the one the user does not need to manage.