Two camera recording duration mismatch: diagnose the cause

Two hardware-triggered cameras can produce videos with different lengths even when they captured the same events. The difference may come from playback settings, missed triggers, incomplete transfers, or frames left unwritten during shutdown. A moving preview does not prove that recording continues. For a two camera recording duration mismatch, start by measuring each boundary separately: trigger delivery, camera acquisition, host reception, disk writing, and playback. This lets you correct the failing stage instead of changing several settings at once.

Separate acquisition time from playback time

A recording has several different time measurements. Keep them separate throughout the investigation:

• Session time: elapsed time between the application's coordinated start and stop boundaries.
• Capture span: time between the first and last captured frames, using suitable frame timestamps.
• Playback duration: the time a player takes to display the encoded frames.

For a constant-frame-rate file, playback duration follows the encoded frame count and playback frame rate. It does not necessarily follow the camera's trigger timing.

The capture-rate estimate assumes consecutive frames without missing samples. Timestamp subtraction also requires a continuous clock with known units and no unhandled rollover or reset.

Do not subtract timestamps from different cameras unless their clocks share a verified timebase. A common hardware trigger can coordinate exposure without synchronizing the cameras' timestamp clocks.

Begin with file frame counts and timestamps, not the duration displayed by a media player. The related recording throughput and dropped-frame guide covers sustained recording capacity; the first question here is whether frames are missing at all.

Build an evidence log before changing settings

Create a separate record for each camera and each recording session. Store the session identifier, camera identifier, configuration readback, first and last frame metadata, counter snapshots, writer settings, and error messages.

Useful counters include trigger pulses measured at the input, camera exposure counts where available, received frames, frames submitted to the writer, and frames confirmed written. Record exactly what each counter means. A host acquisition counter may include preview traffic or may reset when acquisition restarts.

These are diagnostic directions, not proof by themselves. Some cameras expose no exposure counter, and some writers report accepted frames rather than durable writes. Use documented counter definitions and validate the final file independently.

Run a small acquisition-only test outside the graphical interface. Keep the trigger source, image format, and recording destination unchanged so the comparison isolates application behavior.

Check trigger delivery and camera readiness

A software frame-rate setting does not establish the actual capture rate under external frame triggering. Depending on configuration, that setting may limit operation, become inactive, or interact with camera timing. Read back the active trigger selector, source, edge, exposure, and acquisition state.

Measure the signal at each camera input with appropriately rated test equipment. A count at the trigger generator does not prove both inputs received valid pulses. Check input voltage requirements, pulse width, polarity, grounding arrangements, and permitted loading against the camera documentation.

The external-trigger frame-rate diagnostic explains how to separate requested pulses from accepted exposures. If only one input responds consistently, use the trigger common-reference checks before changing software timing.

For a hypothetical test, 30 pulses per second over a defined 600-second gate gives:

Define the gate boundaries carefully. A pulse exactly at an opening or closing boundary can change the expected count. A counted pulse burst is often easier to verify than an operator-timed interval.

Both cameras must be ready before the first pulse. Sequential start calls can work when they only arm acquisition and pulses remain disabled until both cameras report readiness. Sequential starts while pulses are already present create unequal recording beginnings.

Verify the playback timebase with a worked example

Suppose both files contain 18,000 frames captured at a regular 30 frames per second. One writer encodes its file at 30 frames per second; the other uses 60 frames per second.

The second file plays twice as fast even though neither camera lost a frame. The small difference between capture span and playback duration comes from counting intervals between frame timestamps rather than display intervals for every frame.

Set the intended playback rate explicitly on each writer before recording begins, following its documented lifecycle. Read back both settings rather than assuming a shared variable updated both objects. Do not assume a camera acquisition setting automatically configures the video writer.

Inspect the completed files with a tool that reports encoded frame count, nominal frame rate, and presentation timestamps where available. Some container formats and writers use per-frame timing rather than one fixed playback rate.

Now consider a different result: one file contains only 13,500 frames. At 30 frames per second, playback lasts 450 seconds. That discrepancy requires tracing missing frames through the counters; changing playback rate would only hide it.

For irregular triggers, preserve acquisition timestamps in a sidecar record. A constant-frame-rate export cannot represent variable capture intervals faithfully unless the export process explicitly maps those intervals into playback timing.

Stop both streams before draining the writers

A common shutdown error is waiting for a writer to catch up while acquisition continues producing new frames. The target keeps moving. Another is stopping one camera, draining its queue, and only then stopping the other camera.

Use a coordinated shutdown sequence based on the documented behavior of your acquisition library:

