docs: 文档跟进最新代码变化
This commit is contained in:
amtoaer
@@ -33,7 +33,8 @@ bili-sync 是一款专为 NAS 用户编写的哔哩哔哩同步工具，由 Rust
|
||||
- [x] 支持对“稍后再看”内视频的自动扫描与下载
|
||||
- [x] 支持对 UP 主投稿视频的自动扫描与下载
|
||||
- [x] 支持限制任务的并行度和接口请求频率
|
||||
- [ ] 下载单个文件时支持断点续传与并发下载
|
||||
- [x] 支持单个文件的分块并行下载
|
||||
- [x] 支持使用 Web UI 配置，查看并管理视频、视频源
|
||||
|
||||
|
||||
## 参考与借鉴
|
||||
|
||||
@@ -45,7 +45,7 @@ export default defineConfig({
|
||||
{
|
||||
text: "细节",
|
||||
items: [
|
||||
{ text: "配置文件", link: "/configuration" },
|
||||
{ text: "配置说明", link: "/configuration" },
|
||||
{ text: "命令行参数", link: "/args" },
|
||||
{ text: "工作原理", link: "/design" },
|
||||
],
|
||||
@@ -55,10 +55,10 @@ export default defineConfig({
|
||||
items: [
|
||||
{ text: "获取收藏夹信息", link: "/favorite" },
|
||||
{
|
||||
text: "获取视频合集/视频列表信息",
|
||||
text: "获取合集/列表信息",
|
||||
link: "/collection",
|
||||
},
|
||||
{ text: "获取投稿信息", link: "/submission" },
|
||||
{ text: "获取用户投稿信息", link: "/submission" },
|
||||
],
|
||||
},
|
||||
{
|
||||
|
||||
BIN
docs/assets/config.webp
Normal file
BIN
docs/assets/config.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 167 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
BIN
docs/assets/webui.webp
Normal file
BIN
docs/assets/webui.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 95 KiB |
@@ -1,10 +1,10 @@
|
||||
# 获取视频合集/视频列表信息
|
||||
# 获取合集/列表信息
|
||||
|
||||
视频合集和视频列表虽然在哔哩哔哩网站交互上行为类似，但在接口层级是两个不同的概念，程序配置中需要对两者做出区分。
|
||||
|
||||
## 配置形式与区分方法
|
||||
目前 B 站绝大部分内容都是视频合集（Season），视频列表（Series）是古早的功能，现在已经不常见了。
|
||||
|
||||
在 bili-sync 的设计中，视频合集的 key 为 `season:{mid}:{season_id}`，而视频列表的 key 为 `series:{mid}:{series_id}`。
|
||||
## 配置形式与区分方法
|
||||
|
||||
新版本 b 站网页端已经对两种类型做了初步整合，将需要的参数展示在了视频合集/视频列表的 URL 中，不再需要手动查看接口。URL 的路径格式为：
|
||||
|
||||
@@ -13,16 +13,16 @@
|
||||
/{mid}/lists/{id}?type={season/series}
|
||||
```
|
||||
|
||||
点开你想要订阅的视频合集/视频列表详情，查看 URL 即可拼接出对应的 key。
|
||||
点开你想要订阅的视频合集/视频列表详情，对照查看 URL 即可获取所需参数。
|
||||
|
||||
### 视频合集
|
||||
|
||||
|
||||
|
||||
该视频合集的 key 为 `season:521722088:1987140`。
|
||||
类型为 `合集（Season）`，用户 ID 为 `521722088`，合集 ID 为 `1987140`。
|
||||
|
||||
### 视频列表
|
||||
|
||||
|
||||
|
||||
该视频列表的 key 为 `series:521722088:387214`。
|
||||
类型为 `列表（Series）`，用户 ID 为 `521722088`，列表 ID 为 `387214`。
|
||||
|
||||
@@ -1,10 +1,20 @@
|
||||
# 配置文件
|
||||
# 配置说明
|
||||
|
||||
默认的配置文件已经在[快速开始](/quick-start)中给出，该文档对配置文件的各个参数依次详细解释。
|
||||
## 基本设置
|
||||
|
||||
## video_name 与 page_name
|
||||
### 绑定地址
|
||||
|
||||
`video_name` 与 `page_name` 用于设置下载文件的命名规则，对于所有下载的内容，将会维持如下的目录结构：
|
||||
程序 Web Server 监听的地址，程序启动时会监听该地址，成功后可通过 `http://${bind_address}` 访问管理页。
|
||||
|
||||
该配置会在程序重启时生效。
|
||||
|
||||
### 同步间隔（秒）
|
||||
|
||||
表示程序每次执行扫描下载的间隔时间，单位为秒。
|
||||
|
||||
### 视频名称模板、分页名称模板
|
||||
|
||||
视频名称模板（`video_name`）和分页名称模板（`page_name`）用于设置下载文件的命名规则。对于所有下载的内容，将会维持如下的目录结构：
|
||||
|
||||
1. 单页视频：
|
||||
|
||||
@@ -30,7 +40,7 @@
|
||||
│ └── tvshow.nfo
|
||||
```
|
||||
|
||||
这两个参数支持使用模板，其中用 <code v-pre>{{ }}</code> 包裹的模板变量在执行时会被动态替换为对应的内容。
|
||||
这两个模板参数会在运行时解析，其中用 <code v-pre>{{ }}</code> 包裹的模板变量会被动态替换为对应的内容。
|
||||
|
||||
对于 `video_name`，支持设置 bvid（视频编号）、title（视频标题）、upper_name（up 主名称）、upper_mid（up 主 id）、pubtime（视频发布时间）、fav_time（视频收藏时间）。
|
||||
|
||||
@@ -40,7 +50,7 @@
|
||||
|
||||
> [!TIP]
|
||||
> 1. 仅收藏夹视频会区分 `fav_time` 和 `pubtime`，其它类型下载两者的取值是完全相同的；
|
||||
> 2. `fav_time` 和 `pubtime` 的格式受 `time_format` 参数控制，详情可参考 [time_format 小节](#time-format)。
|
||||
> 2. `fav_time` 和 `pubtime` 的格式受[时间格式](#时间格式)控制。
|
||||
|
||||
此外，`video_name` 和 `page_name` 还支持使用路径分割符，如 <code v-pre>{{ upper_mid }}/{{ title }}_{{ pubtime }}</code> 表示视频会根据 UP 主 id 将视频分到不同的文件夹中。
|
||||
|
||||
@@ -49,81 +59,36 @@
|
||||
> [!CAUTION]
|
||||
> **路径分隔符**在不同平台定义不同，Windows 下为 `\`，MacOS 和 Linux 下为 `/`。
|
||||
|
||||
## `auth_token`
|
||||
|
||||
表示调用程序管理 API 需要的身份凭据，程序会检查 API 请求 Header 中是否包含正确的 `Authorization` 字段。
|
||||
|
||||
内置管理页前端提供了 `auth_token` 的输入框，填写后即可成功调用 API 使用管理页。
|
||||
|
||||
## `bind_address`
|
||||
|
||||
程序 Web Server 监听的地址，程序启动时会监听该地址，成功后可通过 `http://${bind_address}` 访问管理页。
|
||||
|
||||
## `interval`
|
||||
|
||||
表示程序每次执行扫描下载的间隔时间，单位为秒。
|
||||
|
||||
## `upper_path`
|
||||
### UP 主头像保存路径
|
||||
|
||||
UP 主头像和信息的保存位置。对于使用 Emby、Jellyfin 媒体服务器的用户，需确保此处路径指向 Emby、Jellyfin 配置中的 `/metadata/people/` 才能够正常在媒体服务器中显示 UP 主的头像。
|
||||
|
||||
## `nfo_time_type`
|
||||
### 时间格式
|
||||
|
||||
表示在视频信息中使用的时间类型，可选值为 `favtime`（收藏时间）和 `pubtime`（发布时间）。
|
||||
用于设置 `fav_time` 和 `pubtime` 在视频名称模板、分页名称模板中使用时的显示格式，支持的格式符号可以参考 [chrono strftime 文档](https://docs.rs/chrono/latest/chrono/format/strftime/index.html)。
|
||||
|
||||
仅收藏夹视频会区分 `fav_time` 和 `pubtime`，其它类型下载两者取值相同。
|
||||
### 后端 API 认证 Token
|
||||
|
||||
## `time_format`
|
||||
表示调用程序管理 API 需要的身份凭据，程序会对 API 请求进行身份验证，身份验证不通过会拒绝访问。
|
||||
|
||||
时间格式，用于设置 `fav_time` 和 `pubtime` 在 `video_name`、 `page_name` 中使用时的显示格式，支持的格式符号可以参考 [chrono strftime 文档](https://docs.rs/chrono/latest/chrono/format/strftime/index.html)。
|
||||
在修改该 Token 后需要对应修改前端保存的 Token，才能正常访问管理页面。
|
||||
|
||||
## `cdn_sorting`
|
||||
|
||||
一般情况下，b 站会为视频、音频流提供一个 baseUrl 与多个 backupUrl，程序默认会按照 baseUrl -> backupUrl 的顺序请求，依次尝试下载。
|
||||
### 启动 CDN 排序
|
||||
|
||||
如果将 `cdn_sorting` 设置为 `true`，程序不再使用默认顺序，而是将所有 url 放到一起统一排序来决定请求顺序。排序优先级从高到低为：
|
||||
表示程序每次执行扫描下载的间隔时间，单位为秒。
|
||||
|
||||
1. 服务商 CDN：`upos-sz-mirrorxxxx.bilivideo.com`
|
||||
## B 站认证
|
||||
|
||||
2. 自建 CDN：`cn-xxxx-dx-v-xxxx.bilivideo.com`
|
||||
|
||||
3. MCDN：`xxxx.mcdn.bilivideo.com`
|
||||
|
||||
4. PCDN：`xxxx.v1d.szbdyd.com`
|
||||
|
||||
这会让程序优先请求质量更高的 CDN，可能会提高下载速度并增加成功率，但效果因地区、网络环境而异。
|
||||
|
||||
## `credential`
|
||||
|
||||
哔哩哔哩账号的身份凭据，请参考[凭据获取流程](https://nemo2011.github.io/bilibili-api/#/get-credential)获取并对应填写至配置文件中，后续 bili-sync 会在必要时自动刷新身份凭据，不再需要手动管理。
|
||||
哔哩哔哩账号的身份凭据，请参考[凭据获取流程](https://nemo2011.github.io/bilibili-api/#/get-credential)获取并对应填写，后续 bili-sync 会在必要时自动刷新身份凭据，不再需要手动管理。
|
||||
|
||||
推荐使用匿名窗口获取，避免潜在的冲突。
|
||||
|
||||
## `filter_option`
|
||||
## 视频质量
|
||||
|
||||
过滤选项，用于设置程序的过滤规则，程序会从过滤结果中选择最优的视频、音频流下载。
|
||||
该页配置大部分都是显而易见的，仅对视频编码格式偏好进行说明。
|
||||
|
||||
这些内容的可选值可前往 [analyzer.rs](https://github.com/amtoaer/bili-sync/blob/24d0da0bf3ea65fd45d07587e4dcdbb24d11a589/crates/bili_sync/src/bilibili/analyzer.rs#L10-L55) 中查看。
|
||||
|
||||
注意将过滤范围设置过小可能导致筛选不到符合要求的流导致下载失败，建议谨慎修改。
|
||||
|
||||
### `video_max_quality`
|
||||
|
||||
视频流允许的最高质量。
|
||||
|
||||
### `video_min_quality`
|
||||
|
||||
视频流允许的最低质量。
|
||||
|
||||
### `audio_max_quality`
|
||||
|
||||
音频流允许的最高质量。
|
||||
|
||||
### `audio_min_quality`
|
||||
|
||||
音频流允许的最低质量。
|
||||
|
||||
### `codecs`
|
||||
### 视频编码格式偏好
|
||||
|
||||
这是 bili-sync 选择视频编码的优先级顺序，优先级按顺序从高到低。此处对编码格式做一个简单说明：
|
||||
|
||||
@@ -135,130 +100,100 @@ UP 主头像和信息的保存位置。对于使用 Emby、Jellyfin 媒体服务
|
||||
|
||||
而如果你的设备不支持，或者单纯懒得查询，那么推荐将 AVC 放在第一位以获得最好的兼容性。
|
||||
|
||||
### `no_dolby_video`
|
||||
|
||||
是否禁用杜比视频流。
|
||||
|
||||
### `no_dolby_audio`
|
||||
|
||||
是否禁用杜比音频流。
|
||||
|
||||
### `no_hdr`
|
||||
|
||||
是否禁用 HDR 视频流。
|
||||
|
||||
### `no_hires`
|
||||
|
||||
是否禁用 Hi-Res 音频流。
|
||||
|
||||
## `danmaku_option`
|
||||
## 弹幕渲染
|
||||
|
||||
弹幕的设置选项，用于设置下载弹幕的样式，几乎全部取自[上游仓库](https://github.com/gwy15/danmu2ass)。
|
||||
|
||||
### `duration`
|
||||
### 弹幕持续时间（秒）
|
||||
|
||||
弹幕在屏幕上的持续时间，单位为秒。
|
||||
|
||||
### `font`
|
||||
### 字体
|
||||
|
||||
弹幕的字体。
|
||||
弹幕使用的字体。
|
||||
|
||||
### `font_size`
|
||||
### 字体大小
|
||||
|
||||
弹幕的字体大小。
|
||||
|
||||
### `width_ratio`
|
||||
### 宽度比例
|
||||
|
||||
计算弹幕宽度的比例，为避免重叠可以调大这个数值。
|
||||
|
||||
### `horizontal_gap`
|
||||
### 水平间距
|
||||
|
||||
两条弹幕之间最小的水平距离。
|
||||
|
||||
### `lane_size`
|
||||
### 轨道大小
|
||||
|
||||
弹幕所占据的高度，即“行高度/行间距”。
|
||||
|
||||
### `float_percentage`
|
||||
### 滚动弹幕高度百分比
|
||||
|
||||
屏幕上滚动弹幕最多高度百分比。
|
||||
|
||||
### `bottom_percentage`
|
||||
### 底部弹幕高度百分比
|
||||
|
||||
屏幕上底部弹幕最多高度百分比。
|
||||
|
||||
### `opacity`
|
||||
### 透明度（0-255）
|
||||
|
||||
透明度，取值范围为 0-255。透明度可以通过 opacity / 255 计算得到。
|
||||
透明度，取值范围为 0-255。实际透明度百分比为 `透明度 / 255`。
|
||||
|
||||
### `bold`
|
||||
|
||||
是否加粗。
|
||||
### 描边宽度
|
||||
|
||||
### `outline`
|
||||
弹幕的描边宽度。
|
||||
|
||||
描边宽度。
|
||||
|
||||
### `time_offset`
|
||||
### 时间偏移（秒）
|
||||
|
||||
时间轴偏移，>0 会让弹幕延后，<0 会让弹幕提前，单位为秒。
|
||||
|
||||
## `favorite_list`
|
||||
### 粗体显示
|
||||
|
||||
你想要下载的收藏夹与想要保存的位置。简单示例：
|
||||
```toml
|
||||
3115878158 = "/home/amtoaer/Downloads/bili-sync/测试收藏夹"
|
||||
```
|
||||
收藏夹 ID 的获取方式可以参考[这里](/favorite)。
|
||||
弹幕是否加粗。
|
||||
|
||||
## `collection_list`
|
||||
## 高级设置
|
||||
|
||||
你想要下载的视频合集/视频列表与想要保存的位置。注意“视频合集”与“视频列表”是两种不同的类型。在配置文件中需要做区分：
|
||||
```toml
|
||||
"series:387051756:432248" = "/home/amtoaer/Downloads/bili-sync/测试视频列表"
|
||||
"season:1728547:101343" = "/home/amtoaer/Downloads/bili-sync/测试合集"
|
||||
```
|
||||
|
||||
具体说明可以参考[这里](/collection)。
|
||||
|
||||
## `submission_list`
|
||||
|
||||
你想要下载的 UP 主投稿与想要保存的位置。简单示例：
|
||||
```toml
|
||||
9183758 = "/home/amtoaer/Downloads/bili-sync/测试投稿"
|
||||
```
|
||||
UP 主 ID 的获取方式可以参考[这里](/submission)。
|
||||
|
||||
## `watch_later`
|
||||
|
||||
设置稍后再看的扫描开关与保存位置。
|
||||
|
||||
如果你希望下载稍后再看列表中的视频，可以将 `enabled` 设置为 `true`，并填写 `path`。
|
||||
|
||||
```toml
|
||||
enabled = true
|
||||
path = "/home/amtoaer/Downloads/bili-sync/稍后再看"
|
||||
```
|
||||
|
||||
## `concurrent_limit`
|
||||
|
||||
对 bili-sync 的并发下载进行多方面的限制，避免 api 请求过于频繁导致的风控。其中 video 和 page 表示下载任务的并发数，rate_limit 表示 api 请求的流量限制。默认取值为：
|
||||
```toml
|
||||
[concurrent_limit]
|
||||
video = 3
|
||||
page = 2
|
||||
|
||||
[concurrent_limit.rate_limit]
|
||||
limit = 4
|
||||
duration = 250
|
||||
```
|
||||
|
||||
具体来说，程序的处理逻辑是严格从上到下的，即程序会首先并发处理多个 video，每个 video 内再并发处理多个 page，程序的并行度可以简单衡量为 `video * page`（很多 video 都只有单个 page，实际会更接近 `video * 1`），配置项中的 `video` 和 `page` 两个参数就是控制此处的，调节这两个参数可以宏观上控制程序的并行度。
|
||||
|
||||
另一方面，每个执行的任务内部都会发起若干 api 请求以获取信息，这些请求的整体频率受到 `rate_limit` 的限制，使用漏桶算法实现。如默认配置表示的是每 250ms 允许 4 个 api 请求，超过这个频率的请求会被暂时阻塞，直到漏桶中有空间为止。调节 `rate_limit` 可以从微观上控制程序的并行度，同时也是最直接、最显著的控制 api 请求频率的方法。
|
||||
|
||||
据观察 b 站风控限制大多集中在主站，因此目前 `rate_limit` 仅作用于主站的各类请求，如请求各类视频列表、视频信息、获取流下载地址等，对实际的视频、图片下载过程不做限制。
|
||||
该页主要用于调整程序的请求与下载行为。
|
||||
|
||||
> [!TIP]
|
||||
> 1. 一般来说，`video` 和 `page` 的值不需要过大；
|
||||
> 2. `rate_limit` 的值可以根据网络环境和 api 请求频率进行调整，如果经常遇到风控可以优先调小 limit。
|
||||
> 1. 一般来说，视频、分页的并发数不需要过大；
|
||||
> 2. 请求频率限制可以根据网络环境和 api 请求频率进行调整，如果经常遇到风控可以优先调小该值。
|
||||
|
||||
### 视频并发数、分页并发数
|
||||
|
||||
视频并发数（video）和分页并发数（page）是控制 bili-sync 视频下载任务并发度的配置项。
|
||||
|
||||
程序的处理逻辑是严格从上到下的，即程序会首先并发处理多个 video，每个 video 内再并发处理多个 page，程序的并发度可以简单衡量为 `video * page`（很多 video 都只有单个 page，实际会更接近 `video * 1`），`video` 和 `page` 两个参数就是控制此处的，调节这两个参数可以宏观上控制程序的并发度。
|
||||
|
||||
### NFO 时间类型
|
||||
|
||||
表示在视频 NFO 文件中使用的时间类型，可选值为收藏时间和发布时间。
|
||||
|
||||
仅收藏夹视频会对这两项进行区分，其它类型的视频这两者取值完全相同。
|
||||
|
||||
### 请求频率限制
|
||||
|
||||
每个执行的任务内部都会发起若干 api 请求以获取信息，这些请求的整体频率受到请求频率的限制，使用漏桶算法实现。超过这个频率的请求会被暂时阻塞，直到漏桶中有空间为止。
|
||||
|
||||
时间间隔（毫秒）与限制请求数共同表明的意思时：程序在每个时间间隔内最多允许多少个请求。调节这一项可以从微观上控制程序的并行度，同时也是最直接、最显著的控制 api 请求频率的方法。
|
||||
|
||||
据观察 b 站风控限制大多集中在主站，因此目前请求频率限制仅作用于主站的各类请求，如请求各类视频列表、视频信息、获取流下载地址等，对实际的视频、图片下载过程不做限制。
|
||||
|
||||
### 单文件分块下载
|
||||
|
||||
单文件分块下载是指将单个视频文件分成多个小块进行下载，这可能有助于提高下载速度。
|
||||
|
||||
程序会首先为这个文件预分配空间，接着将文件分成若干个大小相同的块，为每个块启动单独的异步任务并行下载。
|
||||
|
||||
|
||||
#### 下载分块数
|
||||
|
||||
表示单个文件分成多少个小块，默认值为 4。
|
||||
|
||||
#### 启动分块下载的文件大小阈值（字节）
|
||||
|
||||
表示当单个文件大小超过多少字节时，才会启动分块下载。默认值为 20971520（20 MB）。
|
||||
|
||||
如果文件过小，分块成本可能会超过分块下载带来的收益，因此使用该阈值决定下载策略。
|
||||
@@ -1,13 +1,5 @@
|
||||
# 管理页
|
||||
|
||||
在 2.4.0 版本，bili-sync 提供了一个内置的管理页，可以使用浏览器访问，实现一些简单的预览和重置操作。
|
||||
自 2.6.0 版本开始，bili-sync 的配置文件已经完全迁移至数据库中，程序的所有操作都可以通过 WebUI 管理页进行。
|
||||
|
||||
由于作者的前端水平有限，网页使用 90% AI + 10% 人工实现，问题会比较多，欢迎前端大能 PR（应该说比起 PR 缝缝补补不如直接重写 XD）。
|
||||
|
||||
|
||||
|
||||
# API
|
||||
|
||||
后端提供的 API 可以通过 `/swagger-ui/` 访问：
|
||||
|
||||
|
||||
|
||||
@@ -39,4 +39,5 @@ bili-sync 是一款专为 NAS 用户编写的哔哩哔哩同步工具。
|
||||
- [x] 支持对“稍后再看”内视频的自动扫描与下载
|
||||
- [x] 支持对 UP 主投稿视频的自动扫描与下载
|
||||
- [x] 支持限制任务的并行度和接口请求频率
|
||||
- [ ] 下载单个文件时支持断点续传与并发下载
|
||||
- [x] 支持单个文件的分块并行下载
|
||||
- [x] 支持使用 Web UI 配置，查看并管理视频、视频源
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 常见问题
|
||||
|
||||
## 各种文件找不到问题，如运行后找不到初始 `config.toml`、提示成功下载但看不到视频文件等。
|
||||
## 各种文件找不到问题，如运行后找不到初始 `data.sqlite`、提示成功下载但看不到视频文件等。
|
||||
|
||||
请检查挂载位置与配置文件填写是否正确，需要理解的是：
|
||||
1. 容器挂载是把宿主机的 `/A` 挂载到容器内的 `/B`；
|
||||
@@ -22,4 +22,6 @@ bili-sync 在 2.4.0 版本引入了一个改动，不将此错误计入错误次
|
||||
|
||||
## 有些视频已经达到了最大重试次数还没有成功，我可以手动重试吗？
|
||||
|
||||
2.4.0 版本引入了一个简陋的[管理页](/frontend)来支持这个功能，你可以查询特定视频并点击重置，这样在下次下载任务触发时就会重试这个任务了。
|
||||
可以在 WebUI 中查找对应的视频源并点击“重置”，这会将所有失败的子任务重置为未下载状态，下一次视频下载任务就会开始重试。
|
||||
|
||||
此外还可以进入视频详情点击“编辑状态”，这允许用户自行修改每个子任务的状态。
|
||||
@@ -1,6 +1,6 @@
|
||||
# 快速开始
|
||||
|
||||
程序使用 Rust 编写，不需要 Runtime 且并为各个平台提供了预编译文件，绝大多数情况下是没有使用障碍的。
|
||||
程序使用 Rust 编写，不需要 Runtime 且内嵌 WebUI，并为各个平台提供了预编译的二进制文件，因此部署较为简单。
|
||||
|
||||
## 程序获取
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
### 其一：下载平台二进制文件运行
|
||||
|
||||
> [!CAUTION]
|
||||
> 如果你使用这种方式运行，请确保 FFmpeg 已被正确安装且位于 PATH 中，可通过执行 `ffmpeg` 命令访问。
|
||||
> 如果你使用这种方式运行，请确保 FFmpeg 已被正确安装且位于 PATH 中，可直接通过 `ffmpeg` 命令访问。
|
||||
|
||||
在[程序发布页](https://github.com/amtoaer/bili-sync/releases)选择最新版本中对应机器架构的压缩包，解压后会获取一个名为 `bili-sync-rs` 的可执行文件，直接双击执行。
|
||||
|
||||
@@ -39,9 +39,12 @@ services:
|
||||
- 12345:12345
|
||||
volumes:
|
||||
- ${你希望存储程序配置的目录}:/app/.config/bili-sync
|
||||
# 还需要有一些其它必要的挂载，包括 up 主信息位置、视频下载位置
|
||||
# 这些目录不是固定的，只需要确保此处的挂载与 bili-sync-rs 的配置文件相匹配
|
||||
# ...
|
||||
# metadata/people 正确挂载才能在 Emby 或 Jellyfin 中显示 UP 主头像
|
||||
# 右边的目标目录不固定，只需要确保目标目录与 bili-sync 中填写的“UP 主头像保存路径”保持一致即可
|
||||
- ${Emby 或 Jellyfin 配置下的 metadata/people 目录}:/app/.config/bili-sync/upper_face
|
||||
# 接下来可以挂载一系列用于保存视频的目录，接着在 bili-sync 中配置将视频下载到这些目录即可
|
||||
# 例如：
|
||||
# - /home/amtoaer/HDDs/Videos/Bilibilis/:/home/amtoaer/HDDs/Videos/Bilibilis/
|
||||
# 如果你使用的是群晖系统，请移除最后的 logging 配置，否则会导致日志不显示
|
||||
logging:
|
||||
driver: "local"
|
||||
@@ -49,11 +52,23 @@ services:
|
||||
|
||||
使用该 compose 文件，执行 `docker compose up -d` 即可运行。
|
||||
|
||||
## 程序配置
|
||||
## 进行必要配置
|
||||
|
||||
你是否遇到了程序的 panic？别担心，这是正常情况。
|
||||
运行程序，应该可以在日志中看到：
|
||||
```
|
||||
Jul 12 16:11:10 INFO 欢迎使用 Bili-Sync，当前程序版本：xxxxx
|
||||
Jul 12 16:11:10 INFO 项目地址：https://github.com/amtoaer/bili-sync
|
||||
Jul 12 16:11:10 INFO 数据库初始化完成
|
||||
Jul 12 17:17:50 WARN 生成 auth_token：xxxxxxxx，可使用该 token 登录 web UI，该信息仅在首次运行时打印
|
||||
Jul 12 16:11:10 INFO 配置初始化完成
|
||||
Jul 12 16:11:10 INFO 开始运行管理页: http://0.0.0.0:12345
|
||||
```
|
||||
|
||||
程序默认会将配置文件存储于 `${config_dir}/bili-sync/config.toml`，数据库文件存储于 `${config_dir}/bili-sync/data.sqlite`。
|
||||
中间应该会穿插一条 CONFIG 的报错，这是因为配置文件内容缺失导致视频下载任务未能运行，在初次启动时是正常现象。
|
||||
|
||||
自 2.6.0 版本开始，程序仅会创建一个数据库文件，配置同样在数据库表中进行维护。
|
||||
|
||||
数据库文件存储于 `${config_dir}/bili-sync/data.sqlite`。
|
||||
|
||||
> [!CAUTION]
|
||||
>
|
||||
@@ -67,154 +82,28 @@ services:
|
||||
>
|
||||
> 特别的，在 Docker 环境中，`config_dir` 会被展开为 `/app/.config`。
|
||||
|
||||
在启动时程序会尝试加载配置文件，如果发现不存在会新建并写入默认配置。
|
||||
接着打开 WebUI，切换到设置页，输入日志中打印的 `auth_token`，点击认证。
|
||||
|
||||
获得配置内容后，程序会对其做一次简单的校验，因为默认配置中不包含凭据信息与要下载的收藏夹、视频合集/视频列表，因此程序会拒绝运行而发生 panic。我们只需要在程序生成的默认配置上做一些简单修改即可成功运行。
|
||||
|
||||
|
||||
当前版本的默认示例文件如下：
|
||||
```toml
|
||||
auth_token = "xxxxxxxx"
|
||||
bind_address = "0.0.0.0:12345"
|
||||
video_name = "{{title}}"
|
||||
page_name = "{{bvid}}"
|
||||
interval = 1200
|
||||
upper_path = "/Users/amtoaer/Library/Application Support/bili-sync/upper_face"
|
||||
nfo_time_type = "favtime"
|
||||
time_format = "%Y-%m-%d"
|
||||
cdn_sorting = false
|
||||
认证后会看到一系列的配置，除绑定地址外的选项**基本都会实时生效**。为避免意料外的情况，建议将配置文件一次修改完毕后再点击保存。
|
||||
|
||||
[credential]
|
||||
sessdata = ""
|
||||
bili_jct = ""
|
||||
buvid3 = ""
|
||||
dedeuserid = ""
|
||||
ac_time_value = ""
|
||||
如无特殊需求，一般仅需修改“B站认证”与“视频质量”两个标签下的配置。
|
||||
|
||||
[filter_option]
|
||||
video_max_quality = "Quality8k"
|
||||
video_min_quality = "Quality360p"
|
||||
audio_max_quality = "QualityHiRES"
|
||||
audio_min_quality = "Quality64k"
|
||||
codecs = [
|
||||
"AV1",
|
||||
"HEV",
|
||||
"AVC",
|
||||
]
|
||||
no_dolby_video = false
|
||||
no_dolby_audio = false
|
||||
no_hdr = false
|
||||
no_hires = false
|
||||
其中“B站认证”在一次填写后即可忽略，程序会在**每日第一次运行视频下载任务**时检查认证状态，并在有必要时自动刷新。
|
||||
|
||||
[danmaku_option]
|
||||
duration = 15.0
|
||||
font = "黑体"
|
||||
font_size = 25
|
||||
width_ratio = 1.2
|
||||
horizontal_gap = 20.0
|
||||
lane_size = 32
|
||||
float_percentage = 0.5
|
||||
bottom_percentage = 0.3
|
||||
opacity = 76
|
||||
bold = true
|
||||
outline = 0.8
|
||||
time_offset = 0.0
|
||||
对于这些设置项的含义，请参考[配置说明](./configuration.md)，可善用右侧导航在不同配置项间跳转。
|
||||
|
||||
[favorite_list]
|
||||
## 添加视频源订阅
|
||||
|
||||
[collection_list]
|
||||
配置完毕后，我们便可以随时添加视频源订阅。
|
||||
|
||||
[submission_list]
|
||||
用户在正确填写“B站认证”后可以在“快捷订阅”部分查看自己创建的收藏夹、关注的合集与 UP 主一键订阅，也可以在“视频源”页手动添加并管理。
|
||||
|
||||
[watch_later]
|
||||
enabled = false
|
||||
path = ""
|
||||
对于手动添加的视频源，可参考如下页面获取所需的参数：
|
||||
|
||||
[concurrent_limit]
|
||||
video = 3
|
||||
page = 2
|
||||
- [收藏夹](./favorite.md)
|
||||
- [合集 / 列表](./collection.md)
|
||||
- [用户投稿](./submission.md)
|
||||
|
||||
[concurrent_limit.rate_limit]
|
||||
limit = 4
|
||||
duration = 250
|
||||
```
|
||||
|
||||
虽然配置文件看起来很长，但绝大部分选项是不需要做修改的。一般来说，我们只需要关注其中的少数几个，以下逐条说明。
|
||||
|
||||
### `auth_token`
|
||||
|
||||
表示调用程序管理 API 需要的身份凭据，程序会检查 API 请求 Header 中是否包含正确的 `Authorization` 字段。
|
||||
|
||||
内置管理页前端提供了 `auth_token` 的输入框，填写后即可成功调用 API 使用管理页。
|
||||
|
||||
### `bind_address`
|
||||
|
||||
程序 Web Server 监听的地址，程序启动时会监听该地址，成功后可通过 `http://${bind_address}` 访问管理页。
|
||||
|
||||
### `interval`
|
||||
|
||||
表示程序每次执行扫描下载的间隔时间，单位为秒。
|
||||
|
||||
### `upper_path`
|
||||
|
||||
UP 主头像和信息的保存位置。对于使用 Emby、Jellyfin 媒体服务器的用户，需确保此处路径指向 Emby、Jellyfin 配置中的 `/metadata/people/` 才能够正常在媒体服务器中显示 UP 主的头像。
|
||||
|
||||
### `credential`
|
||||
|
||||
哔哩哔哩账号的身份凭据，请参考[凭据获取流程](https://nemo2011.github.io/bilibili-api/#/get-credential)获取并对应填写至配置文件中，后续 bili-sync 会在必要时自动刷新身份凭据，不再需要手动管理。
|
||||
|
||||
推荐使用匿名窗口获取，避免潜在的冲突。
|
||||
|
||||
### `codecs`
|
||||
|
||||
这是 bili-sync 选择视频编码的优先级顺序，优先级按顺序从高到低。此处对编码格式做一个简单说明：
|
||||
|
||||
+ AVC 又称 H.264，是目前使用最广泛的视频编码格式，绝大部分设备可以使用硬件解码播放该格式的视频（也因此播放普遍流畅），但是同等画质下视频体积较大。
|
||||
|
||||
+ HEV(C) 又称 H.265，与 AV1 都是新一代的视频编码格式。这两种编码相比 AVC 有更好的压缩率，同等画质下视频体积更小，但由于相对较新，硬件解码支持不如 AVC 广泛。如果你的播放设备不支持则只能使用软件解码播放，这种情况下可能导致播放卡顿、机器发热等问题。
|
||||
|
||||
建议查阅自己常用播放设备对这三种编码的硬件解码支持情况以选择合适的编码格式，如果硬件支持 HEV 或 AV1，那么可以将其优先级调高。
|
||||
|
||||
而如果你的设备不支持，或者单纯懒得查询，那么推荐将 AVC 放在第一位以获得最好的兼容性。
|
||||
|
||||
### `favorite_list`
|
||||
|
||||
你想要下载的收藏夹与想要保存的位置。简单示例：
|
||||
```toml
|
||||
3115878158 = "/home/amtoaer/Downloads/bili-sync/测试收藏夹"
|
||||
```
|
||||
收藏夹 ID 的获取方式可以参考[这里](/favorite)。
|
||||
|
||||
### `collection_list`
|
||||
|
||||
你想要下载的视频合集/视频列表与想要保存的位置。注意“视频合集”与“视频列表”是两种不同的类型。在配置文件中需要做区分：
|
||||
```toml
|
||||
"series:387051756:432248" = "/home/amtoaer/Downloads/bili-sync/测试视频列表"
|
||||
"season:1728547:101343" = "/home/amtoaer/Downloads/bili-sync/测试合集"
|
||||
```
|
||||
|
||||
具体说明可以参考[这里](/collection)。
|
||||
|
||||
### `submission_list`
|
||||
|
||||
你想要下载的 UP 主投稿与想要保存的位置。简单示例：
|
||||
```toml
|
||||
9183758 = "/home/amtoaer/Downloads/bili-sync/测试投稿"
|
||||
```
|
||||
UP 主 ID 的获取方式可以参考[这里](/submission)。
|
||||
|
||||
### `watch_later`
|
||||
|
||||
设置稍后再看的扫描开关与保存位置。
|
||||
|
||||
如果你希望下载稍后再看列表中的视频，可以将 `enabled` 设置为 `true`，并填写 `path`。
|
||||
|
||||
```toml
|
||||
enabled = true
|
||||
path = "/home/amtoaer/Downloads/bili-sync/稍后再看"
|
||||
```
|
||||
|
||||
## 运行
|
||||
|
||||
在配置文件填写完毕后，我们可以直接运行程序。如果配置文件无误，程序会自动开始下载收藏夹中的视频。并每隔 `interval` 秒重新扫描一次。
|
||||
|
||||
如果你希望了解更详细的配置项说明，可以查询[这里](/configuration)。
|
||||
添加完订阅就无需进行任何干预了，视频下载任务会在后台每隔特定时间（由配置中的“同步间隔”决定）自动运行一次，刷新并下载启用的视频源！
|
||||
@@ -1,4 +1,4 @@
|
||||
# 获取 UP 主信息
|
||||
# 获取用户投稿信息
|
||||
|
||||
UP 主 的 ID 获取也很简单，在网页端打开想要获取投稿的 UP 主首页，直接查看网址栏中的数字或页面中的个人信息即可。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user