CVAT import failed error dataset not found

Not specified by the original author.

TL;DR

Fix this in CVAT by acting on the exact message first: export a single job first to isolate the failure, check the server log window for that job, repair or remove the one annotation the exporter stops on (usually a track with a missing keyframe), then export the full dataset. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Annotations export failed with status 500

Use this when

• The operation in CVAT fails with this exact message: Annotations export failed with status 500.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in CVAT, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: export a single job first to isolate the failure, check the server log window for that job, repair or remove the one annotation the exporter stops on (usually a track with a missing keyframe), then export the full dataset. Verify: one job exports cleanly and the full export then completes with the expected file count.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in CVAT on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in CVAT so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

The exporter serializes every track in order; one corrupt track fails the whole archive on the server side even though the other jobs are fine.

Variant phrasings

Annotations export failed with status 500

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: CVAT export failed error "Annotations export failed with status 500" on dataset download

The how-to phrasing for the same failure in CVAT. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

CVAT troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: CVAT at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCpvL050R9yff55vcz96_w

Resolved from the public thread: https://vectle.com/posts/pstCpvL050R9yff55vcz96_w

Thread query: CVAT export failed error "Annotations export failed with status 500" on dataset download

TL;DR: Fix this in CVAT by acting on the exact message first: export a single job first to isolate the failure, check the server log window for that job, repair or remove the one annotation the exporter stops on (usually a track with a missing keyframe), then export the full dataset. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Fix this in CVAT by acting on the exact message first: read the version recorded in the backup, restore it on a server of the matching version or step through the supported upgrade path, and only then import the data into the newer server. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

backup file version is not supported

Use this when

• The operation in CVAT fails with this exact message: backup file version is not supported.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in CVAT, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: read the version recorded in the backup, restore it on a server of the matching version or step through the supported upgrade path, and only then import the data into the newer server. Verify: the restore completes on the matching version and tasks appear with their annotations.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in CVAT on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in CVAT so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Backups are versioned with the server that wrote them; a newer server refuses formats it has no migration for instead of guessing.

Variant phrasings

backup file version is not supported

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: CVAT backup restore failed error "backup file version is not supported"

The how-to phrasing for the same failure in CVAT. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

CVAT troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: CVAT at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bXaDPl6jBRoFWzEgp3jXMw

Resolved from the public thread: https://vectle.com/posts/pst_bXaDPl6jBRoFWzEgp3jXMw

Thread query: CVAT backup restore failed error "backup file version is not supported"

TL;DR: Fix this in CVAT by acting on the exact message first: read the version recorded in the backup, restore it on a server of the matching version or step through the supported upgrade path, and only then import the data into the newer server. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

QSIRecon: 'No atlas images found' ValueError in collect_atlases with a custom BIDS atlas dataset

TL;DR

The error means the BIDS layout QSIRecon built from your atlas dataset returned zero files for its template + dseg query, even though a dseg file looks present on disk. In almost every case the cause is on the indexing side, not the tractography side: the path passed to --datasets is not the atlas dataset root, the label string in --atlases does not exactly match the atlas-[label] folder, or the dseg filename does not parse into the entities the query asks for. Verify those three things, reproduce the query standalone with PyBIDS, fix the naming or layout, and rerun one subject before scaling up.

Verbatim error

Errors found in atlas collection:
No atlas images found for CND0012001muse with query {'template': 'MNI152NLin2009cAsym', 'suffix': 'dseg', 'extension': ['.nii.gz', '.nii']}
ValueError, raised from qsirecon/utils/atlases.py in collect_atlases (QSIRecon 26.0.1)

Steps

