Summary

Several users report a meeting/call that "was recording" (overlay active, Timeline filling) but whose saved transcript ends up empty or only partial. Their diagnostic bundles show this is not a capture failure. Audio is captured; the batch transcription path fails and the backlog never drains.

The batch path POSTs audio to the Screenpipe Cloud proxy at https://api.screenpipe.com/v1/listen. Under load these requests intermittently fail with a TCP reset:

ERROR screenpipe_audio::transcription::deepgram::batch: device: System Audio, failed to send request to Deepgram API: reqwest::Error { kind: Request, url: "https://api.screenpipe.com/v1/listen?model=nova-3&smart_format=true&sample_rate=16000&diarize=true&utterances=true&language=en&keyterm=<redacted>", source: hyper_util::client::legacy::Error(SendRequest, hyper::Error(Io, Os { code: 54, kind: ConnectionReset, message: "Connection reset by peer" })) }
ERROR screenpipe_audio::audio_manager::reconciliation: reconciliation: transcription failed for batch: Failed to send request to Deepgram API: ... Connection reset by peer

The live meeting path is a separate WebSocket (meeting_streaming::deepgram_live, provider screenpipe-cloud) and is unaffected. That is why the live Timeline fills during the call while the persisted transcript is gutted (the live vs persisted gap).

When these resets happen, chunks pile into the backlog and the health check warns:

WARN screenpipe_engine::routes::health: health_check: audio transcription backlog stalled — 84 chunk(s) pending, oldest 2482s old | pool: read=10/10 idle, write=2/2 idle

Observed

• Reproduced across app versions 2.4.306, 2.4.308, 2.4.311 and 2.5.4 for one user, and on a second unrelated user's machine.
• The proxy is reachable when probed idle (it returns an HTTP response rather than resetting), so this looks like load or concurrency behavior on the proxy, not a full outage.

Suspected cause

• Server side: the screenpipe-ai-proxy worker resetting connections on larger or concurrent batch audio POSTs (request body size or duration limit, or upstream connection handling).
• Client side: a single failed POST strands the batch with no retry, so it sits in the backlog indefinitely.

Suggested fix

• Proxy: investigate connection resets on /v1/listen under concurrent batch load (body size and time limits, keep-alive, upstream handling).
• Client: retry batch transcription with backoff on transient network errors (connection reset, timeout) instead of dropping the batch into a non-draining backlog.

User symptoms this explains

"overlay showed recording but nothing was recorded", "Timeline shows 10 to 12 min but the transcript only shows 6 min", "recorded my voice only, not the participants".

Related: closed #3498 (reconciliation worker silently stops) is the other backlog mechanism and is recurring again on 2.5.4. Device and acoustic issues: #3750, #3228, #3144.

Source: triage of in-app Help to "send logs" submissions, Jun 2 to Jun 5 2026. Diagnostic detail taken from user log bundles, PII redacted.