autodl无卡模式下载NTURain 训练集实录：基于 Git 部分克隆与稀疏检出的数据拉取

NTURain 训练集获取实录：基于 Git 部分克隆与稀疏检出的数据拉取

记录时间：2026-10-15
执行环境：AutoDL 容器autodl-container-38ef40b880-8646dcf9
目标数据：hotndy/SPAC-SupplementaryMaterials→Dataset_Training_Synthetic
结论状态：验收通过（33 / 25 / 604M 三重校验全部命中）

目录

• 0. 摘要（学术型，约 120 字）
• 1. 任务背景与目标
• 2. 故障现象与根因定位
  • 2.1 故障现象
  • 2.2 根因定位
  • 2.3 故障的间歇性特征
• 3. 解决方案：两段式部分克隆
  • 3.1 完整命令序列
  • 3.2 各参数的作用机理
  • 3.3 分阶段耗时与吞吐实测
• 4. 验收：三重数字化校验
• 5. 与预期的两处偏差校正
• 6. 数据资产清单与命名规则
• 7. 后续步骤
• 8. 可复用命令速查
• 9. 方法论提炼

0. 摘要（学术型，约 120 字）

针对视频去雨知识蒸馏研究的数据需求，本文记录 NTURain 合成训练集的获取过程。采用部分克隆与稀疏检出机制，仅拉取目标目录，成功获得 33 个 RAR 归档（25 个雨序列、8 个背景真值），实测 604 MB，与预期一致。结果校正了原论文"24 序列"的表述偏差，确证 t7 场景含 4 个雨变体，为后续解压与蒸馏流水线接线提供经校验的数据资产。

1. 任务背景与目标

1.1 数据在方案中的位置

NTURain 是 VDMamba → NAFNet 视频去雨蒸馏方案的唯一主训练数据集，同时承担三项职能：

1.2 拉取前的数据缺口

此前本地与实例中已具备 NTURain测试集（经三重认证：synthetic_NTURain.zip与 SPAC 版逐字节相同），但训练集始终缺失——这正是早期教师自训不得不改走"真实雨无监督"替代路线的原因。

本次补齐后，方案才能完整支撑"预训练 + 蒸馏"两阶段流程。

1.3 官方渠道

https://github.com/hotndy/SPAC-SupplementaryMaterials └── Dataset_Training_Synthetic/ ← 本次目标（603 MB）

仓库总容量约1481 MB，训练集占603 MB，其余约 878 MB（测试集 / videoDemos / SP_Matching_Evaluations / SPAC-CNN_code）本次不下载。

2. 故障现象与根因定位

2.1 故障现象

首次执行--sparse单段式 clone 时中途失败：

Cloning into 'SPAC-SupplementaryMaterials'... fatal: unable to access 'https://github.com/hotndy/SPAC-SupplementaryMaterials.git/': GnuTLS recv error (-110): The TLS connection was non-properly terminated. bash: cd: SPAC-SupplementaryMaterials: No such file or directory

2.2 根因定位

关键判据是报错发生的阶段：

• 报错出现在Cloning into ...之后、Enumerating objects之前
• 此时尚未进入数据传输阶段，仅处于 TLS 连接建立 / 存活阶段

因此可判定：

→根因：国内直连 GitHub 时 TLS 连接被中途掐断，与仓库、命令、本地环境均无关。

2.3 故障的间歇性特征

需要如实记录一点：本次重试成功时并未显式执行source /etc/network_turbo学术加速，仅将命令由单段式改为两段式（--no-checkout+sparse-checkout+checkout）。

这说明该故障具有间歇性（stochastic）特征，而非确定性失败。工程含义：

• 判断为网络抖动时，优先重试往往比立即改配置更省时间
• 但也不应据此认为学术加速无效——它是稳定的兜底手段，建议在连续两次失败后启用：

source/etc/network_turbo

3. 解决方案：两段式部分克隆

