My Longest Episodes Were The Ones That Wouldn't Transcribe

In the last post I wrote about episodes that quietly stopped and never told me. That fix made the failures visible. This one makes them stop happening.

Because once I could see them, the pattern was obvious and slightly embarrassing: the episodes failing were the long ones. Which is to say, most of them.

Two and a half minutes

The part of PodGlue that turns audio into a transcript was running somewhere with a hard ceiling of about two and a half minutes. Not two and a half minutes of audio, two and a half minutes of working. Download the file, send it off, get the text back, all of it inside that window.

A ten-minute clip is fine. A sixty-minute interview is not remotely fine.

So the thing that failed wasn't unusual episodes. It was normal ones.

I was guarding the wrong thing

Here's the part I want to keep in mind for next time.

I had limits in place. They were file-size limits: reject anything over a certain number of megabytes, route bigger files down a different path. Reasonable-looking. Completely useless here.

Because the ceiling isn't about size, it's about time. A file can slip under every size limit I set and still take too long. Bitrate, network speed, how busy the transcription service is that morning, none of that is visible in the file size. I was measuring one thing and hoping it stood in for another.

A limit that measures the wrong dimension isn't a guard. It's a guess that looks like a guard.

Moving the work

The fix was to stop doing this work in a place with a stopwatch on it.

PodGlue already runs a separate service for heavy media jobs, the thing that processes studio recordings. It gets an hour per job instead of two and a half minutes. The transcript work now happens there.

The flow is simple. You upload audio, PodGlue says "got it, working on it," and hands the job over. The heavy service takes as long as it needs. When it's done it reports back, and the episode moves on to show notes and everything downstream.

You're not sitting on a spinner waiting for it. And nothing is silently dropped if a step falls over, that's what the last post was about. The two pieces only work together.

One decision I want to explain

Not every failure is worth retrying.

If the audio file is actually a video, trying three more times won't make it audio. If an episode is so long it exceeds what the model can produce in one pass, running it again produces the same result and costs the same money.

So those stop immediately and tell you what's wrong. A service being briefly busy, or a network blip: those retry. The difference matters because a retry budget you spend on impossible things isn't there when you need it for a real hiccup.

What's next

Going back for the episodes that got stranded while all of this was broken. There's a real backlog of them, and now that the path actually works, they can be run through it.

I keep coming back to the same thing with PodGlue. The point isn't that it does the work, plenty of tools do work. The point is that it doesn't quietly lose things. An episode you recorded should still be there, finished, when you go looking for it. That's harder to build than it sounds, and it's most of what I've been doing this month.