bf1942/bili-sync-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: 将 video list model / video list 重命名为 video source (#260)

Browse Source
This commit is contained in:
ᴀᴍᴛᴏᴀᴇʀ
2025-02-18 22:36:25 +08:00
committed by GitHub
parent 315ad13703
commit 32214d5d5f
10 changed files with 64 additions and 64 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/design.md
View File

@@ -10,7 +10,7 @@
- 每个视频都有唯一的 bvid，包含了封面、描述和标签信息，并包含了一个或多个分页；
- 每个分页都有一个唯一的 cid，包含了封面、视频、音频、弹幕。
为了描述方便，在后文会将收藏夹、稍后再看这类结构统称为 video list，将视频称为 video，将分页称为 page。不难看出这三者有着很明显的层级关系：**video list 包含若干 video，video 包含若干 page**。
为了描述方便，在后文会将收藏夹、稍后再看这类结构统称为 video source，将视频称为 video，将分页称为 page。不难看出这三者有着很明显的层级关系：**video source 包含若干 video，video 包含若干 page**。
一个非常容易混淆的点是视频合集/视频列表与多页视频的区别：
@@ -21,7 +21,7 @@
这两张图中，上图是视频合集，下图是多页视频。这两者在展示上区别较小，但在结构上有相当大的不同。结合上面对 b 站视频结构的介绍，这个区别可以简单总结为：
+ **视频合集是由多个仅包含单个 page 的 video 组成的 video list**；
+ **视频合集是由多个仅包含单个 page 的 video 组成的 video source**；
+ **多页视频是由多个 page 组成的 video**。
@@ -31,7 +31,7 @@
EMBY 的一般结构是： `媒体库 - 文件夹 - 电影/电视剧 - 分季/分集`，方便起见，我采用了如下的对应关系：
1. **文件夹**：对应 b 站的 video list；
1. **文件夹**：对应 b 站的 video source；
2. **电视剧**： 对应 b 站的 video；
3. **第一季的所有分集**：对应 b 站的 page。
@@ -54,11 +54,11 @@ EMBY 的一般结构是： `媒体库 - 文件夹 - 电影/电视剧 - 分季/
> [!NOTE]
> 可以[前往此处](https://github.com/amtoaer/bili-sync/tree/main/crates/bili_sync_entity/src/entities)实时查看当前版本的数据库表结构。
既然拥有着明显的层级关系，那数据库表就很容易设计了。为了简化实现，程序没有额外考虑单个 video 被多个 video list 引用的情况（如一个视频同时在收藏夹和稍后再看中）。而是简单的将其设计为了不交叉的层级结构。
既然拥有着明显的层级关系，那数据库表就很容易设计了。为了简化实现，程序没有额外考虑单个 video 被多个 video source 引用的情况（如一个视频同时在收藏夹和稍后再看中）。而是简单的将其设计为了不交叉的层级结构。
### video list 表
### video source 表
从上面的介绍可以看出，video list 并不是一个具体的结构，而是拥有多种实现的抽象概念。我选择将其特化实现为多张表：
从上面的介绍可以看出，video source 并不是一个具体的结构，而是拥有多种实现的抽象概念。我选择将其特化实现为多张表：
1. favorite：收藏夹；
2. watch_later：稍后再看；
@@ -67,9 +67,9 @@ EMBY 的一般结构是： `媒体库 - 文件夹 - 电影/电视剧 - 分季/
### video 表
video 表包含了 video 的基本信息，如 bvid、标题、封面、描述、标签等。此外，video 表还包含了与 video list 的关联。
video 表包含了 video 的基本信息，如 bvid、标题、封面、描述、标签等。此外，video 表还包含了与 video source 的关联。
具体来说，每一种 video list 都在 video 表中有一个对应的列，指向 video list 表中的 id，如 favorite_id、collection_id 等。接下来将这些键与 video 的 bvid 绑在一起建立唯一索引，就可以保证在同一个 video list 中不会有重复的 video。
具体来说，每一种 video source 都在 video 表中有一个对应的列，指向 video source 表中的 id，如 favorite_id、collection_id 等。接下来将这些键与 video 的 bvid 绑在一起建立唯一索引，就可以保证在同一个 video source 中不会有重复的 video。
### page 表
@@ -81,20 +81,20 @@ page 表包含了 page 的基本信息，如 cid、标题、封面等。与 vide
程序启动时会读取配置文件、迁移数据库、初始化日志等操作。如果发现需要的文件不存在，程序会自动创建。
### 扫描 video list 获取新视频
### 扫描 video source 获取新视频
> [!WARNING]
> b 站实现接口时为了节省资源，通过 video list 获取到的 video 列表通常是分页且不包含详细信息的。
> b 站实现接口时为了节省资源，通过 video source 获取到的 video 列表通常是分页且不包含详细信息的。
程序会扫描所有配置文件中包含的 video list，获取其中包含的 video 的简单信息并填充到数据库。在实现时需要避免频繁的全量扫描。
程序会扫描所有配置文件中包含的 video source，获取其中包含的 video 的简单信息并填充到数据库。在实现时需要避免频繁的全量扫描。
具体到 bili-sync 的实现中，每个 video list 都有一个 `latest_row_at` 列，用于记录处理过的最新视频时间。程序在请求接口时会设置按时间排序，确保新视频位于前面。排序依据的时间根据 video list 的类型而定：收藏夹按收藏时间，投稿按照投稿时间...
具体到 bili-sync 的实现中，每个 video source 都有一个 `latest_row_at` 列，用于记录处理过的最新视频时间。程序在请求接口时会设置按时间排序，确保新视频位于前面。排序依据的时间根据 video source 的类型而定：收藏夹按收藏时间，投稿按照投稿时间...
拉取过程会逐页请求，程序会不断将获取到的视频保存到数据库中，直到发现第一个小于等于 `latest_row_at` 的视频时停止。接着将 `latest_row_at` 更新为最新的视频时间。
### 填充 video 详情
将新增视频的简单信息写入数据库后，下一步会填充 video 详情。正如上文所述：**通过 video list 获取到的 video 列表通常是不包含详细信息的**，因此需要额外的请求来填充这些信息。
将新增视频的简单信息写入数据库后，下一步会填充 video 详情。正如上文所述：**通过 video source 获取到的 video 列表通常是不包含详细信息的**，因此需要额外的请求来填充这些信息。
这一步会筛选出所有未完全填充信息的 video，逐个获取 video 的详细信息（如标签、包含的 page 等）并填充到数据库中。
@@ -108,4 +108,4 @@ page 表包含了 page 的基本信息，如 cid、标题、封面等。与 vide
如果某些部分下载失败，status 字段会记录这些部分的失败次数，程序会在下次下载时重试。如果重试次数超过了设定的阈值，那么视频会被标记为下载失败，后续直接忽略。
此处程序对风控做了额外的处理，一般风控发生时接下来的所有请求都会失败，因此程序检测到风控时不会认为是某个视频下载失败，而是直接终止 video list 的全部下载任务，等待下次扫描时重试。
此处程序对风控做了额外的处理，一般风控发生时接下来的所有请求都会失败，因此程序检测到风控时不会认为是某个视频下载失败，而是直接终止 video source 的全部下载任务，等待下次扫描时重试。