Continue video clip indices after existing files

[diegoferigo-rai]

Description

VideoRecorder starts its clip index at zero on every new process, so a run that records into a directory that already holds clips overwrites clip_0000.mp4 onward. This scans the output directory for existing <prefix>_<N>.mp4 files and continues the clip index after the highest one, so successive runs into the same directory no longer clobber earlier recordings.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Release backport

• Backport this pull request to the active release branch after it merges into develop

Checklist

• I have read and understood the contribution guidelines
• I have run the pre-commit checks with ./isaaclab.sh --format
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have added a changelog fragment under source/<pkg>/changelog.d/ for every touched package
• I have added my name to the CONTRIBUTORS.md or my name already exists there

[greptile-apps]

Greptile Summary

The PR prevents sequential recorder processes from overwriting existing clips by initializing the clip counter after the largest matching filename.

• Adds prefix-aware scanning of existing MP4 filenames during recorder initialization.
• Adds unit coverage for populated and empty output directories.
• Adds a changelog entry and contributor attribution.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking scalability issue when a reused directory contains an unusually large sparse clip index and retention pruning is enabled.

Existing filenames can now initialize the counter to an arbitrarily large value, while retention cleanup still enumerates every lower integer rather than only existing files.

Files Needing Attention: source/isaaclab/isaaclab/envs/utils/video_recorder.py

Important Files Changed

Filename	Overview
source/isaaclab/isaaclab/envs/utils/video_recorder.py	Continues numbering after existing clips, but a sparse high index can make range-based retention cleanup perform an effectively unbounded number of filesystem operations.
source/isaaclab/test/envs/test_video_recorder.py	Covers selecting the next index from matching files and retaining zero for an empty directory.
source/isaaclab/changelog.d/video-recorder-continue-indices.rst	Accurately documents the overwrite-prevention fix.

_{Reviews (1): Last reviewed commit: "Continue video clip indices after existi..." | Re-trigger Greptile}

[isaaclab-review-bot]

Isaac Lab Review Bot

The change seeds VideoRecorder clip numbering from the highest existing matching <prefix>_<index>.mp4 file, preventing successive processes from restarting at zero. Focused tests cover sparse matching files, ignored non-matching files, and an empty output directory; release metadata is included.

• Design and architecture: Index discovery remains within the recorder’s existing filesystem boundary and reuses _effective_output_dir() and the established filename convention. _close_clip() continues incrementing the seeded index through the existing path without broader architectural changes.
• API: No public API is added or removed. The private initial index behavior changes intentionally, while VideoRecorderCfg, defaults, and the output filename format remain unchanged. The user-visible fix is documented in the package changelog fragment.
• Implementation: The constructor assigns self.cfg before scanning, the anchored and escaped regex limits matches to the configured prefix and numeric MP4 filenames, and missing or empty directories preserve the prior zero start. A non-blocking tradeoff is that construction now lists an existing output directory, so permission or filesystem errors can surface during initialization rather than later as logged write failures.

No blocking issues. No inline issue met the actionable-evidence threshold; the assessment above records the review feedback.

Automated review; human maintainers own approval decisions.

[AntoineRichard]

Could you target develop? We'll backport them to release 3.0

[diegoferigo-rai]

Retargeted to develop, thanks!

[AntoineRichard]

@kellyguo11 @matthewtrepte could I get a review?

[kellyguo11]

run-ci

[kellyguo11]

run-ci

[kellyguo11]

run-ci

[isaaclab-bot]

Backported to release/3.0.0 as e9b6ab5.