Adding a retry mechanism when transcription fails

[arquitech-ai]

And sometimes it stays stuck in the "Transcribing" state and does not even timeout.
Ideally if we could see these audio files in History that would be great so that we can retry to transcribe.
If not long dictations can get lost and it is very frustrating.
Thanks for considering solutions for that!

[DevEmperor]

Thanks for writing this up — the good news is that most of it is already in the app, so let me
show you where it lives, and then ask about the one part that is a genuine report.

1. Dictate already retries by itself. A transcription that fails for a retryable reason
(timeout, connection dropped, rate limit, provider 5xx) is sent again up to three more times, three
seconds apart. While that happens the Smartbar reads Retrying… (2), (3) … so you can see it
working rather than just waiting.

2. If it still fails, the recording is kept and you get a one-tap resend. A ↻ chip appears in
the Smartbar; tapping it sends the exact same audio again. This is
Settings → Dictate → Output → "Resend button" and it is on by default.

3. And the audio does show up in History — that already exists too. Since v5.1.0 there is a
transcription history (Settings → Dictate → History, and the History quick action in the
Smartbar opens it as a panel over the keyboard). Two things there are worth knowing:

• A failed dictation is logged with its audio, always — even if "Keep audio" is off. A
  failure has no text, so the recording is the only way back; that switch only governs successful
  dictations. The entry shows up in red as "Transcription failed — re-transcribe to retry".
• In the History panel every entry has a ↻ button that re-transcribes it. In the History
  screen you can also play the recording back, export the WAV and share it.

So a long dictation that fails should not be lost, today, with the default settings. If you have
lost one, that is a bug and I would like the details.

Now the part I cannot explain away: "stuck in Transcribing and does not even time out."

There are timeouts. A provider request has a whole-call budget of 120 s by default, adjustable
between 30 and 600 s under Settings → Dictate → Providers → "Request timeout". But the retry in
point 1 multiplies it: four attempts at 120 s plus the pauses is roughly eight minutes before
an error finally appears — which from the outside looks exactly like "it never times out". Two
providers (Soniox, AssemblyAI) upload and then poll for the result, with a five-minute budget of
their own on top.

One case really has no clock at all: the on-device engine, where the work is your phone's CPU
rather than a network. A long recording on a slower device can sit there for a while with nothing
to show.

To tell those apart, could you tell me:

1. Which provider and model, and is it a normal dictation, live/streaming, or a shared audio file?
2. Roughly how long did it sit on "Transcribing…" — and did an error eventually appear, or did it
   truly never end?
3. Did the Smartbar ever change to "Retrying… (2)"?
4. Roughly how long was the recording, and app version?

Two things I am taking from this regardless of the answer: "Transcribing…" should show how long it
has been going instead of eight silent minutes, and there should be a way to give up on a stuck
request while keeping the recording. (That last one half exists already: if you turn on the
on-device model's long-press shortcut, holding the mic during a stuck cloud request cancels it and
finishes the same recording locally, since v6.0.0. It should not require an on-device model to be
useful, though.)

[arquitech-ai]

Hi Jannis,

Thank you so much for the prompt, detailed and helpful reply.

1. I am using Groq with openai/gpt-oss-120b model with a free api key but the free tier is very generous.
2. Not that long, usually less than a minute.
3. No I have never seen the Retrying word in the toolbar. Neither the resend button which is activated. Unless you mean the bar that says Interrupted, that one does appear sometimes but unfortunately not every time it fails. For example the interrupted/retry appears when I start recording into one app then move to another one and open the keyboard there again but that trick does not work if it is stuck in transcribing state which really does not timeout sometimes even when online. I have waited more than 5min hoping to get a fail/retry option.
4. I have the latest version 1.6.2
5. Also I do not see anywhere in AI Providers an option to adjust the timeout.
6. I have tried to start a recording while online then go offline before trying to transcribe and it does stay stuck in Transcribing for more than 120s. Even when I go back online it does not always go through or timeout.
7. Any way I can find the recording in my android files when it does not show in history so I can retry to transcribe it?
8. Should I send my preferences backed up to you? Might be related to other options like real time transcription as I activated a lot of them!
9. My phone is a Pocophone F5 and MIUI might be interfering as well.

I love using Openwhispr on Windows and your app is really as good as this one if not better so congrats for that!

Thanks again!
Pierre

[DevEmperor]

Hi Pierre,

That reply was more useful than you probably expected, because two of the things you could not find
genuinely are not there. Let me correct myself first, then say what has changed since.

1. The "Request timeout" setting does not exist in your version. My mistake.