1. Print the exact expanded arguments before rerunning. Echo the shell variables so you see the final strings QSIRecon receives for --datasets [label]=[path] and --atlases [label]. Success check: the label in both flags is character-for-character identical to the suffix of the atlas-[label] folder on disk. A variable that expands differently in the two flags (for example an extra subject prefix) is the single most common cause.
2. Confirm the --datasets path is the atlas dataset root. The root must contain datasetdescription.json (with DatasetType set to atlas) and the atlas-[label] folder inside it. Passing the atlas-[label] folder itself, or the parent of the root, makes the layout index the wrong tree and the query finds nothing. Success check: listing the path you passed shows datasetdescription.json and the atlas folder side by side.
3. Check the dseg filename entities. The image inside atlas-[label] should be named atlas-[label]space-MNI152NLin2009cAsymdseg.nii.gz, with the matching [label]dseg.tsv (columns index, name, roiresolution) beside it. The space value must match the template name in the error query exactly. Success check: the filename has no extra entities, typos, or double extensions between the space entity and the dseg suffix.
4. Reproduce the indexing standalone. Build a PyBIDS BIDSLayout on the atlas dataset root and run the same query (template MNI152NLin2009cAsym, suffix dseg) and print the results. Success check: the query returns your dseg file. If it returns empty outside QSIRecon, the problem is filename parsing, a .bidsignore entry, or a JSON sidecar whose SpatialReference disagrees with the filename, not QSIRecon logic.
5. If step 4 is still empty, temporarily move the non-space native-space dseg file out of the atlas folder and rerun the query. A second dseg for the same label can confuse collection and mask the spaced file. Success check: the query now returns the MNI-space file.
6. Fix whichever check failed, then rerun the single-subject test recon with the same flags. Success check: collect_atlases logs the atlas as found and the run proceeds past atlas collection to connectivity matrix generation.

When this applies

• QSIRecon 26.x with a custom atlas supplied via --datasets and --atlases
• Failure occurs inside collect_atlases before any tractography or matrix step runs
• The atlas dataset follows the BIDS atlas layout (dataset_description.json plus an atlas-[label] folder)

When this does not apply

• Errors that name a built-in QSIRecon atlas rather than a custom one
• Runs that get past atlas collection and fail during tractography or matrix writing
• QSIPrep (not QSIRecon) preprocessing failures

Variant phrasings

Errors found in atlas collection in QSIRecon 26.0.1

Same failure; the wrapper message appears first in the log and the 'No atlas images found' line underneath it is the actionable part.

Custom atlas query returns empty in PyBIDS

If the standalone layout query in step 4 returns nothing, treat the skill as a filename/layout parsing problem and work steps 2, 3, and 5 in order.

Why it happens

collect_atlases trusts the PyBIDS index completely. It never scans the folder with its own eyes, so a file that looks right in a directory listing can still parse into entities the query does not ask for, sit one directory level away from where the layout was rooted, or be shadowed by a sibling file. The ValueError is the query result (zero files) surfacing, not a corrupted atlas.

Edge cases

• Per-subject atlases generated in a loop: build the label string once and reuse it for the folder name, the --datasets label, and the --atlases value so the three can never drift apart.
• Atlas datasets assembled on Windows or copied between filesystems: check for hidden characters or a trailing space in the folder name.
• If the standalone PyBIDS query works but QSIRecon still fails, compare the QSIRecon version's bundled layout config against your PyBIDS version; entity naming (template vs space) changed across releases.

Provenance

Resolved from the public thread: https://neurostars.org/t/qsirecon-construct-connectivity-matrices-based-on-a-custom-atlas-for-each-individual/36448

In the Neurostars thread 'QSIRecon: construct connectivity matrices based on a custom atlas for each individual' (opened Oct 9, 2026; OP follow-up Oct 14 still unanswered): a 1,262-scan DTI dataset run through QSIPrep + QSIRecon with a per-subject MUSE atlas dataset on QSIRecon 26.0.1 fails in qsirecon/utils/atlases.py collect_atlases with 'No atlas images found for CND0012001muse' for the MNI152NLin2009cAsym dseg query, despite an MNI-space dseg file being present in the atlas folder. Source: https://neurostars.org/t/qsirecon-construct-connectivity-matrices-based-on-a-custom-atlas-for-each-individual/36448