1. Prevent new recording requests and record the stop request time.
2. Stop the dedicated acquisition pulse source, if your design controls it, or issue the documented coordinated acquisition stop.
3. Allow in-flight exposures and transfers to complete through the documented graceful-stop procedure.
4. Confirm that no further frames will enter either recording queue, then snapshot the final received counts.
5. Drain both writer queues while monitoring progress and errors.
6. Finalize both files only after their writers have completed successfully.
7. Reopen the files and compare encoded counts with the session's recorded counts.

Some stop or abort operations discard buffered frames. Confirm the distinction before choosing an API call. Keep receive processing active for as long as the library requires to deliver pending frames.

Use bounded waits, not indefinite equality loops. For example, a diagnostic timeout of 10 seconds should report the remaining backlog and writer state. That value is an application choice, not a universal drain-time guarantee.

Stopping preview is not the same as stopping acquisition or closing a writer. Track those states independently. For callback and queue ownership problems, see multi-camera acquisition freezes and buffer queues.

Make restart a fresh, coordinated session

Treat restart as a state transition, not simply another start call. A reliable sequence is idle, configured, armed, recording, stopping, draining, and finalized. Block incompatible button actions while a transition is incomplete.

Before each restart, verify that both previous writers are closed and both acquisition objects are in the expected state. Create distinct output files and a new session identifier. Reset session counters or store counter offsets where lifetime counters cannot be reset.

Read back the settings that matter: trigger mode, selected input, exposure, pixel format, image dimensions, and writer playback rate. The startup settings and readback checks provide a useful pattern for separating stored configuration from active configuration.

Clear stale queued frames only through a documented procedure, before the new session begins. Otherwise, a new file can start with frames belonging to the previous session.

Log every automatic rearm, timeout, and error callback. If a recording status returns to a waiting state at a repeatable time, inspect finite frame limits, repeat counts, timers, and state-machine transitions. The displayed message alone cannot establish which component stopped.

Repeat the complete lifecycle several times during diagnosis. A successful first recording does not validate cleanup and restart behavior.

Isolate transfer limits from writer limits

Test one camera at a time, then both together. Compare reception-only operation, recording without preview, and full operation. Keep image dimensions, pixel format, and trigger frequency fixed between these tests.

For a hypothetical uncompressed image of 1920 × 1200 pixels with one byte per pixel:

These are image-payload estimates using decimal byte units. Transport overhead, container overhead, metadata, and encoding costs are additional. Compression can reduce output size while increasing processing load.

Watch queue growth, memory use, transport errors, and sustained write rate. If a queue grows throughout recording, buffering is postponing failure rather than solving it. If a host timestamp gap appears without a camera timestamp gap, investigate delivery or callback scheduling before concluding that exposure stopped.

Check whether both camera links share a constrained network path or host controller. A connector count does not establish independent bandwidth. Avoid storing long recordings in memory merely to make the disk test disappear.

When failures persist outside the interface, follow the broader intermittent acquisition failure checks. If behavior changes after a software deployment, also check camera SDK build compatibility.

Choose replacement hardware only after locating the fault

Do not replace a camera because two players report different durations. Hardware selection becomes relevant after measurements identify insufficient acquisition capability, transport capacity, or an unsuitable connection.

Browse area scan cameras and use the camera finder to compare interfaces and acquisition requirements. The LS-CMR-0053 and LS-CMR-0166 illustrate different interface options, not an interchangeable synchronized pair.

All 2 share: Sensor size 1/1.7". Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Confirm hardware-trigger support, input electrical requirements, timestamp facilities, and achievable frame rate for the exact operating configuration. The catalog comparison alone does not establish those capabilities or suitability for the worked example.

Inspect camera cables and the accessory finder when measurements point to a physical connection issue. The LS-CBL-0199 is a GigE camera cable example.

The LS-CBL-0218 is a USB3.0 camera cable example.

Choose the interface that matches the actual camera and host connection. Connector fit, retention, cable routing, permitted length, and motion requirements still need verification. A data cable does not replace a separate trigger or power connection unless the documented system design provides those functions.

Validate the fix across complete recording sessions

Use a short test with a known trigger count, followed by a longer run beyond the previous failure point. Then repeat the full stop, finalize, and restart sequence.

• Confirm both cameras were ready before the first acquisition pulse.
• Compare trigger, exposure, received, submitted, and written counts wherever available.
• Check first and last captured events, not just displayed durations.
• Inspect timestamp gaps and document any counter resets.
• Verify playback settings independently for both completed files.
• Confirm writer backlogs reach zero before successful finalization.
• Check that memory and queue sizes do not keep increasing.
• Repeat after an application restart to expose configuration assumptions.

Acceptance should cover both data completeness and timing correctness. Matching durations alone can conceal identical frame loss, while matching frame counts can conceal different captured intervals.

If hardware changes remain necessary, start with the camera configurator. For an unresolved mismatch, send the counter log, timestamp samples, configuration readback, and file metadata through applications support so the next test targets the failing boundary.