v0.26.1

What changed and why

Take this release if you are on 0.25.2 or 0.26.0 and use a GigE camera.

0.25.2 made every single grab issue AcquisitionStop when it finished. That fixed a real defect — a
camera whose acquisition mode stayed locked for the rest of the session — but it broke single grabs
outright on any device that restarts frame numbering after acquisition stops.

GrabOne discards a received frame that is not newer than the last one emitted; that is how it
refuses a stale frame left over from an earlier acquisition. The baseline it compares against was
reset in exactly one place: when the stream is opened. Once every grab ended with a stop, a device
that begins numbering again from the start would hand the next grab a frame that looks older, so
the filter threw it away and waited for a number that was never coming, until the deadline expired.
Only the first grab of a session worked, because its baseline is still zero and the filter is off.

Measured on the line by a consumer — Crevis MG-A320K-35, firmware 3.6.2.9, two cameras: 1 of 30
grabs succeeded on 0.26.0 against 30 of 30 on 0.22.0. The camera was not at fault and the
health counters say so: CompletedFrames = 30, no losses. The device sent all thirty frames and the
stream received them. We discarded them.

The fix is to drop the baseline wherever acquisition stops — in the single grab's teardown and in
StopContinuous. A stop is precisely the event that makes the comparison meaningless: continuity of
numbering across it is not guaranteed, and some devices do restart. Without a trustworthy baseline
the next frame is accepted whatever its number, which is what the first frame of a session already
does. The dropped-frame counter is cut at the same point, since a gap that spans a stop is not a
loss.

Continuous acquisition was never affected: the pump does not stop between frames, so numbering
continues.

Why this was not caught before release. 0.25.2 shipped with an explicit note that its fix could
not be verified on the camera available here — a Basler acA2500-14gm, which does not lock the
acquisition mode and does not restart numbering, so both the original defect and this regression are
invisible on it. That note was accurate about what had been measured and still understated the risk:
the thing the camera could not show turned out to be not the fix working, but the fix breaking
something else. The corrected build was run against the same camera to confirm it changes nothing
there (four grabs, four frames).

Version

0.26.1 — patch. No public API change; one defect fix.

Checks

• dotnet build in the default configuration reports 0 warnings
• main is an ancestor of this branch (the release-pr-guard job verifies it)
• the tag will be created on the merge commit, main merged back into dev afterwards, and dev bumped to the next -dev version