Every message the bench can hand back, what it actually means, and what to do next. Most of these are one line to fix and worth retrying straight away. Where the fault is ours rather than your data, it says so.
Hugging Face rate limited us while pulling your files. It has nothing to do with your data. Datasets filed as one small file per episode are the usual trigger, because pulling one is several hundred separate requests.
The fetcher now backs off and tries again on its own, up to four times, going slower and plainer each attempt. If you saw this message, all four attempts were refused.
One gigabyte, whether the bytes arrive by paste or by upload. The limit is checked against the Hub's own file listing before anything downloads, so an oversized dataset costs you seconds rather than a long wait.
Sending fewer episodes costs you nothing in the answer. The checks read the same things either way, and a hundred clips is comfortably enough to conclude on.
We pull anonymously, so anything your own account can see but a stranger cannot is invisible to us. That covers private repos and gated ones whose terms you have accepted and we have not.
The checks read a LeRobot export, which means a meta/info.json describing the
features and a data/ folder holding them. Without the metadata there is no way
to know which column is an action and which is a joint reading, and guessing is how a
millimetre comes to be read as a metre.
Every frame needs the command that was issued at it, not only the position the arm reached. A dataset of states alone has nothing for a policy to imitate.
clips.json saying what each clip shows and where it was
filmed, and the arm movements are worked out from the hands.total_episodes reads zero, the export did not finish. Run it again
before uploading.v2.0, v2.1 and v3.0 all work. If you hit this on a v3 dataset before 17 August 2026, that is fixed now and the same link will go through.
The layouts differ in how episodes are filed, not in what was recorded, so a supported export of the same footage gives the same answers.
This is a v3 dataset whose index contradicts itself. v3 spreads its episode index over several parquet files, and rewriting part of a dataset without deleting the file that was replaced leaves two rows for the same episode saying it lives in different places.
We refuse rather than pick one. Both rows claim the file they sit in, so nothing in the format says which is current, and choosing wrong would pair one episode's video with another episode's actions. That is exactly the defect this bench exists to catch, and we are not going to introduce it while looking for it.
meta/episodes/. You will find more index files than the dataset
needs, usually one large early file plus the smaller ones that superseded it.The first means the parquet arrived without the footage. A LeRobot export keeps pixels in mp4 side-cars, so the videos/ folder has to come with it. The parquet files alone have no pixels in them.
The second means the metadata and the video disagree about where an episode is. The index claims frames the file does not contain, which usually follows an interrupted export or files copied across from a different version of the dataset.
The comparison trains on your clips and on a shuffled copy of the same clips, so every clip has to offer the same view. A channel only some clips carry cannot be compared across all of them, and the check abstains rather than quietly scoring a subset and calling it your dataset.
This is an abstention, not a verdict. It says the bench could not measure, not that your footage is bad.
images.laptop in one
episode and images.top in another reads as two different cameras.A quarter of the clips are held back and scored on, and the rest are trained on. With too few held back, your data winning every single clip would still not be past chance, so the check would abstain however good the footage was. Saying that up front is cheaper than training first and abstaining after.
This is the most useful thing the bench can tell you, and it is worth stopping for. Handing each episode's actions to a different episode's video should destroy information. If it improved prediction, the actions in your dataset were not lined up with the frames they belong to in the first place.
The usual cause is an offset. An export that wrote actions a frame or two late, or a timestamp column that was recorded but never used to align the streams.
The signal check trains a policy on your data and then trains it again on twenty shuffled copies of the same data. On the machine currently serving this, a hundred clips takes around half an hour. The page updates itself, so you can close the tab and come back.
The earlier checks are quick. If Intake and the Data report have passed, the dataset is fine and the wait is only compute.
Send the submission link and what you expected to happen to @GuraseesSDhanoa. A message the bench returns that is not on this page is a message worth rewriting, so it is genuinely useful to hear about.