Report
A user reports recurring computer/call freezing while Screenpipe is recording during Zoom, Google Meet and Microsoft Teams calls. Quitting Screenpipe reportedly restores responsiveness. This is a customer report, not a controlled reproduction; the precise freeze duration and triggering call timestamp are not yet known.
Environment:
- MacBook Pro, M5 Pro, 64 GB RAM, as reported by the user.
- Screenpipe 2.7.76 and macOS 26.5.1, verified from the current device registration and its fulfilled diagnostic upload.
- Screenpipe Cloud transcription with Auto selected, as reported by the user.
Sanitized diagnostic findings
A fresh, consent-checked diagnostic upload was retrieved and matched to the requesting account/device. Only technical summaries are included here.
- Five worker panics in the retained panic log with the same signature:
thread: screenpipe-worker
range start is greater than range end in BTreeMap
screenpipe_db::db::frames::DatabaseManager::find_video_chunks_limited
screenpipe_engine::server::SCServer::create_router_inner
- Seven slow frame-fallback SQL statements, approximately 11.76–13.68 seconds each, plus one 1.23-second COMMIT. Query text, parameters and captured content are omitted.
- Five built-in microphone input gaps, approximately 94–121 ms versus an expected 5.3 ms callback interval, followed by silence insertion.
These observations do not establish the cause of the system-wide meeting freeze. The bounded application-log tails cover roughly ten minutes after the report and a short window from the previous day. Panic entries use timestamps without an explicit UTC offset. There is no incident-aligned CPU/RSS/WindowServer sample, spindump, or validated freeze timestamp in this bundle. Audio gaps may be a symptom rather than the cause. Unrelated automation/account messages are excluded.
Code lead and existing work
The installed release's frame-query implementation derives audio start/end bounds and passes a padded range to BTreeMap::range without checking that the bounds are ordered. This is consistent with the observed panic signature, but the original offending row has not been inspected or reproduced.
Open draft #7335 includes malformed audio-offset handling and timeline cache warm-up recovery. Check that work against this signature instead of duplicating it. Its presence in a draft does not establish a shipped fix or recovery for this report. A timeline panic fix alone must not be treated as proof that the meeting-time system freeze is resolved.
Investigation and acceptance
- Reproduce with synthetic call content on comparable Apple Silicon hardware, with recording and Cloud/Auto transcription enabled. Compare each reported meeting app and recording-off control. Treat these as proposed reproduction steps, not a verified recipe.
- Capture a precise freeze interval and simultaneous Screenpipe, WindowServer and audio-service CPU/memory/stack samples. Correlate capture/audio activity, database query latency and worker panics.
- Add a synthetic regression for reversed or otherwise malformed audio segment bounds through the real frame/timeline request path. It must return without panic or an indefinitely waiting request and preserve recoverable transcript data.
- Verify representative meetings remain responsive and recordings continue after the candidate fix. Keep the system-freeze report open until that behavior is validated.
Privacy
No customer identity, organization, account/device IDs, private file paths, meeting content, prompts, billing details, raw diagnostic attachment or signed download URL is published here. Diagnostics remain in the private support system.
Report
A user reports recurring computer/call freezing while Screenpipe is recording during Zoom, Google Meet and Microsoft Teams calls. Quitting Screenpipe reportedly restores responsiveness. This is a customer report, not a controlled reproduction; the precise freeze duration and triggering call timestamp are not yet known.
Environment:
Sanitized diagnostic findings
A fresh, consent-checked diagnostic upload was retrieved and matched to the requesting account/device. Only technical summaries are included here.
These observations do not establish the cause of the system-wide meeting freeze. The bounded application-log tails cover roughly ten minutes after the report and a short window from the previous day. Panic entries use timestamps without an explicit UTC offset. There is no incident-aligned CPU/RSS/WindowServer sample, spindump, or validated freeze timestamp in this bundle. Audio gaps may be a symptom rather than the cause. Unrelated automation/account messages are excluded.
Code lead and existing work
The installed release's frame-query implementation derives audio start/end bounds and passes a padded range to
BTreeMap::rangewithout checking that the bounds are ordered. This is consistent with the observed panic signature, but the original offending row has not been inspected or reproduced.Open draft #7335 includes malformed audio-offset handling and timeline cache warm-up recovery. Check that work against this signature instead of duplicating it. Its presence in a draft does not establish a shipped fix or recovery for this report. A timeline panic fix alone must not be treated as proof that the meeting-time system freeze is resolved.
Investigation and acceptance
Privacy
No customer identity, organization, account/device IDs, private file paths, meeting content, prompts, billing details, raw diagnostic attachment or signed download URL is published here. Diagnostics remain in the private support system.