3.1 完整命令序列

第 1 步 · 仅拉取对象图，不检出工作区

cd~&&gitclone--progress--depth1--filter=blob:none --no-checkout\https://github.com/hotndy/SPAC-SupplementaryMaterials.git

实测输出：

remote: Enumerating objects: 8, done. remote: Counting objects: 100% (8/8), done. remote: Compressing objects: 100% (8/8), done. remote: Total 8 (delta 0), reused 7 (delta 0), pack-reused 0 (from 0) Receiving objects: 100% (8/8), done.

第 2 步 · 声明稀疏范围并触发按需拉取

cd~/SPAC-SupplementaryMaterials&&\gitsparse-checkout init--cone&&\gitsparse-checkoutsetDataset_Training_Synthetic&&\gitcheckout

实测输出：

remote: Enumerating objects: 35, done. remote: Counting objects: 100% (35/35), done. remote: Compressing objects: 100% (35/35), done. remote: Total 35 (delta 1), reused 33 (delta 0), pack-reused 0 (from 0) Receiving objects: 100% (35/35), 603.15 MiB | 5.18 MiB/s, done. Resolving deltas: 100% (1/1), done. Updating files: 100% (35/35), done.

3.2 各参数的作用机理

核心机制：--filter=blob:none与--no-checkout联手"冻结"文件内容下载，直到sparse-checkout set明确了范围，再在checkout时精确拉取。相比单段式--sparse，两段式的优势是：

1. 范围可控——可在 checkout 前二次确认稀疏规则，避免误拉全量
2. 失败可续——万一 checkout 阶段断线，只需重跑 checkout，不必重做整个 clone
3. 进度可读——下载量以Receiving objects明确显现，便于估算时长

3.3 分阶段耗时与吞吐实测

计算：603.15 MiB ÷ 5.18 MiB/s ≈ 116 s ≈ 1 分 56 秒

工程参考值：按 5 MiB/s 估算，603 MB 数据约需 2 分钟；该速率可作为后续拉取同类数据集体量的基准。

4. 验收：三重数字化校验

核验原则：验收必须用可量化的数字指标，不能用"能否打开 / 能否解压"这类定性判断。（历史教训：曾因压缩包恰好截断在整数 MiB 边界而误判为完整。）

三项全部命中，且第 2 步传输日志明确报告603.15 MiB，与 GitHub API 预先测得的理论值 603.0 MB 吻合（差异来自 MiB/MB 换算），下载完整性确认成立。

5. 与预期的两处偏差校正

本次拉取同时校正了两处此前的错误预期，均需在后续流程中作为既定事实使用。

5.1 训练集是 RAR 归档，不是解压好的帧目录

Dataset_Training_Synthetic/实际内容为34 个条目：

34 = 1 × readme.md + 25 × tN_Rain_MM.rar + 8 × tN_GT.rar

影响：t*_Rain_*匹配到的是带.rar后缀的文件，解压前不能当作帧目录直接送进 DataLoader。此前给出的ls -d t*_Rain_* | wc -l数目录的验收方式语义错误，已修正为ls t*_Rain_*.rar | wc -l。

5.2 雨序列实际为 25 个，论文表述为 24 个

合计3 × 7 + 4 = 25。

论文原文写的是 “The training set contains24synthetic rainy videos and the corresponding ground truth.”，与仓库实际不符——很可能是t7_Rain_04在论文投稿后补传，或论文笔误。

处理原则：以仓库实际为准，验收标准按25；同时在校验清单中记录该偏差，避免后续与nturain_train.txt比对时误判为数据缺失。

6. 数据资产清单与命名规则

6.1 资产构成

6.2 命名规则

tN_GT.rar 第 N 个场景的干净背景，一场景一个（8 个） tN_Rain_MM.rar 第 N 个场景的第 MM 个雨变体（25 个）

6.3 与测试集命名体系的区分 ⚠️

