hydroclipsMeasure the stage that is slow#
| Stage | Useful evidence |
|---|---|
| Startup | Time until a completed segment; selected encoder and DXGI/GDI capture method. |
| Buffering | Available seconds increasing, steady CPU/GPU load and no segment errors. |
| Finalization | Time from save request to MP4 publication and clip event. |
| Plugin dispatch | Whether disabling an optional plugin changes save latency. |
| Upload | Drive status after the local clip already exists. |
Buffer duration is the amount of retained history, not the time required to save a clip. A long replay can finalize quickly because the engine copies encoded media. Upload time is a separate network operation.
Why native exports became faster#
The encoder probe now uses a real 640×360 sample that the hardware accepts. Segment metadata is cached, snapshots use hard links when possible, and finalization copies existing compressed video instead of re-encoding the entire requested interval.
On the development RTX 4060 machine, a roughly eight-minute export that previously took about 115 seconds was reproduced through the revised path in about 2.7 seconds. Shorter real native saves completed in roughly 0.8–1.3 seconds in separate checks. These are observations from that machine and workload, not a promised latency for every computer.
Disk speed, clip size, cross-volume copies, encoder fallback and plugins still affect results. Compare like-for-like duration and settings when testing.
Reduce capture pressure#
Confirm a working hardware encoder such as NVIDIA NVENC, Intel QSV or AMD AMF before increasing FPS, resolution or bitrate. If CPU libx264 is selected, higher capture settings can consume substantially more CPU. DXGI and GDI have different capture overhead; inspect the selected method rather than assuming the preferred path started.
Choose a local output directory with enough free space. The default 16 Mbit/s video stream alone is roughly 120 MB per minute, with additional audio and container overhead. Temporary snapshots and output files can require extra space during export.
Changing capture settings resets the current buffer. Save needed history before experimenting, and allow the new buffer to warm up.
Read the relevant failure#
| Symptom | Next check |
|---|---|
| Replay is shorter than requested | Warm-up history and latest completed segment; check availableSeconds. |
| Save remains pending | FFmpeg stderr, output permissions and awaited plugin hooks. |
| High CPU usage | Selected encoder, capture method, resolution and FPS. |
| Silent microphone | Windows default device, mute/gate mode and audio helper errors. |
| Black area behind interface | Use the 2.0.7 normal host; its region must follow sidebar and rounded drawer. |
| Repeated or unresponsive commands | Ordered bridge transport, shortcut debounce and a long-running plugin action. |
The main diagnostic file is %APPDATA%\Hydro Clips\native.log. Capture a short excerpt around the failing operation and include the native version, encoder and operation type.
Keep plugin work out of export delays#
Clip hooks are awaited. A long filesystem read or network promise returned from onClipSaved directly extends the serialized save operation. Use bounded optional background work with its own catch handler; unhandled failures and unbounded queues are not a performance fix.
The webhook guide explains the distinction between a wait deadline and cancellation. The plugin debugging guide provides a small isolation sequence.
Implementation reference: src/native/recorder.ts; src/main/plugins/PluginManager.ts; native/Program.cs · native 2.0.7.