Devlog #6

Last time ended with the review finally seeing subtitles — burn mode drew them into the pixels, and the preview proved the output wasn’t empty. The review came back with a new problem, and this one was in the desktop app. The reviewer dragged a video in, then dragged its subtitle in a moment later, and nothing happened. No pair, no row, no error. Just a log line nobody reads.

“I dropped the video, then the subtitle. Nothing happened.”

The flow made sense to me. Any sane user would load the video and subtitles together. The app matched files by stem and folder, so the names matched — but the pair never appeared. I reproduced it immediately: drop the .mkv, 0 pairs. Drop the .srt, 0 pairs. Drop them together, 1 pair. The order wasn’t the problem — the batch was.

It was by design. That was the problem.

The drop handler split the incoming paths into videos and subtitles and matched them within that single batch:

Both file types had to arrive in the same drop or the matcher had nothing to join. It wasn’t a bug — it worked exactly as written. My own testing had always dropped both files at once, so I never saw it. The code was correct and exactly wrong. To make it worse, that same logic was copy-pasted in four places: the drop handler, the file dialog, the drop-area click, and the folder scan. Four copies, one flaw.

Deferred matching

The fix was to stop matching batches and start matching state. Files now accumulate into pending queues, and every drop re-runs the matcher against everything pending. Drop the video, drop the subtitle five minutes later — the second drop finds the first and pairs them. All four entry points now route through one _ingest() method, so the deferred-matching rule can’t drift between copies again.

Then I almost made it worse

My first pass at leftovers had a shortcut: sort the unmatched files by name and zip them into pairs. Five videos and two subtitles? Two pairs, formed by name order, not by any actual correspondence. The names could be completely unrelated — the wrong subtitle would get muxed in silently. That’s the exact failure class I was trying to kill. So the shortcut got a guard: auto-pairing only happens when exactly one video and one subtitle are left unmatched, and everything else stays in the pending queue where the user can see it.

While I was in there: dropping the same file twice no longer stacks duplicates in the queue, and the waiting notice now shows whenever anything is still pending — not just when a drop matched nothing. The log panel expands on its own so the “waiting for a matching subtitle” state is visible instead of hidden.

TMI

It was quite a struggle at first; I hadn’t properly watched the review video, so while testing it myself, I kept wondering, “Wait, it works fine—why do people say it doesn’t?” It turned out the issue was incredibly simple. I made a few minor quality-of-life improvements, but since they were so small, I decided to skip mentioning them. I actually wanted to do more, but I’ve already spent nine hours on this, so I’m wrapping things up now.