Summary

Audio recording silently dies mid-session when a Bluetooth input device
(AirPods Pro) is released by one app and reacquired by another (e.g.
two consecutive Proton Meet calls). Screenpipe's UI shows audio is still
ON, the audio pipeline reports no errors, but no audio chunks are
created and no transcriptions are produced. The result: an entire
meeting can be lost without any warning to the user.

Environment

• Screenpipe version: 0.3.285
• macOS (Apple Silicon)
• Bluetooth input device: AirPods Pro
• App causing the device handoff: Proton Meet (web app via Safari)

Reproduction

1. Start Screenpipe, ensure Audio Recording is ON
2. Connect AirPods Pro
3. Join a video call (Proton Meet, Google Meet, etc.) → audio captured normally
4. Hang up the call. AirPods stay connected to the Mac.
5. Within ~1 minute, join a new video call on the same app
6. Speak for 10+ minutes
7. End the call

Expected

Both calls should be captured in audio_transcriptions.

Actual

Looking at the SQLite DB:

• Call 1: ~80+ audio_chunks created, ~150 transcriptions, full coverage
• Between calls: no chunks (normal)
• Call 2: only 1 audio_chunk created at the very start, then nothing for the entire remainder of the call
• 0 transcriptions for call 2

The Screenpipe UI continues to show "Audio Recording: ON".
The health-check endpoint reports no errors.
device_status_details shows the device as "active".
Only by checking the actual audio_chunks table do you discover
the data is missing.

Evidence from logs

2026-04-29T16:09:53Z last audio_transcription before silence
2026-04-29T16:10:19Z ONE AirPods chunk created (start of call 2)
2026-04-29T16:10:20Z → 16:31:00Z (call 2 in progress) — silence
2026-04-29T16:39:49Z stopped recording for AirPods (this was 8 min AFTER call 2 ended)
2026-04-29T16:40:15Z user finally toggles disableAudio:true

Impact

This is a "silent failure" — the most dangerous kind. Users who rely
on Screenpipe to record their meetings can lose entire conversations
without any indication. They only discover the loss when they later
try to retrieve the transcription.

Suspected root cause

When Proton Meet (or any app) releases the AirPods at the end of call
1 and reacquires them for call 2, the underlying CoreAudio input
stream Screenpipe was reading is killed. Screenpipe's audio_manager
appears not to detect the dead stream and keeps the device marked as
"active" while producing nothing.

Suggested fixes

1. Watchdog: if audio_devices contains an active device but no
   chunks are written for >60s while screen recording shows an active
   meeting app (Zoom, Meet, Proton Meet, etc.), surface a warning toast
2. Stream resilience: detect dead CoreAudio input streams and
   reacquire them automatically
3. Health check: a more granular audio_status value, e.g.
   "active_no_data", to flag this exact condition instead of
   reporting "ok"

Workaround for users

After hanging up a call, manually toggle Audio Recording OFF then
ON in Settings before joining the next call, to force Screenpipe to
reacquire a fresh audio stream.