两套命名体系不可混用，编写数据列表文件时需分别处理。

7. 后续步骤

7.1 立即执行：解压 33 个 RAR

先探环境，再决定安装方式：

whichunrarunar 7z p7zip2>/dev/null;echo"---";python-c"import rarfile"2>&1|tail-1

若均缺失：

apt-getupdate&&apt-getinstall-yunrar

解压示例（先单文件试跑，确认无误再批量）：

cd~/SPAC-SupplementaryMaterials/Dataset_Training_Syntheticunrarx -o+-yt1_Rain_01.rar

本地兜底：Windows 端 WinRAR 位于D:\Ccopy\Program Files\WinRAR\，可用UnRAR.exe x -o+ -y <file>.rar .静默解压。
⚠️不要用 Windows 自带的tar.exe（bsdtar）解 rar——它会报Parsing filters is unsupported。

7.2 数据列表对齐

ls-dt*_Rain_*|wc-l# 解压后应为 25 个目录ls-dt*_GT*|wc-l# 应为 8

核对VDMamba-main/lists/nturain_train.txt：若只列 24 条，需补齐 t7_Rain_04，否则训练时会静默少一个序列。

7.3 接入蒸馏流水线

数据就位后即可进入 VDMamba → NAFNet 方案的 P2 接线阶段：教师预生成输出/特征 → 学生按配对数据训练。

8. 可复用命令速查

# ===== 一次性拷贝版：拉取任意仓库的指定子目录 =====REPO="https://github.com/hotndy/SPAC-SupplementaryMaterials.git"DIR="Dataset_Training_Synthetic"cd~&&gitclone--progress--depth1--filter=blob:none --no-checkout"$REPO"DIRNAME=$(basename"$REPO".git)cd"$DIRNAME"&&\gitsparse-checkout init--cone&&\gitsparse-checkoutset"$DIR"&&\gitcheckout# ===== 验收 =====ls"$DIR"/*.rar|wc-l# 期望 33du-sh"$DIR"# 期望 ≈ 603M

连接失败时的对策序列：

# 1) 先重试（故障具间歇性）# 2) 连续两次失败 → 开学术加速source/etc/network_turbo# 3) 仍失败 → 换 GitHub 代理gitclone--progress--depth1--filter=blob:none --no-checkout\https://ghfast.top/https://github.com/hotndy/SPAC-SupplementaryMaterials.git

9. 方法论提炼

本次拉取沉淀出四条可复用于其他数据集获取的规则：

① “blobless + no-checkout + sparse” 是只取子目录的标准范式

不需要完整历史、不需要全仓库内容时，三者组合能把传输量压到最小。判据是第一步的Enumerating objects数量——本次仅8 个对象，说明 blob 过滤确实生效；若该数字接近仓库文件总数，则说明 filter 未生效。

② 传输故障的定位看"报错发生的阶段"

• 报错在Cloning into之后、Enumerating objects之前 →连接层问题（网络），非仓库/命令问题
• 报错在Receiving objects中途 →传输层问题，优先考虑续传或换渠道
• 报错在Updating files→本地层问题，检查磁盘与权限

本次属第一类，重试即通。

③ 验收必须数字化，且要用"与理论值交叉核对"的方式

本次的完整闭环是：GitHub API 预查理论体积（603.0 MB）→ 传输日志实测（603.15 MiB）→ 本地 du 复核（604M）+ 条目计数（33 / 25）。三方一致才判为成功。仅凭"命令没报错"或"能解压"不足以验收。

④ 论文描述与仓库实际不一致时，以仓库为准并显式记录偏差

"24 序列 vs 25 序列"这类偏差不会导致报错，但会污染后续所有实验的对齐基准。正确做法是：记录偏差 → 定下新标准 → 在后续所有校验点使用新标准，而不是让偏差在流水线里静默传递。

文档结束 · 2026-10-15