You are on 6.1.2 — I read your "1.6.2" as a transposition, that was never a Dictate version. The
timeout slider under Providers → Network was written on 7 September and has not been released
yet, so there was nothing for you to find. The same is true of the elapsed-seconds counter beside
"Transcribing…", which I built the evening before your reply, because of this thread. Sorry for
sending you looking for both.

What is in 6.1.2 is the retry indicator, the resend button and the failure entries in History. So
the fact that you have never seen any of the three is not you missing them — it is information, and
it points somewhere specific.

2. The model you named is your rewording model

openai/gpt-oss-120b is Groq's chat model; Dictate uses it for rewording and auto-formatting.
Transcription on Groq is whisper-large-v3-turbo (the default) or whisper-large-v3. Worth a glance
under Providers → Groq, but almost certainly not the cause here.

3. My best guess, and it fits everything you describe

Do you have "Offline fallback" turned on, with an on-device model downloaded?

If so, your test from point 6 does this. Going offline makes the Groq call fail instantly rather
than slowly — so the four attempts and their "Retrying… (2)" flash past in about twelve seconds and
are very easy to miss. Then the offline fallback quietly takes over and transcribes on your phone
instead. And the on-device engine had no timeout at all until three days ago: it runs until it is
finished, however long that takes.

That is literally "stuck in Transcribing and does not even time out". It explains why coming back
online changes nothing — there is no network involved any more. And it explains why no error, no
resend button and no History entry ever appeared: all three are written when an attempt ends, and
this one never did.

One thing would settle it: while it is stuck, is there a small phone icon next to "Transcribing…"?
That icon means the work is running here rather than on a provider's machine. If it is there, the
diagnosis is confirmed. If it is not, this is a genuinely hanging network call and I want to keep
digging — so please tell me either way.

4. What has changed because of your report

All of this is on main now and will be in the next release, not in 6.1.2:

• The wait has a clock. "Transcribing…" now trails the elapsed seconds, so a slow answer and a
  dead one stop looking identical. It keeps counting across retries and across the handover to the
  offline fallback, because you have been waiting since the recording stopped — that total is the
  number that answers the question. (Show how long "Transcribing…" has been running #355)
• The on-device engine has a timeout, the same "Request timeout" every provider call uses. That
  is the one that had none. (Put the on-device engine on the same request timeout as every provider #354)
• A dictation is logged to History the moment its audio is sent, not when the answer comes back.
  Until a transcript exists it is the ordinary red "Transcription failed — re-transcribe to retry"
  entry with its recording attached; when the transcript arrives it is rewritten in place. Which
  means a request that hangs, a keyboard the system kills mid-upload, or a phone that reboots all
  leave a recoverable entry behind instead of nothing. (Log a dictation to History when it is sent, not when it comes back #358 — filed off the back of this thread)
• And you can now walk away from a stuck request without losing the dictation. Tapping the mic
  button while it says "Transcribing…" has always cancelled the request; it used to throw the
  recording away in the same breath, which is why it was no use to anyone. It now keeps it, in
  History, ready to re-transcribe.

5. Two things you can do today, on 6.1.2

• That mic tap still gets you out of the stuck state — it just costs you the recording on this
  version.
• MIUI: give Dictate "No restrictions" under battery, and turn off the background and autostart
  limits. A keyboard process the system has frozen cannot run a timeout either.

6. Finding the recording in your files (your point 7)

Not with a file manager, no — recordings live in Dictate's private storage, which Android does not
let other apps read. The route to them is Settings → Dictate → History, where an entry can be
played back, exported as a WAV and shared. On 6.1.2 a stuck dictation never gets an entry at all,
which is exactly the gap the change above closes.

7. The settings backup (your point 8)

Please do not post it here. The backup contains the preferences file, and your API keys are in it
in plain text. If you would like to send it, mail it to contact@devemperor.net instead, and rotate
your Groq key afterwards to be safe. Honestly though, the answer to point 3 plus a note of which
options you switched on will probably tell me more than the file would.

Thanks for the comparison with OpenWhispr — glad it holds up.

[arquitech-ai]

Hi Jannis,
Thanks for keeping up with that issue.

1. OK I'll wait for your new release, hopefully that will fix my issue.
2. You are right it was empty and I selected whisper large v3 turbo for transcription.
3. No I do not have any offline fallback config defined in AI providers for On-Device.
4. Looking forward to these updates!
5. I just allowed Dictate as a background process with no battery optmimization. I don't have a mic icon when it is stuck in Transcribing state, just a square blue button to stop the process and lose the recording.
6. That would be nice to be able to access those audio files on our phones if not complicated to implement (after granting access to a specific folder) because the share button in History only shares the text.
7. OK I will share my settings by email if your new update does not solve this problem.
   OpenWhispr just released today an iOS app by the way if you want to try it.
   Thanks!