[bug] Very Slow General Windows OS Performance While Recording

AI assistance:

• AI tool(s) used: Screenpipe assistant / AI coding assistant
• Autonomy level: agent
• What you personally verified: I personally reproduced the performance issue while Screenpipe recording was enabled. I tested reduced capture settings, including 1080p/lowest quality/Light FPS, with audio recording disabled. The cursor and general Windows desktop remained sluggish. I also personally reviewed the Screenpipe logs and health output.
• I personally submitted this issue; its problem statement and rationale are my own.

describe the bug

Screenpipe causes significant mouse-cursor lag and general Windows desktop sluggishness while recording.

The problem persists even after reducing recording to 1080p, lowest quality, and Light FPS, with audio recording disabled. The performance degradation returns when recording starts and is not resolved by reducing video workload.

The logs suggest a capture/database pipeline stall rather than ordinary high-resolution encoding overhead:

• Screenpipe reports that high-FPS capture is unsupported and falls back to event-driven capture.
• Actual capture rate falls to approximately 0.039 FPS.
• A SQLite WAL backlog reached approximately 40,368 pending pages, with only 795 pages checkpointed.
• Screenpipe requested a database lifecycle recovery/restart because of the WAL backlog.
• Several database operations took between approximately 1.3 and 16.8 seconds.
• Windows low-level input hooks were reinstalled after callbacks became silent, reportedly because of Windows LowLevelHooksTimeout.
• Windows OCR also reports Cannot change thread mode after it is set. (0x80010106).

system info

• OS: Windows 11 Pro, x64
• Screenpipe version: 2.7.42
• Screenpipe CLI/engine version: 0.4.50
• CPU: AMD Ryzen 9 7950X
• GPU: nVidia GTX1060 6GB (plus AMD iGPU for desktop)
• RAM: 64GB DDR5
• Display: 5120×2160
• Capture path reported by logs: Event-driven capture
• Audio: Disabled during the latest reproduction test
• Storage: Approximately 52.6 GB used; disk space is not critically low

additional context

The issue began ~last week. The same general setup was previously usable without severe cursor or desktop lag.

Reproduction

1. Start Screenpipe recording.
2. Use reduced settings:
   • 1080p
   • Lowest capture quality
   • Light FPS
   • Audio recording disabled
3. Move the mouse and use normal Windows applications.
4. Observe severe cursor and general desktop sluggishness.
5. Observe increased CPU usage (locks to about ~28%) with few other processes contributing
6. Stop Screenpipe recording; responsiveness improves, CPU usage drops

Relevant log findings

Screenpipe reports:

high-fps capture not supported on this platform
event-driven capture started

Health data showed approximately:

frames_captured: 3
capture_fps_actual: 0.0387
frames_dropped: 0

The absence of dropped frames combined with the extremely low capture rate suggests that the pipeline is becoming blocked or taking too long to complete each capture cycle.

The database reported:

passive wal checkpoint left 40368 pages pending
log=41163, checkpointed=795

Screenpipe then requested recovery:

database lifecycle recovery requested - restarting recording
reason=WalBacklog

Slow database operations included:

• Frame query: approximately 3.46 seconds
• SQLite quick check: approximately 16.84 seconds
• Frame query: approximately 2.01 seconds
• UI-event query: approximately 1.26 seconds
• Activity-summary query: approximately 1.27 seconds

The input-hook watchdog reported:

LL input hooks reinstalled by watchdog
hooks likely removed by Windows LowLevelHooksTimeout

This occurred twice. One recorded silent period was approximately 1 hour and 54 minutes.

Windows OCR also reported:

windows OCR failed:
Cannot change thread mode after it is set. (0x80010106)

Even with reduced capture settings, Screenpipe starts several processing workers, including text PII redaction, image redaction, accessibility/UI-event reconciliation, and semantic projection. The Screenpipe process reached approximately 1.6 GB of memory and more than 300 threads.

Potential areas for investigation:

1. Why is the Windows high-FPS capture path unavailable?
2. Why does event-driven capture fall to approximately 0.039 FPS?
3. Why does the SQLite WAL accumulate over 40,000 pending pages?
4. Can capture be tested without redaction, semantic processing, or accessibility/input hooks?
5. Can input-hook processing be isolated from database and redaction workloads?
6. Is this a regression in Screenpipe 2.7.42 on Windows 11?
7. Is the OCR COM-thread error related to the capture or input-hook stalls?
8. Can Activity History stop retrying a model that consistently returns HTTP 403?

Logs have been submitted with #7059 in the description (Submission #397afafb-73d5-4565-9ed5-eb0cd959cf80).