Twenty seconds of the repair: a transcript with a hole in it, the hole being filled from the broadcast's own audio, and one continuous transcript at the end.
Why your transcript starts where you did
Live transcription is a recording process. Audio arrives, something turns it into text, and the text is stored. Nothing about that process reaches backwards. If no capture was running at 19:04, then 19:04 produced no text, and scrolling up in the transcript will not produce it later - there is nothing above the first line because nothing was written above it.
This is also why ordinary YouTube transcript tools fail on a stream that is still live. They fetch a caption file, and for a broadcast still airing that file is incomplete or absent. They are retrieval tools pointed at something that has not been written down yet.
So the hole is real. What is not true - and this is the part worth being precise about - is that the hole is permanent. No transcript existed for those 78 minutes, but the audio usually still does. A YouTube stream with DVR enabled keeps its earlier minutes seekable while the broadcast continues. That is the whole opening for the repair: text was never written, but the source it would have been written from is still sitting there, addressable.
What “Fill missing gaps” actually does
The button in the transcript header queues a job against that broadcast. It is not one operation but a sequence, and the order is chosen to keep the expensive part small.
1. It measures the holes first
Before fetching anything, the job looks at the transcript you already have and finds the stretches with nothing against them. Only gaps longer than a minute count - a three-second pause between sentences is not a gap, it is someone breathing. What comes out is a list of intervals: 19:00 to 20:18, say, plus the six minutes in the middle where the capture dropped.
2. It tries captions before it tries audio
On YouTube, the caption track often covers part of the broadcast already, even mid-stream. That is free to fetch and near-instant, so it runs first. Whatever it covers is one less thing to transcribe. Twitch has no caption track at all, so those jobs skip this phase entirely and go straight to the audio.
Worth knowing what you are getting when captions do cover a stretch: they are YouTube's automatic captions, which is a different quality bar from a dedicated transcription pass. The trade is speed and cost against fidelity, and it is why the difference between captions and live transcription matters more than it looks.
3. It transcribes only what is left
Whatever the captions did not cover gets the real treatment. The broadcast audio is pulled once, cut to the specific intervals that are still empty, and only those slices are transcribed. A three-hour stream with twelve minutes missing costs twelve minutes of transcription, not three hours of it. The cut is the reason this is affordable enough to be a button rather than a support request.
4. It merges rather than appends
Recovered lines are inserted at their true broadcast timestamps, so the opening lands above the live edge where it belongs and one search covers the whole broadcast. Each line is also checked against a three-second window before it goes in, and anything landing on top of existing text is dropped. That is what makes the operation safe to repeat: run it twice and the second run finds almost nothing to do.
Recovered lines carry their origin in the transcript, so a line that came from a caption track or from re-transcribed audio is distinguishable from one captured live. When a claim depends on exactly what was said, knowing which path produced the words is not a detail.
Where the recovered text is better than the live text
There is an assumption worth overturning here. Backfilled lines sound like a downgrade - the salvage version, the best-effort copy. In practice the opposite is usually true.
Real-time transcription is the harder problem. It commits to a word before the sentence finishes, with no access to what comes next, under a latency budget that exists because you want the line on screen while it still matters. Transcribing recorded audio has none of those constraints: the surrounding seconds are all available at once. That is why the same broadcast transcribed from a file reads more cleanly than it did live.
So the transcript you end up with is uneven in an interesting way. The part you were present for is the fast version. The part you missed is the careful one.
When the gap matters more than the rest
For a lot of viewing, arriving late costs nothing. For a few cases it is the whole event:
- Prepared remarks come first. Statements are read at the top, questions come after. If you joined during the Q&A you missed the part that was written down in advance and is therefore the most quotable.
- Mention markets settle on a single word. A contract resolving on whether a phrase was said is unanswerable if an hour of the broadcast was never transcribed. “I did not hear it” and “it was not said” are different claims, and only one of them is checkable.
- Someone tells you about it afterwards. A line gets clipped and quoted an hour later. Searching your own transcript for it only works if your transcript goes back that far.
- Overlapping events. Two things start at once, you watch one, and the second is recoverable rather than lost - which changes how you choose.
Doing it
Open the stream on the watch page as usual. Press Fill missing gaps in the transcript header. The header then reports the stage it is on - fetching captions, downloading audio, generating transcript, merging - and the job runs on LiveScript's servers, so you can close the tab and come back to it.
A long backfill on a multi-hour broadcast takes minutes rather than seconds, most of it spent pulling audio. The live capture keeps running the entire time; filling the past does not interrupt the present.
It draws on the same minute pool as file uploads, and bills for the audio it actually transcribes rather than the length of the broadcast. Free accounts see the button in place but disabled - the work behind it is metered, so it comes with Pro or the Day Pass.
The version of this that does not cost anything
Backfill is a repair, and repairs are worse than not needing one. The captions phase gives you automatic-caption quality on any stretch it covers, the audio phase spends minutes you could have spent elsewhere, and neither can recover audio the platform no longer serves.
The preventive version is to not be the trigger. Channel drop alerts watch a channel and start the capture when a stream appears, whether or not you are awake for it - the reasoning is in transcribing streams that start without warning. Arm one on the channels you actually care about and the gap never opens. Use backfill for the streams you could not have predicted.
If the reaction should belong to a program rather than a person, the live WebSocket API streams lines as they are spoken and the API reference covers the event shapes; the MCP server hands a finished transcript to Claude once the broadcast is over.
The short version
Your transcript starts where your capture started, because live transcription writes text rather than fetching it. The audio for the part you missed usually outlives that fact, which is why the gap is repairable at all - one button, captions where they exist, re-transcription where they do not, merged back at the right timestamps.
Open the stream you joined late and fill it in. Then arm an alert on the channel, so the next one does not need repairing.