Hi Joan,
I just upgraded from 2023.1.1 to 2025.2 and am experiencing an issue where the replay speed steps down after every capture. I didn't experience this in 2023.1.1. (By the way, thanks for including a setting to set the capture camera as Armed on startup - that was a request of mine many months ago.)
This may be the reproduction case for what bnord reported in the 2025.1 thread (posts #5 and #7). Same symptom, but on hardware that is clearly not resource limited, and with the playback cache configured but apparently never used. The cache part seems like the more useful signal.
SYSTEM
Kinovea 2025.2.0
Windows 11
AMD Ryzen 7 5800X (8 core, 3.8 GHz)
16 GB RAM
NVIDIA RTX 3070
All windows displayed on a single 60 Hz TV
SETUP
Golf simulator. Four separate Kinovea instances: two capture (face-on and down-the-line), two playback running as replay folder observers. Each camera writes to its own local folder. Storage is a local drive, not cloud synced. No default annotation file for capture or playback.
CAMERAS
Both identical: 1280x720 @ 100 fps, MJPG, DirectShow.
Capture infobar during recording, both instances:
Signal: 98.71 and 98.83 fps
Throughput: 336 and 386 MB/s
Load: 0%
Drops: 0
SETTINGS
Capture > General: Record uncompressed unchecked, MP4, display framerate 20
Capture > Memory: delay buffers 1021 MB
Capture > Recording: Delayed, threshold 99, replacement framerate 60
Capture screen: delay 1.50 s, duration 2.50 s
Playback > Memory: cache 2998 MB per playback screen
PRIMARY ISSUE: THE WORKING ZONE NEVER CACHES
Kinogram is greyed out on every clip, which I understand means the working zone did not load into memory.
It should fit comfortably. Throughput divided by frame rate gives roughly 3.7 MB per frame (1280 x 720 x 4 bytes). A 2.5 second clip at 100 fps is 250 frames, about 925 MB. The cache is set to 2998 MB per playback screen, and since these are separate instances each should get its own full allocation.
Task Manager with all four instances running and videos loaded:
Kinovea 138.5 MB, 7.9% CPU
Kinovea 127.8 MB, 8.3% CPU
Kinovea 141.9 MB, 7.0% CPU
Kinovea 132.1 MB, 7.6% CPU
System memory 62% total, CPU 43% total (includes GSPro and a browser). Each instance holds around 135 MB against a permitted 2998 MB, with several GB free system wide.
So the cache is configured, memory is available, the clip should fit, and nothing loads. If frames were being decompressed in advance I would not expect the player to fall behind at all on this hardware.
SECONDARY ISSUE: SPEED STEPS DOWN
The speed slider steps down roughly 5% at a time across successive recordings in the replay observer. It does not recover. Before a clean reinstall it would reach 0% and stop playing. After the reinstall it settles rather than bottoming out, but still drifts down over a session.
The effect scales with declared framerate. At replacement framerate 15 playback is completely smooth and stable with no stepping. At 40 and above it steps down. This looks proportional to rendering load, which is consistent with frames being decoded live rather than served from cache.
RULED OUT
Full uninstall and clean reinstall of 2025.2.0, no change to the caching behavior
Working zone trimmed to roughly one second, still would not cache
Record uncompressed unchecked, output confirmed .mp4 rather than .mkv
Separate local output folders per camera, neither cloud synced
No default annotation file
Display framerate reduced to 20
Capture side clean: 0% load, 0 drops on both cameras
CPU and RAM not saturated
Happy to run any test, or send logs or a sample file.
Thanks for the continued work on 2025.x.