bili-sync 请问，记录视频下载完成，下次下载时自动跳过的逻辑是如何实现的？

RT. 请问，记录视频下载完成，下次下载自动跳过的逻辑是如何实现的？系统环境：飞牛OS 部署方式：Docker-compose

services:
  bili-sync-rs:
    # 不推荐使用 latest 这种模糊的 tag，最好直接指明版本号
    image: amtoaer/bili-sync-rs:latest
    restart: always
    network_mode: bridge
    # 该选项请仅在日志终端支持彩色输出时启用，否则日志中可能会出现乱码
    tty: true
    # 非必需设置项，推荐设置为宿主机用户的 uid 及 gid (`$uid:$gid`)
    # 可以执行 `id ${user}` 获取 `user` 用户的 uid 及 gid
    # 程序下载的所有文件权限将与此处的用户保持一致，不设置默认为 Root
    user: 1000:1000
    hostname: bili-sync-rs
    container_name: bili-sync-rs
    # 程序默认绑定 0.0.0.0:12345 运行 http 服务
    # 可同时修改 compose 文件与 config.toml 变更服务运行的端口
    ports:
      - 52000:12345
    volumes:
      - /vol1/1000/docker-compose/bili_sync/appdata/config:/app/.config/bili-sync
      - /vol1/1000/docker-compose/bili_sync/media:/media
      # 还需要有一些其它必要的挂载，包括 up 主信息位置、视频下载位置
      # 这些目录不是固定的，只需要确保此处的挂载与 bili-sync-rs 的配置文件相匹配
      # ...
    # 如果你使用的是群晖系统，请移除最后的 logging 配置，否则会导致日志不显示
    logging:
      driver: "local"

前期调试下载路径时，下载错了路径，想后期修改，删掉视频重下发现总会跳过。我尝试清空了sqllite数据库的collection、favorite、page、submission、video、watch_later表，重新添加合集发现还是会跳过视频。也尝试清空了浏览器的localstorage，除了让我重新输入auth好像也没有用的样子。难道说，想完成已下载文件的管理，只能把docker容器删了，全部推倒重来这样吗？

Oct 14 '25 07:10 DeSireFire

自动跳过依赖 video 表的 DownloadStatus，整个筛选逻辑是：

Valid = true 视频状态正常，可以下载
DownloadStatus < STATUS_COMPLETED 视频状态如果全部成功最高位会是 1，如果该条件满足说明视频有失败的状态
Category = 2 这是收藏夹接口会返回的字段，2 表示普通用户投稿视频，现在是一个兼容字段，基本都是 true
SinglePage != null 表示上一步的填充视频详情成功，分页信息已正确填充
ShouldDownload = true 表示满足视频源的筛选规则 https://github.com/amtoaer/bili-sync/blob/2fff5134cf89ce79c63f9c7621e3d74a56be3104/crates/bili_sync/src/utils/model.rs#L33-L51

最主要的是 2，每次执行都会更新视频的下载状态，下次检查时如果视频已经完成就会跳过条件 2。按道理来说目前程序是否下载仅依赖数据库字段，如果数据库都清空了不可能会继续跳过的。

不过当前程序确实没怎么考虑对已下载文件的管理，WebUI 上也只是支持全体视频的失败状态重置与单个视频页的状态编辑。因为我总觉得下载完后用户可能自己做一些重命名之类的操作，基于数据库里记录的路径做管理很不可靠，做起来也有点麻烦，所以一直处于搁置状态。

Oct 14 '25 08:10 amtoaer

说真，我也很疑惑，按理说清空了表，日志里应该会提示说下载的。原因归结于，必须完全停止docker项目，再去修改sqllite文件，清空video的同时，collection表也要清空，保存退出。再重新启动项目，通过webui再次添加collection，才会下载。如果清空video 保留collection表的内容，重启项目是会提示扫到0个视频。这个测试结果不完全可靠，过后发现有关进程有残留没有完全关闭，这可能也是导致玄学问题的原因之一。

另外，是否能够添加多一个命名变量{{collection_name}}，用于表示合集(or 收藏夹)名称。是否可以将视频命名模板，按照视频源细分：背景：视频源包括收藏夹、合集、用户投稿、稍后看。它们各自的结构，有时候用同一套模板，并不能兼顾整理的需要。主设置为公共命名模板; 每个视频源有独立自定义的视频模板; 优先级：自定义模板>设置公共模板。

Oct 14 '25 18:10 DeSireFire

视频更新检测和下载不同，是依赖各个视频源表的 latest_row_at 字段的，所以即使清空 videos 表，合集也不会检测到新视频，这部分在文档的运行原理里有说明。

另外视频表和各个视频源表在程序层级维护了逻辑上的外键关系，不推荐直接删除，可能会破坏程序执行假设造成一些问题。

collection_name 实现很简单，可以速加。后面这个自定义命名模板做起来要麻烦些，而且我有点犹豫。现在电影、电视剧的结构都是固定写死的，命名模板基本只能用于控制文件和文件夹名称，我觉得支持独立自定义的好处相当有限，可能唯一的作用是允许用户给不同视频源的模板里加一段自己写的特定文本。

Oct 14 '25 19:10 amtoaer