## System details

Dell XPS (Panther Lake), Intel Core Ultra X7 358H, Intel Arc B390 (integrated), Omarchy 4.0.3-1 stable, kernel 7.2.3-arch1-1-ptl, `intel-ipu7-camera` 1.0.5-1. Webcam is the OV08X40 behind Intel IPU7, exposed to userspace as the v4l2loopback node `/dev/video50` fed by `v4l2-relayd@ipu7`.

## What's wrong?

When the webcam device opens but never delivers a frame, `omarchy capture screenrecording --with-webcam` leaves a frozen mpv `WebcamOverlay` window on screen that Omarchy cannot remove, and the user has no supported way to get rid of it.

### Steps to reproduce

1. Have a camera device that opens but produces no frames. Any IPU6/IPU7 machine hit by #10837 does this today: `v4l2-relayd` opens the loopback, its `icamerasrc` pipeline fails, so readers of `/dev/video50` block forever. `timeout 5 v4l2-ctl -d /dev/video50 --stream-mmap --stream-count=3` hanging until the timeout is enough to confirm the precondition.
2. `Super + Space` → capture → screen recording with webcam (or `omarchy capture screenrecording with webcam`).
3. Record for a while, then stop with the same binding or `omarchy capture screenrecording --stop-recording`.

### Observed

- The recording itself is fine. The mp4 is saved with video and audio and the "Screen recording saved" toast appears.
- The overlay window (178x200, title `WebcamOverlay`, app-id `WebcamOverlay-medium`) stays on screen, black, pinned in its corner.
- Running `--stop-recording` again does nothing: `screenrecording_active` is false (gpu-screen-recorder already exited), so the script hits the `elif [[ $STOP_RECORDING == "true" ]]` branch and exits 1 without touching the overlay (`omarchy-capture-screenrecording` lines 284-285).
- The stuck mpv also holds `/dev/video50` open, so every other camera consumer gets `VIDIOC_REQBUFS returned -1 (Device or resource busy)` until it is killed.

Only `kill -9` removes it:

```
$ pgrep -af '^mpv'
1043170 mpv av://v4l2:/dev/video50 --profile=low-latency --untimed --no-cache --demuxer-lavf-o=video_size=1920x1080,framerate=30 --vf=lavfi=[crop=ih*8/9:ih] --title=WebcamOverlay --wayland-app-id=WebcamOverlay-medium --no-border --no-audio --no-osc --osd-level=0 --really-quiet
$ kill 1043170; sleep 1; pgrep -af '^mpv' | wc -l
1
$ kill -9 1043170; sleep 1; pgrep -af '^mpv' | wc -l
0
```

### Expected

Stopping the recording removes the overlay unconditionally, and an overlay whose camera never produces a frame gives up on its own with a notification instead of sitting there black.

### Cause

Two things in `bin/omarchy-capture-screenrecording`:

1. `cleanup_webcam` (line 110-111) is only `pkill -f "WebcamOverlay"`, i.e. SIGTERM. mpv blocked inside the v4l2 demuxer open/read never gets back to its event loop to honour it. `stop_screenrecording` does call `cleanup_webcam`, so the intent is right; the signal is just not strong enough for this state.
2. `start_webcam_overlay` (line 86-93) launches mpv with no timeout on the first frame. It waits up to 2 s for the Hyprland client to *map*, which succeeds because mpv creates its window before it has any video, and then proceeds. Nothing later checks that frames ever arrived.

Side note for anyone reproducing: `pkill -f WebcamOverlay` from an interactive shell also matches the shell's own command line and kills it. `pkill -9 -f '^mpv.*WebcamOverlay'` is the safe form.

### Suggested fix

- In `cleanup_webcam`, escalate: `pkill -f '^mpv.*WebcamOverlay'`, wait briefly, then `pkill -9 -f '^mpv.*WebcamOverlay'` if it is still alive. That alone fixes the "can't quit it" half.
- Make the `--stop-recording` branch run `cleanup_webcam` even when no recorder is active, so a second press always clears leftovers.
- Optionally, in `start_webcam_overlay`, probe the device for a frame before launching mpv (e.g. `timeout 3 v4l2-ctl -d "$WEBCAM_DEVICE" --stream-mmap --stream-count=1`) and fall back to recording without the overlay plus a notification if it times out.

The underlying "camera delivers nothing" condition on this machine is the jsoncpp soname break tracked in #10837, plus a separate ov08x40 sensor-binding regression on kernel 7.2 that is filed against intel/ipu7-drivers. This report is only about the screenrecording script's handling of that state, which will recur with any dead camera device.

Reported with the help of Claude Code.