A session produces two things: motion now, and a dataset later. The two want opposite things, so recording happens away from the control path.

How to record

Give the follower a path and it records while you drive.
That attaches a recorder when the session starts and closes it when the session stops. To turn it on and off yourself, leave record= out and call the methods directly. Both sides can record. Everything above works the same on a Leader, which is useful when the person driving is not on the same machine as the arm.
Recording never touches the control path. Control keeps only what it needs and discards the rest, which is right for moving a robot and wrong for a dataset.

Episodes

An episode is one demonstration. By default the deadman marks the boundary: squeeze to start, release to end.
success is True, False, or None for not judged, so you can decide later whether failures are noise or negative examples.

Where it is kept

On the robot. The path you passed. The follower already holds the commanded value, the value read back and the camera frames, so nothing is lost and every timestamp comes from one machine. In Torq Cloud. The same episodes are kept for you, so a session becomes a training dataset without moving files off the robot, stitching sessions together, or managing storage yourself.

Export

--dry-run reports the row count, the measured frame rate and how many rows were joined by number rather than guessed, so you can check a session before spending time on it.Add --explicit-only to drop guessed rows entirely.
Run exports on your own machine, not the robot. Transcoding images is CPU heavy, and the robot needs its CPU for the control loop.

Recording and export

Every method, field and export flag.

Sync

Matching video to joint readings.

Types

Every id and what creates it.

Stats

Checking how well a session was recorded.