歌单入库：父级 URL 与溯源

「搬运」活很少光鲜：四十期播客、两百条 Shorts、三年的系列剧。剪辑迟早会做二次创作；你的工作是落地、命名、让人三个月后不必问「这从哪个频道来的」。

溯源在入库时丢，不在归档时补。

多数人卡在这里

逐条贴单集 URL，丢了播放列表上下文。多数溯源失败发生在入库，不是归档。 平台若暴露歌单 / 频道 / 系列 URL，应把父级 URL 交给队列，让队列展开子项，并为每行打上父级元数据——否则你得到 187 条孤儿行。

父级 URL 规则

1. 解析播放列表为当时的子项列表。
2. 每条子项写入：父级 URL、歌单标题、在单内序号。
3. 元数据落成与成片同名的 JSON 侧车（小、无聊、值钱）。

侧车体积可忽略；法务问「第 7 还是第 8 集」时，侧车说 "playlist_index": 7。

Clipr 默认写侧车；功能「搬运」向文案有写。若用别的工具，手写 JSON 也值。

跨次去重

第二次「同一频道只要本周新更」时，队列应拒绝上周已抓的 14 条：

• URL 规范化去重（去 tracking 参数、统一协议）。
• 已落地文件指纹（大小 + 头 4KB 哈希对多数情况够用）。
• 有 Team 库时：入队前先查共享目录。

勿仅用标题去重——标题会改。

VPN 断后续传

• 支持 Range 的 CDN：断线续字节，别重头。
• 每 N 条 checkpoint：200 集歌单每 5–10 条落盘进度；137 集崩溃应从 138 续，不是从 1。
• manifest 过期：单条视频的 manifest 常 6–12 小时过期；隔夜续跑应先重新解析 manifest，别死磕昨夜 URL。

章节与元数据

YouTube 有章节时，写入容器与 chapters.json 侧车；下游重编码时 forward 章节 atom，多数 NLE 会默默丢。

同时保留：原始发布日期（非下载日）、抓取时标题（频道后改标题时仍可对上）、必要时原始描述（法务偶要）、缩略图字节（URL 会过期）。

只留视频不留元数据，你只有文件，没有资产。

目录命名

搬运向推荐按频道扁平 + 侧车，别深嵌「按剧名」——剧名会改：

/library/raw/2026-04/
  channel-a__series-03__ep01.mp4
  channel-a__series-03__ep01.json

侧车与成片相邻；归档时再迁树不迟。

不行怎么办？

• **列表条数比页面少：**分页或登录可见项；回到已登录标签重解；检查歌单 URL 是否带完整 list=。
• **续传总从 0 开始：**该 CDN 不认 Range；预分配磁盘并接受重下，别死循环。
• **重编码后章节没了：**编码器未 map chapters；加 -map_chapters 0 或等价参数。
• **两人各入库一套重复：**缺团队级去重；把频道升为「已 watch 歌单」，再入队先查库。
• **下游不认侧车：**在边界统一成一种 JSON（如 info.json 风格），别在中间环节乱换格式。

收尾

搬运奖励无聊纪律：父级 URL、侧车、入队前去重、断线后先刷新 manifest、文件名不当唯一真相。做到这五条，「这文件哪来的」不再靠 Slack 翻记录。

详见 功能，共享库与席位见 价格，入库 UI 在 下载。