mirror of
https://github.com/EstrellaXD/Auto_Bangumi.git
synced 2026-11-02 21:55:22 +08:00
docs(4.0): 新增 3.3 升级到 4.0 指南与 4.0 更新日志，更新部署页与首页
This commit is contained in:
Estrella Pan
75
docs/changelog/4.0.md
Normal file
75
docs/changelog/4.0.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# [4.0] — Beta
|
||||
|
||||
4.0 是插件化重构的大版本：下载、通知、解析、搜索、重命名与整理都通过同一套扩展点实现，内置功能与第三方插件走相同的接口。下载器可以有多个实例，重命名、硬链接、种子过滤与媒体库刷新由内置插件提供。只支持从 3.3.x 升级，第一次启动时自动迁移配置并备份原文件。
|
||||
|
||||
升级步骤、回滚方法与升级后的检查项见 [从 3.3 升级到 4.0](../deploy/upgrade-4.0)。
|
||||
|
||||
## 4.0.0-beta.1
|
||||
|
||||
Docker 镜像：`ghcr.io/estrellaxd/auto_bangumi:4.0.0-beta.1`（`dev-latest` 也指向最新测试版）。
|
||||
|
||||
### 破坏性变更
|
||||
|
||||
- **只支持从 3.3.x 升级。** 检测到更早版本的数据（`config/version.info` 低于 3.3，或残留 2.x 的 `data/data.json`）时拒绝启动，并提示先升级到最新的 3.3.x 启动一次。
|
||||
- **配置结构变化，自动迁移。** 下载器改为 `plugins.instances` 中的实例，`plugins.slots.downloader` 指向默认实例；重命名方式与版本冲突策略移到 `plugins.slots.rename_strategy` / `plugins.slots.conflict_policy`。第一次启动时自动迁移 3.3 的 `downloader`、`bangumi_manage.rename_method`、`bangumi_manage.revision_conflict_policy`，原文件备份为 `config.json.v3.bak`（已有备份时另存为 `config.json.v3.bak.1` 等，不覆盖）。迁移失败时 `config.json` 保持原样、拒绝启动，日志写明出错的字段。`AB_DOWNLOADER_*`、`AB_DOWNLOAD_PATH`、`AB_METHOD`、`AB_REVISION_CONFLICT_POLICY` 环境变量照常生效。
|
||||
- **通知渠道旧字段。** Bark 不再读取 `token`（改用 `device_key`），WeCom 不再读取 `chat_id`（改用 `webhook_url`）。升级时自动迁移。
|
||||
- **移除旧 API。** 3.2 兼容的 GET 控制端点（`/api/v1/restart`、`/start`、`/stop`、`/shutdown`）和 `GET /api/v1/auth/refresh_token` 已移除，请改用 POST。
|
||||
- **移除旧配置。** 移除 `experimental_openai` 配置节与通知的单渠道旧字段（3.3 已迁移到 `llm` 与 `notification.providers`）；移除废弃的 `normal` 重命名方式，已有配置自动改为行为相同的 `none`。
|
||||
- 数据库自动升级到 schema v26（新增插件存储表与 `downloader_id` 列）。
|
||||
|
||||
### 插件系统
|
||||
|
||||
- 新增插件运行时：插件可以来自内置目录、签名插件目录、本地目录（`config/plugins/local/`）或 pip 包。本地与 pip 插件未签名，需开启 **设置 → 插件 → 允许未签名插件**（`plugins.allow_unsigned`）才会加载。
|
||||
- 插件可以提供下载器、通知渠道、LLM 解析提供商、搜索站点、元数据源和定时任务。内置的 qBittorrent / aria2 与各通知渠道走同一套扩展点。下载器类型、通知渠道、订阅解析器的下拉框会列出插件提供的选项。
|
||||
- 插件可以在 RSS 下载流程中过滤种子、修正解析结果、修改保存路径 / 分类 / 标签，或为私有站点的请求添加 Cookie 等请求头。
|
||||
- 设置页新增「插件」卡片：查看状态、启停插件，并通过自动生成的表单修改插件配置；秘密字段在读取接口中一律掩码。
|
||||
- 签名插件目录：`GET /api/v1/plugins/catalog` 列出目录中的插件，`POST /api/v1/plugins/{id}/install` 验证 sha256 与 ed25519 签名后安装并启用，`DELETE /api/v1/plugins/{id}` 卸载。
|
||||
- 插件的钩子调用有超时。同一插件连续失败 5 次后被自动禁用，修复后在设置页重新启用即可。
|
||||
|
||||
### 多下载器
|
||||
|
||||
- **设置 → 下载设置** 可以添加多个下载器实例（qBittorrent、aria2 或插件提供的下载器）并指定默认实例。
|
||||
- 规则与 RSS 订阅可以选择下载器，留空时用默认实例；由订阅新建的规则继承订阅的选择。
|
||||
- 每个种子记录它所在的下载器，重命名、删除都在该下载器上进行。规则改用另一个下载器后，已有种子留在原处。
|
||||
- 重命名逐个下载器运行。连不上的下载器被跳过，并在第一次连不上时发送「下载器连接异常」通知。
|
||||
- 下载器页与种子列表标出种子所在的下载器。`GET /api/v1/downloader/torrents` 汇总所有实例，暂停 / 恢复 / 删除 / 打标接口新增 `downloader_id`，新增 `GET /api/v1/downloader/instances`。
|
||||
|
||||
### 重命名与整理
|
||||
|
||||
- 重命名改为插件：`pn` / `advance` / `template` 由默认启用的内置插件「重命名」（`rename`）提供，`none` 由 AB 本身提供。`pn` / `advance` 的输出与 3.3 逐字一致。字幕与正片使用同一种方式。
|
||||
- 新增 `template` 重命名方式：用模板自定义文件名，默认模板对普通剧集与 `pn` 相同（剧场版 `pn` 不加 `SxxExx`，默认模板会加）。保存时试渲染，不合法的模板直接拒绝；运行时渲染失败的文件保留原名并发送「文件未重命名」通知，不会退回 `pn`。
|
||||
- 新增内置插件「硬链接到媒体库」（`hardlink`，默认停用）：种子整理完成后把正片与字幕链接到媒体库目录，下载目录继续做种。按下载器实例配置路径映射（`path_map`）；跨文件系统时默认复制。不覆盖不是它创建的文件，版本升级后替换自己创建的链接；复制中断不会在媒体库留下半个文件。已有文件可通过 `POST /api/v1/plugins/hardlink/backfill` 补链。
|
||||
- 新增内置插件「媒体库刷新」（`media-server-refresh`）：填写 Jellyfin / Emby / Plex 地址与 API Key 后，合并一段时间内整理完成的种子，请求刷新媒体库。未配置时不做任何事。
|
||||
- 新增内置插件「种子过滤」（`ingest-filters`，默认启用）：填写「包含过滤」后，只下载名称匹配任一表达式的种子（对所有订阅生效）；留空时不过滤。
|
||||
|
||||
### 事件、API 与 MCP
|
||||
|
||||
- 系统事件（RSS 订阅异常、种子添加失败、下载器不可用、新版本、文件重命名、种子整理完成等）发布到事件总线，插件可以订阅。
|
||||
- 插件可以提供 REST 路由（挂载于 `/api/v1/plugins/<插件 id>/`，需要登录）、MCP 工具与 MCP 资源，并可以按事件类型和渠道改写系统通知的标题与正文。
|
||||
- 插件可以发出通知，通知进入通知中心。
|
||||
- 通知中心改为事件推送：有新消息、已读或删除时立即更新（原先每 3 秒检查一次）。
|
||||
|
||||
### 前端插件
|
||||
|
||||
- WebUI 新增插件挂载点，插件可以在指定位置加入自己的界面（Web Component）。内置的硬链接插件用它提供补链按钮。
|
||||
- 新增示例插件 `manual-pick`（手动选种），演示前端挂载点。
|
||||
|
||||
### 插件开发工具
|
||||
|
||||
- 插件 SDK `ab_sdk` 单独打包为 `autobangumi-sdk` 轮子，随 GitHub Release 发布（不发布到 PyPI）。
|
||||
- 新增 `ab-plugin` 命令行：`new` 生成插件骨架与契约测试，`validate` 校验清单与 SDK 版本范围，`pack` 打包为可安装的 zip，`dev` 把插件目录链接到 `config/plugins/local/` 并开启 `plugins.dev_mode`。开启 `dev_mode` 后，修改本地插件的文件会自动重新加载该插件。
|
||||
- `ab_sdk.testing` 提供下载器、重命名方式、通知渠道、搜索站点的契约测试套件。
|
||||
- 新增 5 个示例插件（`examples/plugins/`，CI 逐个运行它们的测试）：`webhook-on-event`、`custom-rss-site`、`template-rename`、`nfo-writer`、`ntfy-notifier`。
|
||||
- 新增插件作者 agent skill，随 GitHub Release 以 `autobangumi-plugin-skill-<版本>.zip` 发布。
|
||||
- 插件开发文档拆为总览、核心概念与每个扩展点一页（中 / 英 / 日），见 [插件开发](../dev/plugins)。
|
||||
|
||||
### 修复
|
||||
|
||||
- 新保存的搜索站点要重启后才出现在搜索站点列表中；现在立即出现。
|
||||
- MCP 客户端断开 SSE 连接后，日志出现 `AssertionError: Unexpected message http.response.start`（3.x 起存在）。
|
||||
- 插件配置的校验器报错时，保存接口返回 500 而不是 422。
|
||||
- `version.info` 只比较次版本号，跨主版本升级（如 3.3 → 4.0）不会被记录。
|
||||
|
||||
### 清理
|
||||
|
||||
- 删除 3.0 → 3.1、3.1 → 3.2 跨版本迁移、旧 JWT 与内存会话实现，以及约 70 处无调用方的代码；CI 新增死代码检查。
|
||||
@@ -1,5 +1,9 @@
|
||||
# 使用 Docker CLI 部署
|
||||
|
||||
::: tip 4.0 测试版
|
||||
本页命令使用 `latest` 标签，安装的是 3.3 正式版。要使用 4.0 测试版，把镜像标签换成 `4.0.0-beta.N`（例如 `4.0.0-beta.1`）；挂载卷与环境变量不变。从 3.3 升级前请阅读 [从 3.3 升级到 4.0](./upgrade-4.0)。4.0 的硬链接插件需要把媒体库目录也挂载进容器，见 [番剧管理设置](../config/manager)。
|
||||
:::
|
||||
|
||||
## 新版本说明
|
||||
|
||||
从 AutoBangumi 2.6 开始，您可以直接在 WebUI 中配置所有设置。您可以先启动容器，然后在 WebUI 中进行配置。旧版本的环境变量配置将自动迁移。环境变量仍然有效，但仅在首次启动时生效。
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
|
||||
使用 `docker-compose.yml` 文件一键部署 **AutoBangumi**。
|
||||
|
||||
::: tip 4.0 测试版
|
||||
本页命令使用 `latest` 标签，安装的是 3.3 正式版。要使用 4.0 测试版，把镜像标签换成 `4.0.0-beta.N`（例如 `4.0.0-beta.1`）；挂载卷与环境变量不变。从 3.3 升级前请阅读 [从 3.3 升级到 4.0](./upgrade-4.0)。4.0 的硬链接插件需要把媒体库目录也挂载进容器，见 [番剧管理设置](../config/manager)。
|
||||
:::
|
||||
|
||||
## 安装 Docker Compose
|
||||
|
||||
Docker Compose 通常与 Docker 捆绑安装。使用以下命令检查：
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
|
||||
DSM 7.2 支持 Docker Compose，因此我们建议使用 Docker Compose 进行一键部署。
|
||||
|
||||
::: tip 4.0 测试版
|
||||
本页使用 `latest` 标签，安装的是 3.3 正式版。要使用 4.0 测试版，把镜像标签换成 `4.0.0-beta.N`（例如 `4.0.0-beta.1`）。从 3.3 升级前请阅读 [从 3.3 升级到 4.0](./upgrade-4.0)。
|
||||
:::
|
||||
|
||||
## 创建配置和数据目录
|
||||
|
||||
在 `/volume1/docker/` 下创建 `AutoBangumi` 文件夹，然后在其中创建 `config` 和 `data` 子文件夹。
|
||||
|
||||
@@ -3,6 +3,10 @@
|
||||
我们推荐使用 Docker 部署 AutoBangumi。
|
||||
部署前，请确保已安装 [Docker Engine][docker-engine] 或 [Docker Desktop][docker-desktop]。
|
||||
|
||||
::: tip 4.0 测试版
|
||||
本页命令使用 `latest` 标签，安装的是 3.3 正式版。要使用 4.0 测试版，把镜像标签换成 `4.0.0-beta.N`（例如 `4.0.0-beta.1`）；挂载卷与环境变量不变。从 3.3 升级前请阅读 [从 3.3 升级到 4.0](./upgrade-4.0)。4.0 的硬链接插件需要把媒体库目录也挂载进容器，见 [番剧管理设置](../config/manager)。
|
||||
:::
|
||||
|
||||
## 创建数据和配置目录
|
||||
|
||||
为确保 AB 的数据和配置在更新时持久化，我们建议使用绑定挂载或 Docker 卷。
|
||||
|
||||
199
docs/deploy/upgrade-4.0.md
Normal file
199
docs/deploy/upgrade-4.0.md
Normal file
@@ -0,0 +1,199 @@
|
||||
# 从 3.3 升级到 4.0
|
||||
|
||||
4.0 是插件化重构的大版本：下载器改为可以有多个的实例，重命名、硬链接、种子过滤、媒体库刷新改由内置插件提供。第一次启动时，AB 会自动把 3.3 的配置迁移到新位置。本页说明迁移改了什么、如何升级、升级后检查什么，以及如何回滚到 3.3。
|
||||
|
||||
::: warning 4.0 目前是测试版
|
||||
4.0 只以 `4.0.0-beta.N` 测试版发布。`latest` 镜像标签在 4.0 正式版发布前仍指向 3.3。生产环境请先完成下面的备份。
|
||||
:::
|
||||
|
||||
## 升级前
|
||||
|
||||
1. **确认当前版本是 3.3.x。** 4.0 只支持从 3.3.x 升级。检测到更早版本的数据（`config/version.info` 记录的版本低于 3.3，或残留 2.x 的 `data/data.json`）时，AB 拒绝启动，并提示先升级到最新的 3.3.x 启动一次。被拒绝时 `config.json` 可能已经被改写为 4.0 格式，请先用 `config.json.v3.bak` 覆盖它，再换回 3.3.x。
|
||||
2. **停止容器，备份 `config` 与 `data` 两个目录。** 回滚到 3.3 时需要这两份备份（见 [回滚到 3.3](#回滚到-3-3)）。
|
||||
|
||||
```shell
|
||||
docker stop AutoBangumi
|
||||
cp -a ${HOME}/AutoBangumi/config ${HOME}/AutoBangumi/config.bak-3.3
|
||||
cp -a ${HOME}/AutoBangumi/data ${HOME}/AutoBangumi/data.bak-3.3
|
||||
```
|
||||
|
||||
## 更换镜像标签
|
||||
|
||||
4.0 测试版的镜像标签：
|
||||
|
||||
| 标签 | 含义 |
|
||||
| --- | --- |
|
||||
| `4.0.0-beta.N` | 指定的测试版，例如 `4.0.0-beta.1`。**推荐**，升级与回滚都可控 |
|
||||
| `dev-latest` | 最新推送的测试版。任何 `X.Y.Z-beta.N` 发布都会更新它，不只是 4.0 |
|
||||
| `latest` | 最新正式版。4.0 正式版发布前仍是 3.3 |
|
||||
|
||||
镜像同时发布到 `ghcr.io/estrellaxd/auto_bangumi` 与 Docker Hub 的 `estrellaxd/auto_bangumi`。
|
||||
|
||||
Docker Compose：修改 `image` 后重新创建容器。
|
||||
|
||||
```yaml
|
||||
services:
|
||||
AutoBangumi:
|
||||
image: "ghcr.io/estrellaxd/auto_bangumi:4.0.0-beta.1"
|
||||
```
|
||||
|
||||
```shell
|
||||
docker compose pull
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Docker CLI：删除旧容器，用新标签和原来的参数重新运行 `docker run`。
|
||||
|
||||
挂载卷（`/app/config`、`/app/data`）、端口与环境变量都没有变化，4.0 没有新增环境变量。插件安装在 `config/plugins/` 下，已经包含在 `/app/config` 卷里。
|
||||
|
||||
### 应用内更新（3.3 测试版渠道）
|
||||
|
||||
3.3 中更新渠道选择「测试版」的用户，会在 **设置 → 软件更新** 看到 `4.0.0-beta.N`。4.0 的更新包要求镜像版本不低于 `4.0.0-beta.1`，3.3 镜像上点击 **立即更新** 会失败，提示镜像版本过低、需要拉取新镜像。请按上一节更换镜像标签。选择「稳定版」渠道的用户不会看到 4.0 测试版。
|
||||
|
||||
## 第一次启动：配置迁移
|
||||
|
||||
AB 在读取 `config.json` 之前检查它是不是 3.3 格式。是 3.3 格式时，先把原文件备份为 `config.json.v3.bak`，再把下列字段移到 4.0 的位置：
|
||||
|
||||
| 3.3 字段 | 4.0 位置 |
|
||||
| --- | --- |
|
||||
| `downloader` | `plugins.instances` 中 id 为 `default` 的下载器实例：`type` 变为 `provider`，其它字段（地址、用户名、密码、下载路径、SSL）放入 `options` |
|
||||
| — | `plugins.slots.downloader` 设为 `"default"`（默认下载器实例） |
|
||||
| `bangumi_manage.rename_method` | `plugins.slots.rename_strategy`。已废弃的 `normal` 改为语义相同的 `none` |
|
||||
| `bangumi_manage.revision_conflict_policy` | `plugins.slots.conflict_policy` |
|
||||
| Bark 渠道的 `token` | `device_key` |
|
||||
| WeCom 渠道的 `chat_id` | `webhook_url` |
|
||||
|
||||
迁移前后的下载器配置示例：
|
||||
|
||||
::: code-group
|
||||
|
||||
```json [3.3]
|
||||
{
|
||||
"downloader": {
|
||||
"type": "qbittorrent",
|
||||
"host": "172.17.0.1:8080",
|
||||
"username": "admin",
|
||||
"password": "adminadmin",
|
||||
"path": "/downloads/Bangumi",
|
||||
"ssl": false
|
||||
},
|
||||
"bangumi_manage": {
|
||||
"rename_method": "pn",
|
||||
"revision_conflict_policy": "hold"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```json [4.0]
|
||||
{
|
||||
"plugins": {
|
||||
"slots": {
|
||||
"downloader": "default",
|
||||
"rename_strategy": "pn",
|
||||
"conflict_policy": "hold"
|
||||
},
|
||||
"instances": [
|
||||
{
|
||||
"id": "default",
|
||||
"point": "downloader",
|
||||
"provider": "qbittorrent",
|
||||
"options": {
|
||||
"host": "172.17.0.1:8080",
|
||||
"username": "admin",
|
||||
"password": "adminadmin",
|
||||
"path": "/downloads/Bangumi",
|
||||
"ssl": false
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
示例只列出相关字段；其它设置保持原样。
|
||||
|
||||
- **备份不会被覆盖。** 已有 `config.json.v3.bak` 时（例如回滚到 3.3 后再次升级），新的备份另存为 `config.json.v3.bak.1`、`config.json.v3.bak.2` 等。第一份备份里是最早的 3.3 配置。
|
||||
- **迁移成功**时，日志出现 `Migrated config.json to 4.0 (...); the 3.3 file is kept as config.json.v3.bak`，括号里列出被移动的字段。
|
||||
- **迁移失败**时，`config.json` 保持 3.3 的内容，AB 拒绝启动，日志写明出错的字段。修正该字段后重新启动即可。
|
||||
- 已经是 4.0 格式的配置不会再迁移，也不会再生成备份。
|
||||
- 环境变量（`AB_DOWNLOADER_HOST`、`AB_METHOD` 等）照常生效，仍然只在没有 `config.json` 的首次启动时读取；它们的值写入默认下载器实例与 `plugins.slots`。
|
||||
|
||||
数据库在同一次启动中自动升级到 schema v26：新增插件存储表 `plugin_kv`，番剧、电影、RSS 订阅与种子新增 `downloader_id` 列。已有种子归属 `default` 实例；已有规则与订阅的 `downloader_id` 为空，表示跟随默认实例。
|
||||
|
||||
## 4.0 中改变的行为
|
||||
|
||||
### 多个下载器
|
||||
|
||||
**设置 → 下载设置** 可以添加多个下载器实例（qBittorrent、aria2 或插件提供的下载器）并指定默认实例。规则与 RSS 订阅可以选择下载器，留空时用默认实例。每个种子记录它所在的下载器，重命名与删除都在该下载器上进行。详见 [下载器设置](../config/downloader)。
|
||||
|
||||
### 重命名改为插件
|
||||
|
||||
`pn`、`advance` 与新增的 `template` 由默认启用的内置插件「重命名」（`rename`）提供，`none` 由 AB 本身提供。`pn` 与 `advance` 的输出与 3.3 逐字一致。
|
||||
|
||||
- `template` 用自定义模板生成文件名。保存设置时 AB 试渲染模板，不合法的模板直接拒绝保存。
|
||||
- 运行时某个文件的模板渲染失败，该文件保留原名，并发送「文件未重命名」通知；不会退回 `pn`。
|
||||
- 在 **设置 → 插件** 中停用「重命名」插件后，所有番剧按 `none` 处理，保留原文件名。
|
||||
|
||||
详见 [番剧管理设置](../config/manager)。
|
||||
|
||||
### 硬链接到媒体库
|
||||
|
||||
新增内置插件「硬链接到媒体库」（`hardlink`），**默认停用**。启用后，种子整理完成时把正片与字幕链接到媒体库目录，下载目录保持原样继续做种。
|
||||
|
||||
- 下载器与 AB 看到的路径不同时（例如分别运行在不同容器中），按下载器实例在 `path_map` 中配置路径映射。
|
||||
- 无法创建硬链接（跨文件系统）时，默认复制文件（`cross_device: copy`）。
|
||||
- 在 Docker 中，媒体库目录也要挂载进 AB 容器。要使用硬链接，请把下载目录与媒体库放在同一块盘上，并以同一个挂载点映射进容器。
|
||||
|
||||
详见 [番剧管理设置](../config/manager)。
|
||||
|
||||
### 其它内置插件
|
||||
|
||||
- 「种子过滤」（`ingest-filters`）默认启用。「包含过滤」留空时不过滤任何种子。
|
||||
- 「媒体库刷新」（`media-server-refresh`）默认启用。填写 Jellyfin / Emby / Plex 的地址与 API Key 后才会请求刷新媒体库。
|
||||
|
||||
### 第三方插件
|
||||
|
||||
本地目录（`config/plugins/local/`）与 pip 安装的插件没有签名，需要在 **设置 → 插件** 中开启「允许未签名插件」（`plugins.allow_unsigned`）才会加载。插件开发见 [插件开发](../dev/plugins)。
|
||||
|
||||
### 移除的功能
|
||||
|
||||
- 3.2 兼容的 GET 控制端点（`/api/v1/restart`、`/start`、`/stop`、`/shutdown`）和 `GET /api/v1/auth/refresh_token`。请改用 POST。调用这些端点的脚本需要修改。
|
||||
- 旧版 `experimental_openai` 配置节与通知的单渠道旧字段。3.3 已把它们迁移到 `llm` 与 `notification.providers`。
|
||||
|
||||
## 升级后检查
|
||||
|
||||
- [ ] 日志中有 `Migrated config.json to 4.0` 一行，`config` 目录中有 `config.json.v3.bak`。
|
||||
- [ ] **设置 → 下载设置** 中有 id 为 `default` 的实例，地址、用户名与下载路径与 3.3 相同，并且能连接。
|
||||
- [ ] 重命名方式与 3.3 相同。3.3 中的 `normal` 现在显示为 `none`，行为相同：不重命名文件。
|
||||
- [ ] **设置 → 插件** 中「重命名」插件处于启用状态。
|
||||
- [ ] 使用 Bark 或 WeCom 通知时，发送一条测试通知。
|
||||
- [ ] 需要硬链接或媒体库刷新时，在 **设置 → 插件** 中启用并配置它们。
|
||||
- [ ] 使用 3.2 的 GET 控制端点的脚本已改为 POST。
|
||||
|
||||
## 回滚到 3.3
|
||||
|
||||
::: danger 先处理 `version.info`
|
||||
4.0 会在 `config/version.info` 末尾追加一行 `4.0.0-beta.N`。3.3 只比较次版本号：最后一行是 4.0 时，3.3 会把数据当作 3.0 的数据，重建全部数据表，只保留番剧规则和第一个用户，种子记录等其它数据全部丢失。回滚前必须还原 `data` 备份，或删除 `version.info` 中 4.x 的行。
|
||||
:::
|
||||
|
||||
**有升级前的完整备份时**（推荐）：
|
||||
|
||||
1. 停止容器。
|
||||
2. 用 `config.bak-3.3` 与 `data.bak-3.3` 替换 `config` 与 `data` 目录。
|
||||
3. 把镜像标签改回 3.3（例如 `3.3.6`），重新创建容器。
|
||||
|
||||
升级后在 4.0 中做的修改（新番剧、新订阅、新设置）全部丢失。
|
||||
|
||||
**没有完整备份时：**
|
||||
|
||||
1. 停止容器。
|
||||
2. 用 `config/config.json.v3.bak` 覆盖 `config/config.json`。3.3 不认识 `plugins.instances`，不还原时下载器设置会变成默认值。
|
||||
3. 编辑 `config/version.info`，删除所有以 `4.` 开头的行，使最后一行是 3.3.x 的版本号。
|
||||
4. 如果在 4.0 中使用过应用内更新，删除 `config/updates/` 目录。否则 3.3 镜像启动时会加载其中更新的 4.0 代码。
|
||||
5. 把镜像标签改回 3.3（例如 `3.3.6`），重新创建容器。
|
||||
|
||||
这种方式保留 4.0 中新增的番剧与种子记录。3.3 忽略 4.0 新增的数据库表与列。在 4.0 中修改的设置丢失。
|
||||
|
||||
以后再次升级到 4.0 时，迁移会重新运行，新的备份另存为 `config.json.v3.bak.1`。
|
||||
75
docs/en/changelog/4.0.md
Normal file
75
docs/en/changelog/4.0.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# [4.0] — Beta
|
||||
|
||||
4.0 is a large release that adds plugins. Download, notification, parsing, search, rename, and file organization all use one set of extension points. Built-in features and third-party plugins use the same interfaces. You can have more than one downloader instance. Built-in plugins supply rename, hard links, torrent filters, and media server refresh. You can upgrade only from 3.3.x. At the first start, AB migrates the configuration and keeps a backup of the original file.
|
||||
|
||||
For the upgrade procedure, the rollback procedure, and the checks after the upgrade, refer to [Upgrade from 3.3 to 4.0](../deploy/upgrade-4.0).
|
||||
|
||||
## 4.0.0-beta.1
|
||||
|
||||
Docker image: `ghcr.io/estrellaxd/auto_bangumi:4.0.0-beta.1`. `dev-latest` also points to the most recent beta.
|
||||
|
||||
### Breaking changes
|
||||
|
||||
- **Upgrade only from 3.3.x.** AB does not start if it finds data from an older version: a version below 3.3 in `config/version.info`, or a 2.x `data/data.json` file. The log tells you to upgrade to the latest 3.3.x and start it once.
|
||||
- **New configuration structure, with automatic migration.** Downloaders are now instances in `plugins.instances`. `plugins.slots.downloader` points to the default instance. The rename method and the revision conflict policy moved to `plugins.slots.rename_strategy` and `plugins.slots.conflict_policy`. At the first start, AB migrates the 3.3 fields `downloader`, `bangumi_manage.rename_method`, and `bangumi_manage.revision_conflict_policy`. AB keeps the original file as `config.json.v3.bak`. If that backup exists, AB writes `config.json.v3.bak.1` and so on, and does not overwrite it. If the migration fails, `config.json` does not change, AB does not start, and the log shows the field that caused the failure. The environment variables `AB_DOWNLOADER_*`, `AB_DOWNLOAD_PATH`, `AB_METHOD`, and `AB_REVISION_CONFLICT_POLICY` continue to work.
|
||||
- **Old notification fields.** Bark no longer reads `token` (use `device_key`). WeCom no longer reads `chat_id` (use `webhook_url`). The upgrade migrates them.
|
||||
- **Removed old API.** The 3.2-compatible GET control endpoints (`/api/v1/restart`, `/start`, `/stop`, `/shutdown`) and `GET /api/v1/auth/refresh_token` are removed. Use POST.
|
||||
- **Removed old configuration.** The `experimental_openai` section and the old single-channel notification fields are removed. 3.3 already moved them to `llm` and `notification.providers`. The deprecated `normal` rename method is removed. AB changes it to `none`, which has the same behavior.
|
||||
- AB upgrades the database to schema v26. It adds a plugin storage table and `downloader_id` columns.
|
||||
|
||||
### Plugin system
|
||||
|
||||
- New plugin runtime. Plugins can come from the built-in directory, the signed plugin catalog, a local directory (`config/plugins/local/`), or a pip package. Local and pip plugins do not have a signature. AB loads them only when you turn on **Settings → Plugins → Allow unsigned plugins** (`plugins.allow_unsigned`).
|
||||
- Plugins can supply downloaders, notification channels, LLM parser providers, search sites, metadata sources, and scheduled tasks. The built-in qBittorrent and aria2 downloaders and the notification channels use the same extension points. The lists of downloader types, notification channels, and subscription parsers show the options that plugins supply.
|
||||
- In the RSS download flow, plugins can filter torrents, correct parse results, change the save path, category, or tags, and add request headers (for example cookies for private sites).
|
||||
- The settings page has a new "Plugins" card. Use it to see the status, enable and disable plugins, and edit plugin options in a generated form. Read APIs always mask secret fields.
|
||||
- Signed plugin catalog: `GET /api/v1/plugins/catalog` lists the catalog. `POST /api/v1/plugins/{id}/install` verifies the sha256 and the ed25519 signature, then installs and enables the plugin. `DELETE /api/v1/plugins/{id}` uninstalls it.
|
||||
- Plugin hook calls have a timeout. If one plugin fails 5 times in sequence, AB disables it. After you correct the problem, enable it again on the settings page.
|
||||
|
||||
### More than one downloader
|
||||
|
||||
- In **Settings → Downloader Setting**, you can add more than one downloader instance (qBittorrent, aria2, or a downloader from a plugin) and set the default instance.
|
||||
- Rules and RSS subscriptions can select a downloader. If you do not select one, AB uses the default instance. A rule that AB makes from a subscription uses the selection of the subscription.
|
||||
- Each torrent records its downloader. AB renames and deletes the torrent on that downloader. If a rule changes to a different downloader, the existing torrents stay where they are.
|
||||
- AB renames files on one downloader at a time. AB skips a downloader that it cannot connect to, and sends a notification the first time that the connection fails.
|
||||
- The downloader page and the torrent list show the downloader of each torrent. `GET /api/v1/downloader/torrents` returns the torrents of all instances. The pause, resume, delete, and tag endpoints have a new `downloader_id` parameter. `GET /api/v1/downloader/instances` is new.
|
||||
|
||||
### Rename and file organization
|
||||
|
||||
- Rename is now a plugin. The built-in plugin `rename` (enabled by default) supplies `pn`, `advance`, and `template`. AB itself supplies `none`. The output of `pn` and `advance` is the same as in 3.3. Subtitles use the same method as the video files.
|
||||
- New `template` rename method: you write a template for the file name. For normal episodes the default template gives the same result as `pn`. For movies, `pn` adds no `SxxExx`, but the default template does. When you save the settings, AB renders the template as a test and does not save a template that is not valid. If the template fails for a file at run time, the file keeps its name and AB sends a "Files kept their names" notification. AB does not use `pn` as a fallback.
|
||||
- New built-in plugin `hardlink` (disabled by default). After AB organizes a torrent, the plugin links the video and subtitle files into the media library directory. The download directory continues to seed. Set a path map (`path_map`) for each downloader instance. Across file systems, the plugin copies the files by default. It does not overwrite files that it did not make, and replaces its own links after a revision upgrade. If a copy stops before it is complete, no partial file stays in the library. To link files that already exist, use `POST /api/v1/plugins/hardlink/backfill`.
|
||||
- New built-in plugin `media-server-refresh`. After you set the Jellyfin / Emby / Plex address and API key, it collects the torrents that AB organized during a short period and sends one library refresh request. If you do not configure it, it does nothing.
|
||||
- New built-in plugin `ingest-filters` (enabled by default). If you set its `include` option, AB downloads only torrents whose name matches one of the expressions. This applies to all subscriptions. If the option is empty, the plugin does not filter.
|
||||
|
||||
### Events, API, and MCP
|
||||
|
||||
- System events (RSS feed errors, failed torrent additions, downloader not available, new version, file renamed, torrent organized, and others) go to an event bus. Plugins can subscribe to them.
|
||||
- Plugins can supply REST routes (under `/api/v1/plugins/<plugin id>/`, login required), MCP tools, and MCP resources. Plugins can change the title and body of a system notification for each event type and channel.
|
||||
- Plugins can send notifications to the notification center.
|
||||
- The notification center now receives events immediately when a message is added, read, or deleted. Before, it checked every 3 seconds.
|
||||
|
||||
### Frontend plugins
|
||||
|
||||
- The WebUI has new plugin slots. A plugin can add its own interface (a Web Component) at a specified location. The built-in `hardlink` plugin uses a slot for its backfill button.
|
||||
- New example plugin `manual-pick`, which shows how to use a frontend slot.
|
||||
|
||||
### Plugin development tools
|
||||
|
||||
- The plugin SDK `ab_sdk` is available as the `autobangumi-sdk` wheel on each GitHub Release. It is not on PyPI.
|
||||
- New `ab-plugin` command line: `new` makes a plugin skeleton with contract tests. `validate` checks the manifest and the SDK version range. `pack` makes an installable zip. `dev` links the plugin directory into `config/plugins/local/` and turns on `plugins.dev_mode`. With `dev_mode` on, AB reloads a local plugin when its files change.
|
||||
- `ab_sdk.testing` has contract test suites for downloaders, rename methods, notification channels, and search sites.
|
||||
- 5 new example plugins in `examples/plugins/`: `webhook-on-event`, `custom-rss-site`, `template-rename`, `nfo-writer`, and `ntfy-notifier`. CI runs the tests of each one.
|
||||
- New agent skill for plugin authors, on each GitHub Release as `autobangumi-plugin-skill-<version>.zip`.
|
||||
- The plugin development documentation now has an overview, core concepts, and one page for each extension point, in Chinese, English, and Japanese. Refer to [Plugin Development](../dev/plugins).
|
||||
|
||||
### Fixes
|
||||
|
||||
- A new search site showed in the search site list only after a restart. It now shows immediately.
|
||||
- After an MCP client closed its SSE connection, the log showed `AssertionError: Unexpected message http.response.start`. This problem existed since 3.x.
|
||||
- When a plugin option validator failed, the save endpoint returned 500 instead of 422.
|
||||
- `version.info` compared only the minor version, so it did not record an upgrade to a new major version (for example 3.3 to 4.0).
|
||||
|
||||
### Cleanup
|
||||
|
||||
- Removed the 3.0 → 3.1 and 3.1 → 3.2 migrations, the old JWT and in-memory session code, and approximately 70 functions, methods, and models that nothing called. CI now checks for dead code.
|
||||
@@ -1,5 +1,9 @@
|
||||
# Deploy with Docker CLI
|
||||
|
||||
::: tip 4.0 beta
|
||||
The commands on this page use the `latest` tag, which installs the 3.3 stable release. To use the 4.0 beta, change the image tag to `4.0.0-beta.N` (for example `4.0.0-beta.1`). The volumes and the environment variables do not change. Before you upgrade from 3.3, read [Upgrade from 3.3 to 4.0](./upgrade-4.0). The 4.0 hard link plugin also needs the media library directory mounted into the container. Refer to [Bangumi Manager](../config/manager).
|
||||
:::
|
||||
|
||||
## Note on New Versions
|
||||
|
||||
Since AutoBangumi 2.6, you can configure everything directly in the WebUI. You can start the container first and then configure it in the WebUI. Environment variable configuration from older versions will be automatically migrated. Environment variables still work but only take effect on the first startup.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
|
||||
A one-click deployment method for **AutoBangumi** using a `docker-compose.yml` file.
|
||||
|
||||
::: tip 4.0 beta
|
||||
The commands on this page use the `latest` tag, which installs the 3.3 stable release. To use the 4.0 beta, change the image tag to `4.0.0-beta.N` (for example `4.0.0-beta.1`). The volumes and the environment variables do not change. Before you upgrade from 3.3, read [Upgrade from 3.3 to 4.0](./upgrade-4.0). The 4.0 hard link plugin also needs the media library directory mounted into the container. Refer to [Bangumi Manager](../config/manager).
|
||||
:::
|
||||
|
||||
## Install Docker Compose
|
||||
|
||||
Docker Compose usually comes bundled with Docker. Check with:
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
|
||||
DSM 7.2 supports Docker Compose, so we recommend using Docker Compose for one-click deployment.
|
||||
|
||||
::: tip 4.0 beta
|
||||
This page uses the `latest` tag, which installs the 3.3 stable release. To use the 4.0 beta, change the image tag to `4.0.0-beta.N` (for example `4.0.0-beta.1`). Before you upgrade from 3.3, read [Upgrade from 3.3 to 4.0](./upgrade-4.0).
|
||||
:::
|
||||
|
||||
## Create Configuration and Data Directories
|
||||
|
||||
Create an `AutoBangumi` folder under `/volume1/docker/`, then create `config` and `data` subfolders inside it.
|
||||
|
||||
@@ -3,6 +3,10 @@
|
||||
We recommend deploying AutoBangumi in Docker.
|
||||
Before deployment, make sure you have [Docker Engine][docker-engine] or [Docker Desktop][docker-desktop] installed.
|
||||
|
||||
::: tip 4.0 beta
|
||||
The commands on this page use the `latest` tag, which installs the 3.3 stable release. To use the 4.0 beta, change the image tag to `4.0.0-beta.N` (for example `4.0.0-beta.1`). The volumes and the environment variables do not change. Before you upgrade from 3.3, read [Upgrade from 3.3 to 4.0](./upgrade-4.0). The 4.0 hard link plugin also needs the media library directory mounted into the container. Refer to [Bangumi Manager](../config/manager).
|
||||
:::
|
||||
|
||||
## Create Data and Configuration Directories
|
||||
|
||||
To ensure AB's data and configuration persist across updates, we recommend using bind mounts or Docker volumes.
|
||||
|
||||
199
docs/en/deploy/upgrade-4.0.md
Normal file
199
docs/en/deploy/upgrade-4.0.md
Normal file
@@ -0,0 +1,199 @@
|
||||
# Upgrade from 3.3 to 4.0
|
||||
|
||||
4.0 is a large release that adds plugins. You can now have more than one downloader instance. Built-in plugins now supply rename, hard links, torrent filters, and media server refresh. At the first start, AB moves the 3.3 configuration to the new locations. This page tells what the migration changes, how to upgrade, what to check after the upgrade, and how to roll back to 3.3.
|
||||
|
||||
::: warning 4.0 is a beta
|
||||
4.0 is only available as `4.0.0-beta.N` beta releases. Until the 4.0 stable release, the `latest` image tag continues to point to 3.3. Make the backups below before you upgrade a production system.
|
||||
:::
|
||||
|
||||
## Before you upgrade
|
||||
|
||||
1. **Make sure that you use 3.3.x.** You can upgrade to 4.0 only from 3.3.x. AB does not start if it finds data from an older version: a version below 3.3 in `config/version.info`, or a 2.x `data/data.json` file. The log tells you to upgrade to the latest 3.3.x and start it once. At that time, AB can already have changed `config.json` to the 4.0 format. Copy `config.json.v3.bak` back to `config.json` before you go back to 3.3.x.
|
||||
2. **Stop the container. Back up the `config` and `data` directories.** You need these backups to roll back to 3.3 (see [Roll back to 3.3](#roll-back-to-3-3)).
|
||||
|
||||
```shell
|
||||
docker stop AutoBangumi
|
||||
cp -a ${HOME}/AutoBangumi/config ${HOME}/AutoBangumi/config.bak-3.3
|
||||
cp -a ${HOME}/AutoBangumi/data ${HOME}/AutoBangumi/data.bak-3.3
|
||||
```
|
||||
|
||||
## Change the image tag
|
||||
|
||||
Image tags for the 4.0 beta:
|
||||
|
||||
| Tag | Meaning |
|
||||
| --- | --- |
|
||||
| `4.0.0-beta.N` | One specified beta, for example `4.0.0-beta.1`. **Recommended**: you control when you upgrade and roll back |
|
||||
| `dev-latest` | The most recent beta. Each `X.Y.Z-beta.N` release moves this tag, not only 4.0 releases |
|
||||
| `latest` | The most recent stable release. This is 3.3 until the 4.0 stable release |
|
||||
|
||||
The images are on `ghcr.io/estrellaxd/auto_bangumi` and on Docker Hub as `estrellaxd/auto_bangumi`.
|
||||
|
||||
Docker Compose: change `image`, then create the container again.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
AutoBangumi:
|
||||
image: "ghcr.io/estrellaxd/auto_bangumi:4.0.0-beta.1"
|
||||
```
|
||||
|
||||
```shell
|
||||
docker compose pull
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Docker CLI: remove the old container. Then run `docker run` again with the new tag and the same options.
|
||||
|
||||
The volumes (`/app/config`, `/app/data`), the port, and the environment variables do not change. 4.0 adds no environment variables. AB installs plugins in `config/plugins/`, which is in the `/app/config` volume.
|
||||
|
||||
### In-app update (3.3 beta channel)
|
||||
|
||||
If you selected the beta update channel in 3.3, **Settings → Software Update** shows `4.0.0-beta.N`. 4.0 update bundles need image version `4.0.0-beta.1` or later. On a 3.3 image, **Update now** fails with a message that the image is too old and that you must pull a newer image. Change the image tag as the previous section tells you. Users on the stable channel do not see 4.0 betas.
|
||||
|
||||
## First start: configuration migration
|
||||
|
||||
Before AB reads `config.json`, it checks if the file has the 3.3 format. If it does, AB first copies the file to `config.json.v3.bak`. Then AB moves these fields to their 4.0 locations:
|
||||
|
||||
| 3.3 field | 4.0 location |
|
||||
| --- | --- |
|
||||
| `downloader` | The downloader instance with id `default` in `plugins.instances`. `type` becomes `provider`. The other fields (host, username, password, download path, SSL) go into `options` |
|
||||
| — | `plugins.slots.downloader` is set to `"default"` (the default downloader instance) |
|
||||
| `bangumi_manage.rename_method` | `plugins.slots.rename_strategy`. The deprecated value `normal` becomes `none`, which has the same behavior |
|
||||
| `bangumi_manage.revision_conflict_policy` | `plugins.slots.conflict_policy` |
|
||||
| `token` of a Bark channel | `device_key` |
|
||||
| `chat_id` of a WeCom channel | `webhook_url` |
|
||||
|
||||
Example of the downloader configuration before and after the migration:
|
||||
|
||||
::: code-group
|
||||
|
||||
```json [3.3]
|
||||
{
|
||||
"downloader": {
|
||||
"type": "qbittorrent",
|
||||
"host": "172.17.0.1:8080",
|
||||
"username": "admin",
|
||||
"password": "adminadmin",
|
||||
"path": "/downloads/Bangumi",
|
||||
"ssl": false
|
||||
},
|
||||
"bangumi_manage": {
|
||||
"rename_method": "pn",
|
||||
"revision_conflict_policy": "hold"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```json [4.0]
|
||||
{
|
||||
"plugins": {
|
||||
"slots": {
|
||||
"downloader": "default",
|
||||
"rename_strategy": "pn",
|
||||
"conflict_policy": "hold"
|
||||
},
|
||||
"instances": [
|
||||
{
|
||||
"id": "default",
|
||||
"point": "downloader",
|
||||
"provider": "qbittorrent",
|
||||
"options": {
|
||||
"host": "172.17.0.1:8080",
|
||||
"username": "admin",
|
||||
"password": "adminadmin",
|
||||
"path": "/downloads/Bangumi",
|
||||
"ssl": false
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
The example shows only the related fields. The other settings do not change.
|
||||
|
||||
- **AB does not overwrite a backup.** If `config.json.v3.bak` already exists (for example, you rolled back to 3.3 and upgrade again), AB writes the new backup to `config.json.v3.bak.1`, `config.json.v3.bak.2`, and so on. The first backup contains the oldest 3.3 configuration.
|
||||
- **If the migration is successful**, the log shows `Migrated config.json to 4.0 (...); the 3.3 file is kept as config.json.v3.bak`. The parentheses list the fields that moved.
|
||||
- **If the migration fails**, `config.json` keeps its 3.3 content and AB does not start. The log shows the field that caused the failure. Correct that field and start AB again.
|
||||
- AB does not migrate a configuration that already has the 4.0 format, and does not make a backup for it.
|
||||
- Environment variables (`AB_DOWNLOADER_HOST`, `AB_METHOD`, and others) continue to work. AB reads them only at the first start, when no `config.json` exists. AB writes their values to the default downloader instance and to `plugins.slots`.
|
||||
|
||||
During the same start, AB upgrades the database to schema v26. It adds the plugin storage table `plugin_kv` and a `downloader_id` column to bangumi, movies, RSS subscriptions, and torrents. Existing torrents belong to the `default` instance. Existing rules and subscriptions have an empty `downloader_id`, which means that they use the default instance.
|
||||
|
||||
## Behavior that changes in 4.0
|
||||
|
||||
### More than one downloader
|
||||
|
||||
In **Settings → Downloader Setting**, you can add more than one downloader instance (qBittorrent, aria2, or a downloader from a plugin) and set the default instance. Rules and RSS subscriptions can select a downloader. If you do not select one, AB uses the default instance. Each torrent records its downloader, and AB renames and deletes the torrent on that downloader. Refer to [Downloader Settings](../config/downloader).
|
||||
|
||||
### Rename is a plugin
|
||||
|
||||
The built-in plugin `rename` supplies `pn`, `advance`, and the new `template` method. It is enabled by default. AB itself supplies `none`. The output of `pn` and `advance` is the same as in 3.3.
|
||||
|
||||
- `template` makes file names from a template that you write. When you save the settings, AB renders the template as a test. AB does not save a template that is not valid.
|
||||
- If the template fails for a file at run time, the file keeps its name and AB sends a "Files kept their names" notification. AB does not use `pn` as a fallback.
|
||||
- If you disable the `rename` plugin in **Settings → Plugins**, AB uses `none` for all bangumi and keeps the original file names.
|
||||
|
||||
Refer to [Bangumi Manager](../config/manager).
|
||||
|
||||
### Hard links to a media library
|
||||
|
||||
The new built-in plugin `hardlink` is **disabled by default**. When you enable it, AB links the video and subtitle files of each organized torrent into the media library directory. The download directory does not change and continues to seed.
|
||||
|
||||
- If the downloader and AB see different paths (for example, they run in different containers), set a path map in `path_map` for each downloader instance.
|
||||
- If a hard link is not possible (different file systems), AB copies the file by default (`cross_device: copy`).
|
||||
- In Docker, you must also mount the media library directory into the AB container. For hard links, keep the download directory and the media library on the same disk, and mount them into the container through one mount point.
|
||||
|
||||
Refer to [Bangumi Manager](../config/manager).
|
||||
|
||||
### Other built-in plugins
|
||||
|
||||
- The torrent filter plugin `ingest-filters` is enabled by default. If its `include` option is empty, it does not filter torrents.
|
||||
- The plugin `media-server-refresh` is enabled by default. It sends refresh requests only after you set the Jellyfin / Emby / Plex address and API key.
|
||||
|
||||
### Third-party plugins
|
||||
|
||||
Plugins from the local directory (`config/plugins/local/`) or from pip do not have a signature. AB loads them only when you turn on "Allow unsigned plugins" (`plugins.allow_unsigned`) in **Settings → Plugins**. To write a plugin, refer to [Plugin Development](../dev/plugins).
|
||||
|
||||
### Removed items
|
||||
|
||||
- The 3.2-compatible GET control endpoints (`/api/v1/restart`, `/start`, `/stop`, `/shutdown`) and `GET /api/v1/auth/refresh_token`. Use POST. Change the scripts that call these endpoints.
|
||||
- The old `experimental_openai` configuration section and the old single-channel notification fields. 3.3 already moved them to `llm` and `notification.providers`.
|
||||
|
||||
## Checks after the upgrade
|
||||
|
||||
- [ ] The log has the line `Migrated config.json to 4.0`. The `config` directory has `config.json.v3.bak`.
|
||||
- [ ] **Settings → Downloader Setting** has an instance with id `default`. Its host, username, and download path are the same as in 3.3, and AB can connect to it.
|
||||
- [ ] The rename method is the same as in 3.3. The 3.3 value `normal` now shows as `none`. The behavior is the same: AB does not rename files.
|
||||
- [ ] The `rename` plugin is enabled in **Settings → Plugins**.
|
||||
- [ ] If you use Bark or WeCom notifications, send a test notification.
|
||||
- [ ] If you want hard links or media server refresh, enable and configure them in **Settings → Plugins**.
|
||||
- [ ] Scripts that use the 3.2 GET control endpoints now use POST.
|
||||
|
||||
## Roll back to 3.3
|
||||
|
||||
::: danger Correct `version.info` first
|
||||
4.0 adds the line `4.0.0-beta.N` at the end of `config/version.info`. 3.3 compares only the minor version. If the last line is 4.0, 3.3 thinks that the data is from 3.0. It then creates all database tables again and keeps only the bangumi rules and the first user. All other data, for example torrent records, is lost. Before you roll back, restore the `data` backup or remove the 4.x lines from `version.info`.
|
||||
:::
|
||||
|
||||
**If you have a full backup from before the upgrade** (recommended):
|
||||
|
||||
1. Stop the container.
|
||||
2. Replace the `config` and `data` directories with `config.bak-3.3` and `data.bak-3.3`.
|
||||
3. Change the image tag back to 3.3 (for example `3.3.6`). Create the container again.
|
||||
|
||||
All changes that you made in 4.0 (new bangumi, new subscriptions, new settings) are lost.
|
||||
|
||||
**If you do not have a full backup:**
|
||||
|
||||
1. Stop the container.
|
||||
2. Copy `config/config.json.v3.bak` to `config/config.json`. 3.3 does not know `plugins.instances`. If you do not restore the file, the downloader settings go back to their default values.
|
||||
3. Edit `config/version.info`. Remove all lines that start with `4.`. The last line must be a 3.3.x version.
|
||||
4. If you used the in-app update in 4.0, remove the `config/updates/` directory. If you do not, the 3.3 image loads the newer 4.0 code from that directory at startup.
|
||||
5. Change the image tag back to 3.3 (for example `3.3.6`). Create the container again.
|
||||
|
||||
With this procedure, you keep the bangumi and torrent records that you added in 4.0. 3.3 ignores the database tables and columns that 4.0 added. The settings that you changed in 4.0 are lost.
|
||||
|
||||
When you upgrade to 4.0 again, the migration runs again and writes the new backup to `config.json.v3.bak.1`.
|
||||
@@ -65,6 +65,10 @@ The organized file names and directory structure are directly compatible with [P
|
||||
- Zero maintenance, completely transparent operation
|
||||
- Built-in TMDB parser for generating complete TMDB-formatted files and anime metadata
|
||||
- Reverse proxy support for Mikan RSS feeds
|
||||
- Plugins (4.0): plugins can supply downloaders, notification channels, metadata sources, search sites, and rename methods. The SDK, the `ab-plugin` command line, and example plugins are available. Refer to [Plugin Development](../dev/plugins)
|
||||
- More than one downloader (4.0): connect more than one qBittorrent or aria2 instance, and select a downloader for each rule or subscription
|
||||
- Template rename (4.0): make file names from a template that you write
|
||||
- Hard links and media server refresh (4.0): the download directory continues to seed while AB links the organized files into the media library. After AB organizes a torrent, it can tell Jellyfin / Emby / Plex to refresh
|
||||
|
||||
## Community
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ hero:
|
||||
link: /en/home/
|
||||
- theme: alt
|
||||
text: Changelog
|
||||
link: /en/changelog/3.3
|
||||
link: /en/changelog/4.0
|
||||
|
||||
features:
|
||||
- icon:
|
||||
@@ -28,7 +28,7 @@ features:
|
||||
- icon:
|
||||
src: /image/icons/qbittorrent-logo.svg
|
||||
title: qBittorrent / aria2 Downloaders
|
||||
details: Download anime with qBittorrent or aria2, manage existing series, fetch missed episodes, and remove entries from AutoBangumi.
|
||||
details: Download anime with qBittorrent or aria2, manage existing series, fetch missed episodes, and remove entries from AutoBangumi. From 4.0, connect more than one downloader and select one for each rule or subscription.
|
||||
- icon:
|
||||
src: /image/icons/tmdb-icon.png
|
||||
title: TMDB Metadata Matching
|
||||
@@ -36,7 +36,14 @@ features:
|
||||
- icon:
|
||||
src: /image/icons/plex-icon.png
|
||||
title: Plex / Jellyfin / Infuse ...
|
||||
details: Organize filenames and folders for media libraries, improving metadata scraping success in Plex, Jellyfin, Infuse, and similar apps.
|
||||
details: Organize filenames and folders for media libraries, improving metadata scraping success in Plex, Jellyfin, Infuse, and similar apps. Optionally hard link files into a media library and tell Jellyfin / Emby / Plex to refresh.
|
||||
- icon:
|
||||
light: /image/icons/light-icon.svg
|
||||
dark: /image/icons/dark-icon.svg
|
||||
title: Plugins
|
||||
details: From 4.0, plugins can supply downloaders, notification channels, metadata sources, search sites, and rename methods. Write your own plugin with the SDK and the ab-plugin command line.
|
||||
link: /en/dev/plugins
|
||||
linkText: Plugin Development
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -65,6 +65,10 @@ title: 关于
|
||||
- 零维护，完全透明运行
|
||||
- 内置 TMDB 解析器，可生成完整的 TMDB 格式文件和番剧元数据
|
||||
- 支持 Mikan RSS 订阅的反向代理
|
||||
- 插件系统（4.0）：下载器、通知渠道、元数据源、搜索站点与重命名方式都可以由插件提供；提供 SDK、`ab-plugin` 命令行与示例插件，见 [插件开发](../dev/plugins)
|
||||
- 多个下载器（4.0）：可以同时连接多个 qBittorrent / aria2 实例，规则与订阅可以分别指定下载器
|
||||
- 模板重命名（4.0）：用自定义模板生成文件名
|
||||
- 硬链接到媒体库与媒体库刷新（4.0）：下载目录继续做种，整理好的文件链接到媒体库；整理完成后通知 Jellyfin / Emby / Plex 刷新
|
||||
|
||||
## 社区
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ hero:
|
||||
link: /home/
|
||||
- theme: alt
|
||||
text: 更新日志
|
||||
link: /changelog/3.3
|
||||
link: /changelog/4.0
|
||||
|
||||
features:
|
||||
- icon:
|
||||
@@ -28,7 +28,7 @@ features:
|
||||
- icon:
|
||||
src: /image/icons/qbittorrent-logo.svg
|
||||
title: qBittorrent / aria2 下载器
|
||||
details: 使用 qBittorrent 或 aria2 下载番剧资源。在 AutoBangumi 中即可管理现有番剧、下载往期番剧以及删除条目。
|
||||
details: 使用 qBittorrent 或 aria2 下载番剧资源。在 AutoBangumi 中即可管理现有番剧、下载往期番剧以及删除条目。4.0 起可以同时连接多个下载器，规则与订阅可以分别指定。
|
||||
- icon:
|
||||
src: /image/icons/tmdb-icon.png
|
||||
title: TMDB 元数据匹配
|
||||
@@ -36,7 +36,14 @@ features:
|
||||
- icon:
|
||||
src: /image/icons/plex-icon.png
|
||||
title: Plex / Jellyfin / Infuse ...
|
||||
details: 根据匹配结果自动整理文件名和目录结构，确保媒体库软件能够高成功率地刮削元数据。
|
||||
details: 根据匹配结果自动整理文件名和目录结构，确保媒体库软件能够高成功率地刮削元数据。可选把文件硬链接到媒体库，并在整理完成后通知 Jellyfin / Emby / Plex 刷新。
|
||||
- icon:
|
||||
light: /image/icons/light-icon.svg
|
||||
dark: /image/icons/dark-icon.svg
|
||||
title: 插件扩展
|
||||
details: 4.0 起，下载器、通知渠道、元数据源、搜索站点与重命名方式都可以由插件提供。用 SDK 与 ab-plugin 命令行编写自己的插件。
|
||||
link: /dev/plugins
|
||||
linkText: 插件开发
|
||||
---
|
||||
|
||||
|
||||
|
||||
75
docs/ja/changelog/4.0.md
Normal file
75
docs/ja/changelog/4.0.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# [4.0] — Beta
|
||||
|
||||
4.0 はプラグイン化のための大型リリースです。ダウンロード、通知、解析、検索、リネーム、ファイル整理はすべて同じ拡張ポイントで実装され、内蔵機能とサードパーティープラグインは同じインターフェースを使います。ダウンローダーは複数のインスタンスを持てるようになり、リネーム、ハードリンク、トレントフィルター、メディアサーバーの更新は内蔵プラグインが提供します。アップグレードは 3.3.x からのみ対応し、初回起動時に設定を自動移行して元のファイルをバックアップします。
|
||||
|
||||
アップグレード手順、ロールバック方法、アップグレード後の確認項目は [3.3 から 4.0 へのアップグレード](../deploy/upgrade-4.0) を参照してください。
|
||||
|
||||
## 4.0.0-beta.1
|
||||
|
||||
Docker イメージ：`ghcr.io/estrellaxd/auto_bangumi:4.0.0-beta.1`（`dev-latest` も最新のベータ版を指します）。
|
||||
|
||||
### 互換性のない変更
|
||||
|
||||
- **3.3.x からのみアップグレード可能。** 古いバージョンのデータ（`config/version.info` が 3.3 未満、または 2.x の `data/data.json` が残っている）を検出すると起動を拒否し、最新の 3.3.x に一度アップグレードして起動するよう案内します。
|
||||
- **設定構造の変更と自動移行。** ダウンローダーは `plugins.instances` のインスタンスになり、`plugins.slots.downloader` が既定インスタンスを指します。リネーム方式とリビジョン競合ポリシーは `plugins.slots.rename_strategy` / `plugins.slots.conflict_policy` に移りました。初回起動時に 3.3 の `downloader`、`bangumi_manage.rename_method`、`bangumi_manage.revision_conflict_policy` を自動移行し、元のファイルを `config.json.v3.bak` にバックアップします（既存のバックアップは上書きせず、`config.json.v3.bak.1` などに保存）。移行に失敗すると `config.json` はそのまま残り、起動を拒否し、ログに原因のフィールドを表示します。`AB_DOWNLOADER_*`、`AB_DOWNLOAD_PATH`、`AB_METHOD`、`AB_REVISION_CONFLICT_POLICY` 環境変数は引き続き有効です。
|
||||
- **通知チャンネルの旧フィールド。** Bark は `token` を読まなくなりました（`device_key` を使用）。WeCom は `chat_id` を読まなくなりました（`webhook_url` を使用）。アップグレード時に自動移行します。
|
||||
- **旧 API の削除。** 3.2 互換の GET 制御エンドポイント（`/api/v1/restart`、`/start`、`/stop`、`/shutdown`）と `GET /api/v1/auth/refresh_token` を削除しました。POST を使ってください。
|
||||
- **旧設定の削除。** `experimental_openai` 設定セクションと通知の単一チャンネル用旧フィールドを削除しました（3.3 で `llm` と `notification.providers` に移行済み）。非推奨の `normal` リネーム方式を削除し、既存の設定は同じ動作の `none` に自動変更します。
|
||||
- データベースは schema v26 に自動更新されます（プラグイン用ストレージテーブルと `downloader_id` 列を追加）。
|
||||
|
||||
### プラグインシステム
|
||||
|
||||
- 新しいプラグインランタイム。プラグインは内蔵フォルダー、署名済みプラグインカタログ、ローカルフォルダー（`config/plugins/local/`）、pip パッケージから読み込めます。ローカルと pip のプラグインは署名されていないため、**設定 → プラグイン → 未署名プラグインを許可**（`plugins.allow_unsigned`）をオンにしたときだけ読み込まれます。
|
||||
- プラグインはダウンローダー、通知チャンネル、LLM パーサープロバイダー、検索サイト、メタデータソース、定期タスクを提供できます。内蔵の qBittorrent / aria2 と各通知チャンネルも同じ拡張ポイントを使います。ダウンローダーの種類、通知チャンネル、購読パーサーのドロップダウンにはプラグインの選択肢も表示されます。
|
||||
- RSS ダウンロードの流れの中で、プラグインはトレントのフィルター、解析結果の修正、保存パス / カテゴリー / タグの変更、プライベートサイト向けの Cookie などのリクエストヘッダーの追加ができます。
|
||||
- 設定ページに「プラグイン」カードを追加しました。状態の確認、有効化 / 無効化、自動生成されるフォームでのプラグイン設定の編集ができます。秘密フィールドは読み取り API で常にマスクされます。
|
||||
- 署名済みプラグインカタログ：`GET /api/v1/plugins/catalog` でカタログを一覧し、`POST /api/v1/plugins/{id}/install` で sha256 と ed25519 署名を検証してからインストールして有効にし、`DELETE /api/v1/plugins/{id}` でアンインストールします。
|
||||
- プラグインのフック呼び出しにはタイムアウトがあります。同じプラグインが 5 回連続で失敗すると自動的に無効になります。問題を直してから設定ページで再度有効にしてください。
|
||||
|
||||
### 複数のダウンローダー
|
||||
|
||||
- **設定 → ダウンローダー設定** で複数のダウンローダーインスタンス（qBittorrent、aria2、またはプラグインのダウンローダー）を追加し、既定インスタンスを指定できます。
|
||||
- ルールと RSS 購読はダウンローダーを選択できます。空欄なら既定インスタンスを使います。購読から作成されたルールは購読の選択を引き継ぎます。
|
||||
- 各トレントは所属するダウンローダーを記録し、リネームと削除はそのダウンローダー上で行います。ルールが別のダウンローダーに変わっても、既存のトレントは元の場所に残ります。
|
||||
- リネームはダウンローダーごとに実行します。接続できないダウンローダーはスキップし、最初に接続できなかったときに通知します。
|
||||
- ダウンローダーページとトレント一覧に、トレントが属するダウンローダーを表示します。`GET /api/v1/downloader/torrents` はすべてのインスタンスのトレントを返し、一時停止 / 再開 / 削除 / タグ付けのエンドポイントに `downloader_id` を追加しました。`GET /api/v1/downloader/instances` を追加しました。
|
||||
|
||||
### リネームとファイル整理
|
||||
|
||||
- リネームはプラグインになりました。`pn` / `advance` / `template` は既定で有効な内蔵プラグイン `rename` が提供し、`none` は AB 本体が提供します。`pn` / `advance` の出力は 3.3 と完全に同じです。字幕は動画と同じ方式を使います。
|
||||
- 新しいリネーム方式 `template`：テンプレートでファイル名を自由に決められます。通常のエピソードでは既定のテンプレートは `pn` と同じ結果になります（劇場版では `pn` は `SxxExx` を付けませんが、既定のテンプレートは付けます）。保存時に試しにレンダリングし、不正なテンプレートは保存できません。実行時にレンダリングに失敗したファイルは元の名前のまま残り、通知が送られます。`pn` へのフォールバックはしません。
|
||||
- 新しい内蔵プラグイン `hardlink`（既定で無効）：トレントの整理が終わると、動画と字幕をメディアライブラリのフォルダーにリンクします。ダウンロードフォルダーはシードを続けます。ダウンローダーインスタンスごとにパスの対応（`path_map`）を設定します。ファイルシステムをまたぐ場合は既定でコピーします。自分が作っていないファイルは上書きせず、リビジョン更新後は自分が作ったリンクを置き換えます。コピーが中断しても、ライブラリに途中までのファイルは残りません。既存のファイルは `POST /api/v1/plugins/hardlink/backfill` でリンクできます。
|
||||
- 新しい内蔵プラグイン `media-server-refresh`：Jellyfin / Emby / Plex のアドレスと API キーを設定すると、一定時間内に整理が終わったトレントをまとめて、ライブラリの更新を要求します。設定しなければ何もしません。
|
||||
- 新しい内蔵プラグイン `ingest-filters`（既定で有効）：`include` オプションを設定すると、名前がいずれかの式に一致するトレントだけをダウンロードします（すべての購読に適用）。空欄なら何もフィルターしません。
|
||||
|
||||
### イベント、API、MCP
|
||||
|
||||
- システムイベント（RSS 購読のエラー、トレント追加の失敗、ダウンローダーの接続不可、新バージョン、ファイルのリネーム、トレントの整理完了など）はイベントバスに送られ、プラグインから購読できます。
|
||||
- プラグインは REST ルート（`/api/v1/plugins/<プラグイン id>/` 配下、ログイン必須）、MCP ツール、MCP リソースを提供できます。また、イベントの種類とチャンネルごとにシステム通知のタイトルと本文を書き換えられます。
|
||||
- プラグインは通知センターに通知を送れます。
|
||||
- 通知センターはイベントで更新されるようになり、新着、既読、削除がすぐに反映されます（以前は 3 秒ごとに確認）。
|
||||
|
||||
### フロントエンドプラグイン
|
||||
|
||||
- WebUI にプラグインのマウントポイントを追加しました。プラグインは指定の場所に独自の UI（Web Component）を追加できます。内蔵の `hardlink` プラグインはこれを使ってリンク補完のボタンを提供します。
|
||||
- フロントエンドのマウントポイントの使い方を示すサンプルプラグイン `manual-pick` を追加しました。
|
||||
|
||||
### プラグイン開発ツール
|
||||
|
||||
- プラグイン SDK `ab_sdk` を `autobangumi-sdk` wheel として各 GitHub Release に添付します（PyPI には公開しません）。
|
||||
- 新しい `ab-plugin` コマンドライン：`new` はプラグインの雛形と契約テストを生成し、`validate` はマニフェストと SDK バージョン範囲を検証し、`pack` はインストール可能な zip を作り、`dev` はプラグインフォルダーを `config/plugins/local/` にリンクして `plugins.dev_mode` をオンにします。`dev_mode` がオンのとき、ローカルプラグインのファイルを変更すると自動的に再読み込みされます。
|
||||
- `ab_sdk.testing` にダウンローダー、リネーム方式、通知チャンネル、検索サイトの契約テストスイートを追加しました。
|
||||
- `examples/plugins/` に 5 つのサンプルプラグインを追加しました：`webhook-on-event`、`custom-rss-site`、`template-rename`、`nfo-writer`、`ntfy-notifier`。CI がそれぞれのテストを実行します。
|
||||
- プラグイン作者向けの agent skill を各 GitHub Release に `autobangumi-plugin-skill-<バージョン>.zip` として添付します。
|
||||
- プラグイン開発ドキュメントを概要、基本概念、拡張ポイントごとのページに分けました（中国語 / 英語 / 日本語）。[プラグイン開発](../dev/plugins) を参照してください。
|
||||
|
||||
### 修正
|
||||
|
||||
- 新しく保存した検索サイトが、再起動するまで検索サイト一覧に表示されませんでした。今はすぐに表示されます。
|
||||
- MCP クライアントが SSE 接続を閉じると、ログに `AssertionError: Unexpected message http.response.start` が出ていました（3.x から存在）。
|
||||
- プラグイン設定のバリデーターがエラーを出したとき、保存 API が 422 ではなく 500 を返していました。
|
||||
- `version.info` がマイナーバージョンだけを比較していたため、メジャーバージョンをまたぐアップグレード（3.3 → 4.0 など）が記録されませんでした。
|
||||
|
||||
### クリーンアップ
|
||||
|
||||
- 3.0 → 3.1、3.1 → 3.2 のバージョン間移行、旧 JWT とメモリー内セッションの実装、呼び出し元のない約 70 の関数・メソッド・モデルを削除しました。CI にデッドコードのチェックを追加しました。
|
||||
@@ -1,5 +1,9 @@
|
||||
# Docker CLIでデプロイ
|
||||
|
||||
::: tip 4.0 ベータ版
|
||||
このページのコマンドは `latest` タグを使い、3.3 の正式版をインストールします。4.0 ベータ版を使うには、イメージタグを `4.0.0-beta.N`（例：`4.0.0-beta.1`）に変更してください。ボリュームと環境変数は変わりません。3.3 からアップグレードする前に [3.3 から 4.0 へのアップグレード](./upgrade-4.0) を読んでください。4.0 のハードリンクプラグインを使う場合は、メディアライブラリのフォルダーもコンテナにマウントする必要があります。[アニメ管理設定](../config/manager) を参照してください。
|
||||
:::
|
||||
|
||||
## 新バージョンに関する注意
|
||||
|
||||
AutoBangumi 2.6以降、WebUIで直接すべてを設定できます。まずコンテナを起動してから、WebUIで設定できます。以前のバージョンの環境変数設定は自動的に移行されます。環境変数は引き続き機能しますが、初回起動時にのみ有効です。
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
|
||||
`docker-compose.yml`ファイルを使用した**AutoBangumi**のワンクリックデプロイ方法です。
|
||||
|
||||
::: tip 4.0 ベータ版
|
||||
このページのコマンドは `latest` タグを使い、3.3 の正式版をインストールします。4.0 ベータ版を使うには、イメージタグを `4.0.0-beta.N`（例：`4.0.0-beta.1`）に変更してください。ボリュームと環境変数は変わりません。3.3 からアップグレードする前に [3.3 から 4.0 へのアップグレード](./upgrade-4.0) を読んでください。4.0 のハードリンクプラグインを使う場合は、メディアライブラリのフォルダーもコンテナにマウントする必要があります。[アニメ管理設定](../config/manager) を参照してください。
|
||||
:::
|
||||
|
||||
## Docker Composeのインストール
|
||||
|
||||
Docker Composeは通常Dockerにバンドルされています。以下で確認してください：
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
|
||||
DSM 7.2はDocker Composeをサポートしているため、ワンクリックデプロイにDocker Composeの使用を推奨します。
|
||||
|
||||
::: tip 4.0 ベータ版
|
||||
このページは `latest` タグを使い、3.3 の正式版をインストールします。4.0 ベータ版を使うには、イメージタグを `4.0.0-beta.N`（例：`4.0.0-beta.1`）に変更してください。3.3 からアップグレードする前に [3.3 から 4.0 へのアップグレード](./upgrade-4.0) を読んでください。
|
||||
:::
|
||||
|
||||
## 設定とデータディレクトリの作成
|
||||
|
||||
`/volume1/docker/`の下に`AutoBangumi`フォルダを作成し、その中に`config`と`data`サブフォルダを作成します。
|
||||
|
||||
@@ -3,6 +3,10 @@
|
||||
AutoBangumiはDockerでのデプロイを推奨しています。
|
||||
デプロイ前に、[Docker Engine][docker-engine]または[Docker Desktop][docker-desktop]がインストールされていることを確認してください。
|
||||
|
||||
::: tip 4.0 ベータ版
|
||||
このページのコマンドは `latest` タグを使い、3.3 の正式版をインストールします。4.0 ベータ版を使うには、イメージタグを `4.0.0-beta.N`（例：`4.0.0-beta.1`）に変更してください。ボリュームと環境変数は変わりません。3.3 からアップグレードする前に [3.3 から 4.0 へのアップグレード](./upgrade-4.0) を読んでください。4.0 のハードリンクプラグインを使う場合は、メディアライブラリのフォルダーもコンテナにマウントする必要があります。[アニメ管理設定](../config/manager) を参照してください。
|
||||
:::
|
||||
|
||||
## データと設定ディレクトリの作成
|
||||
|
||||
ABのデータと設定を更新時に永続化するために、バインドマウントまたはDockerボリュームの使用を推奨します。
|
||||
|
||||
199
docs/ja/deploy/upgrade-4.0.md
Normal file
199
docs/ja/deploy/upgrade-4.0.md
Normal file
@@ -0,0 +1,199 @@
|
||||
# 3.3 から 4.0 へのアップグレード
|
||||
|
||||
4.0 はプラグイン化のための大型リリースです。ダウンローダーは複数のインスタンスを持てるようになり、リネーム、ハードリンク、トレントフィルター、メディアサーバーの更新は内蔵プラグインが提供します。初回起動時に、AB は 3.3 の設定を新しい場所へ自動的に移行します。このページでは、移行で何が変わるか、アップグレード手順、アップグレード後の確認項目、3.3 へのロールバック方法を説明します。
|
||||
|
||||
::: warning 4.0 はベータ版です
|
||||
4.0 は `4.0.0-beta.N` のベータ版としてのみ公開されています。4.0 正式版の公開までは、`latest` イメージタグは 3.3 を指します。本番環境では、先に下記のバックアップを取ってください。
|
||||
:::
|
||||
|
||||
## アップグレードの前に
|
||||
|
||||
1. **現在のバージョンが 3.3.x であることを確認します。** 4.0 へは 3.3.x からのみアップグレードできます。古いバージョンのデータ（`config/version.info` の記録が 3.3 未満、または 2.x の `data/data.json` が残っている）を検出すると、AB は起動を拒否し、最新の 3.3.x に一度アップグレードして起動するよう案内します。このとき `config.json` はすでに 4.0 形式に書き換えられている場合があります。3.3.x に戻す前に、`config.json.v3.bak` で `config.json` を上書きしてください。
|
||||
2. **コンテナを停止し、`config` と `data` の 2 つのフォルダーをバックアップします。** 3.3 へロールバックするときに必要です（[3.3 へのロールバック](#_3-3-へのロールバック) を参照）。
|
||||
|
||||
```shell
|
||||
docker stop AutoBangumi
|
||||
cp -a ${HOME}/AutoBangumi/config ${HOME}/AutoBangumi/config.bak-3.3
|
||||
cp -a ${HOME}/AutoBangumi/data ${HOME}/AutoBangumi/data.bak-3.3
|
||||
```
|
||||
|
||||
## イメージタグの変更
|
||||
|
||||
4.0 ベータ版のイメージタグ：
|
||||
|
||||
| タグ | 意味 |
|
||||
| --- | --- |
|
||||
| `4.0.0-beta.N` | 指定したベータ版。例：`4.0.0-beta.1`。アップグレードとロールバックを管理しやすいため**推奨** |
|
||||
| `dev-latest` | 最新のベータ版。4.0 に限らず、すべての `X.Y.Z-beta.N` リリースで更新されます |
|
||||
| `latest` | 最新の正式版。4.0 正式版の公開までは 3.3 です |
|
||||
|
||||
イメージは `ghcr.io/estrellaxd/auto_bangumi` と Docker Hub の `estrellaxd/auto_bangumi` に公開されます。
|
||||
|
||||
Docker Compose：`image` を変更し、コンテナを作り直します。
|
||||
|
||||
```yaml
|
||||
services:
|
||||
AutoBangumi:
|
||||
image: "ghcr.io/estrellaxd/auto_bangumi:4.0.0-beta.1"
|
||||
```
|
||||
|
||||
```shell
|
||||
docker compose pull
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Docker CLI：古いコンテナを削除し、新しいタグと同じオプションで `docker run` を再実行します。
|
||||
|
||||
ボリューム（`/app/config`、`/app/data`）、ポート、環境変数は変わりません。4.0 で追加された環境変数はありません。プラグインは `config/plugins/` にインストールされ、`/app/config` ボリュームに含まれます。
|
||||
|
||||
### アプリ内更新（3.3 のベータチャンネル）
|
||||
|
||||
3.3 で更新チャンネルにベータ版を選んでいる場合、**設定 → ソフトウェア更新** に `4.0.0-beta.N` が表示されます。4.0 の更新パッケージはイメージバージョン `4.0.0-beta.1` 以上を必要とします。3.3 のイメージで **今すぐ更新** を押すと、イメージが古いため新しいイメージを pull するよう求めるエラーで失敗します。前の節のとおりイメージタグを変更してください。安定版チャンネルのユーザーには 4.0 ベータ版は表示されません。
|
||||
|
||||
## 初回起動：設定の移行
|
||||
|
||||
AB は `config.json` を読み込む前に、3.3 形式かどうかを確認します。3.3 形式の場合、まず元のファイルを `config.json.v3.bak` にバックアップし、次のフィールドを 4.0 の場所へ移します。
|
||||
|
||||
| 3.3 のフィールド | 4.0 の場所 |
|
||||
| --- | --- |
|
||||
| `downloader` | `plugins.instances` 内の id が `default` のダウンローダーインスタンス。`type` は `provider` になり、その他のフィールド（ホスト、ユーザー名、パスワード、ダウンロードパス、SSL）は `options` に入ります |
|
||||
| — | `plugins.slots.downloader` を `"default"`（既定のダウンローダーインスタンス）に設定 |
|
||||
| `bangumi_manage.rename_method` | `plugins.slots.rename_strategy`。非推奨の `normal` は同じ動作の `none` に変わります |
|
||||
| `bangumi_manage.revision_conflict_policy` | `plugins.slots.conflict_policy` |
|
||||
| Bark チャンネルの `token` | `device_key` |
|
||||
| WeCom チャンネルの `chat_id` | `webhook_url` |
|
||||
|
||||
移行前後のダウンローダー設定の例：
|
||||
|
||||
::: code-group
|
||||
|
||||
```json [3.3]
|
||||
{
|
||||
"downloader": {
|
||||
"type": "qbittorrent",
|
||||
"host": "172.17.0.1:8080",
|
||||
"username": "admin",
|
||||
"password": "adminadmin",
|
||||
"path": "/downloads/Bangumi",
|
||||
"ssl": false
|
||||
},
|
||||
"bangumi_manage": {
|
||||
"rename_method": "pn",
|
||||
"revision_conflict_policy": "hold"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```json [4.0]
|
||||
{
|
||||
"plugins": {
|
||||
"slots": {
|
||||
"downloader": "default",
|
||||
"rename_strategy": "pn",
|
||||
"conflict_policy": "hold"
|
||||
},
|
||||
"instances": [
|
||||
{
|
||||
"id": "default",
|
||||
"point": "downloader",
|
||||
"provider": "qbittorrent",
|
||||
"options": {
|
||||
"host": "172.17.0.1:8080",
|
||||
"username": "admin",
|
||||
"password": "adminadmin",
|
||||
"path": "/downloads/Bangumi",
|
||||
"ssl": false
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
例には関連するフィールドだけを示しています。その他の設定は変わりません。
|
||||
|
||||
- **バックアップは上書きされません。** `config.json.v3.bak` がすでにある場合（3.3 にロールバックしてから再度アップグレードした場合など）、新しいバックアップは `config.json.v3.bak.1`、`config.json.v3.bak.2` などに保存されます。最初のバックアップに最も古い 3.3 の設定が入っています。
|
||||
- **移行に成功すると**、ログに `Migrated config.json to 4.0 (...); the 3.3 file is kept as config.json.v3.bak` が出力されます。括弧内は移動したフィールドです。
|
||||
- **移行に失敗すると**、`config.json` は 3.3 の内容のまま残り、AB は起動しません。ログに原因のフィールドが表示されます。そのフィールドを修正して再起動してください。
|
||||
- すでに 4.0 形式の設定は移行されず、バックアップも作られません。
|
||||
- 環境変数（`AB_DOWNLOADER_HOST`、`AB_METHOD` など）は引き続き有効です。読み込まれるのは `config.json` がない初回起動時だけで、値は既定のダウンローダーインスタンスと `plugins.slots` に書き込まれます。
|
||||
|
||||
同じ起動で、データベースは schema v26 に自動更新されます。プラグイン用のストレージテーブル `plugin_kv` が追加され、アニメ、映画、RSS 購読、トレントに `downloader_id` 列が追加されます。既存のトレントは `default` インスタンスに属します。既存のルールと購読の `downloader_id` は空で、既定インスタンスを使うことを意味します。
|
||||
|
||||
## 4.0 で変わる動作
|
||||
|
||||
### 複数のダウンローダー
|
||||
|
||||
**設定 → ダウンローダー設定** で複数のダウンローダーインスタンス（qBittorrent、aria2、またはプラグインのダウンローダー）を追加し、既定インスタンスを指定できます。ルールと RSS 購読はダウンローダーを選択でき、空欄なら既定インスタンスを使います。各トレントは所属するダウンローダーを記録し、リネームと削除はそのダウンローダー上で行われます。詳しくは [ダウンローダー設定](../config/downloader) を参照してください。
|
||||
|
||||
### リネームはプラグインに
|
||||
|
||||
`pn`、`advance` と新しい `template` は、既定で有効な内蔵プラグイン `rename` が提供します。`none` は AB 本体が提供します。`pn` と `advance` の出力は 3.3 と完全に同じです。
|
||||
|
||||
- `template` は自分で書いたテンプレートからファイル名を作ります。設定の保存時に AB がテンプレートを試しにレンダリングし、不正なテンプレートは保存できません。
|
||||
- 実行時にあるファイルのテンプレートのレンダリングに失敗すると、そのファイルは元の名前のまま残り、「ファイル名を変更しなかった」旨の通知が送られます。`pn` へのフォールバックはしません。
|
||||
- **設定 → プラグイン** で `rename` プラグインを無効にすると、すべてのアニメが `none` として扱われ、元のファイル名が保たれます。
|
||||
|
||||
詳しくは [アニメ管理設定](../config/manager) を参照してください。
|
||||
|
||||
### メディアライブラリへのハードリンク
|
||||
|
||||
新しい内蔵プラグイン `hardlink` は**既定で無効**です。有効にすると、トレントの整理が終わったときに動画と字幕をメディアライブラリのフォルダーにリンクします。ダウンロードフォルダーはそのまま残り、シードを続けます。
|
||||
|
||||
- ダウンローダーと AB から見えるパスが異なる場合（別々のコンテナで動いている場合など）、ダウンローダーインスタンスごとに `path_map` でパスの対応を設定します。
|
||||
- ハードリンクを作れない場合（ファイルシステムが異なる場合）、既定ではファイルをコピーします（`cross_device: copy`）。
|
||||
- Docker では、メディアライブラリのフォルダーも AB コンテナにマウントする必要があります。ハードリンクを使うには、ダウンロードフォルダーとメディアライブラリを同じディスクに置き、1 つのマウントポイントでコンテナにマウントしてください。
|
||||
|
||||
詳しくは [アニメ管理設定](../config/manager) を参照してください。
|
||||
|
||||
### その他の内蔵プラグイン
|
||||
|
||||
- トレントフィルタープラグイン `ingest-filters` は既定で有効です。`include` オプションが空のときは何もフィルターしません。
|
||||
- `media-server-refresh` は既定で有効です。Jellyfin / Emby / Plex のアドレスと API キーを設定したときだけ、ライブラリの更新を要求します。
|
||||
|
||||
### サードパーティープラグイン
|
||||
|
||||
ローカルフォルダー（`config/plugins/local/`）と pip でインストールしたプラグインは署名されていません。**設定 → プラグイン** で「未署名プラグインを許可」（`plugins.allow_unsigned`）をオンにしたときだけ読み込まれます。プラグインの開発は [プラグイン開発](../dev/plugins) を参照してください。
|
||||
|
||||
### 削除された機能
|
||||
|
||||
- 3.2 互換の GET 制御エンドポイント（`/api/v1/restart`、`/start`、`/stop`、`/shutdown`）と `GET /api/v1/auth/refresh_token`。POST を使ってください。これらを呼び出すスクリプトは修正が必要です。
|
||||
- 旧 `experimental_openai` 設定セクションと、通知の単一チャンネル用の旧フィールド。3.3 ですでに `llm` と `notification.providers` へ移行済みです。
|
||||
|
||||
## アップグレード後の確認
|
||||
|
||||
- [ ] ログに `Migrated config.json to 4.0` の行があり、`config` フォルダーに `config.json.v3.bak` がある。
|
||||
- [ ] **設定 → ダウンローダー設定** に id が `default` のインスタンスがあり、ホスト、ユーザー名、ダウンロードパスが 3.3 と同じで、接続できる。
|
||||
- [ ] リネーム方式が 3.3 と同じ。3.3 の `normal` は `none` と表示されますが、動作は同じでファイル名を変更しません。
|
||||
- [ ] **設定 → プラグイン** で `rename` プラグインが有効になっている。
|
||||
- [ ] Bark または WeCom の通知を使っている場合、テスト通知を送る。
|
||||
- [ ] ハードリンクやメディアサーバーの更新が必要な場合、**設定 → プラグイン** で有効にして設定する。
|
||||
- [ ] 3.2 の GET 制御エンドポイントを使うスクリプトを POST に変更した。
|
||||
|
||||
## 3.3 へのロールバック
|
||||
|
||||
::: danger 先に `version.info` を処理してください
|
||||
4.0 は `config/version.info` の末尾に `4.0.0-beta.N` の行を追加します。3.3 はマイナーバージョンだけを比較するため、最後の行が 4.0 だとデータを 3.0 のものと判断し、すべてのデータベーステーブルを作り直します。残るのはアニメのルールと最初のユーザーだけで、トレントの記録などその他のデータはすべて失われます。ロールバックの前に、`data` のバックアップを戻すか、`version.info` から 4.x の行を削除してください。
|
||||
:::
|
||||
|
||||
**アップグレード前の完全なバックアップがある場合**（推奨）：
|
||||
|
||||
1. コンテナを停止します。
|
||||
2. `config` と `data` フォルダーを `config.bak-3.3` と `data.bak-3.3` で置き換えます。
|
||||
3. イメージタグを 3.3（例：`3.3.6`）に戻し、コンテナを作り直します。
|
||||
|
||||
4.0 で行った変更（新しいアニメ、新しい購読、新しい設定）はすべて失われます。
|
||||
|
||||
**完全なバックアップがない場合：**
|
||||
|
||||
1. コンテナを停止します。
|
||||
2. `config/config.json.v3.bak` で `config/config.json` を上書きします。3.3 は `plugins.instances` を認識しないため、戻さないとダウンローダー設定が既定値になります。
|
||||
3. `config/version.info` を編集し、`4.` で始まる行をすべて削除して、最後の行を 3.3.x のバージョンにします。
|
||||
4. 4.0 でアプリ内更新を使った場合は、`config/updates/` フォルダーを削除します。削除しないと、3.3 のイメージが起動時にそこにある新しい 4.0 のコードを読み込みます。
|
||||
5. イメージタグを 3.3（例：`3.3.6`）に戻し、コンテナを作り直します。
|
||||
|
||||
この方法では、4.0 で追加したアニメとトレントの記録が残ります。3.3 は 4.0 で追加されたデータベースのテーブルと列を無視します。4.0 で変更した設定は失われます。
|
||||
|
||||
再び 4.0 にアップグレードすると移行がもう一度実行され、新しいバックアップは `config.json.v3.bak.1` に保存されます。
|
||||
@@ -65,6 +65,10 @@ title: 概要
|
||||
- メンテナンス不要、完全に透明な動作
|
||||
- 完全なTMDB形式のファイルとアニメメタデータを生成する内蔵TMDBパーサー
|
||||
- Mikan RSSフィードのリバースプロキシサポート
|
||||
- プラグインシステム（4.0）：ダウンローダー、通知チャンネル、メタデータソース、検索サイト、リネーム方式をプラグインで提供できます。SDK、`ab-plugin` コマンドライン、サンプルプラグインを用意しています。[プラグイン開発](../dev/plugins) を参照
|
||||
- 複数のダウンローダー（4.0）：複数の qBittorrent / aria2 インスタンスに同時に接続し、ルールや購読ごとにダウンローダーを指定できます
|
||||
- テンプレートリネーム（4.0）：自分で書いたテンプレートでファイル名を作れます
|
||||
- メディアライブラリへのハードリンクとメディアサーバーの更新（4.0）：ダウンロードフォルダーはシードを続け、整理したファイルをメディアライブラリにリンクします。整理完了後に Jellyfin / Emby / Plex へ更新を通知できます
|
||||
|
||||
## コミュニティ
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ hero:
|
||||
link: /ja/home/
|
||||
- theme: alt
|
||||
text: 更新履歴
|
||||
link: /ja/changelog/3.3
|
||||
link: /ja/changelog/4.0
|
||||
|
||||
features:
|
||||
- icon:
|
||||
@@ -28,7 +28,7 @@ features:
|
||||
- icon:
|
||||
src: /image/icons/qbittorrent-logo.svg
|
||||
title: qBittorrent / aria2 ダウンローダー
|
||||
details: qBittorrentまたはaria2を使用してアニメをダウンロード。AutoBangumiで既存のアニメ管理、過去のエピソードのダウンロード、エントリの削除が可能です。
|
||||
details: qBittorrentまたはaria2を使用してアニメをダウンロード。AutoBangumiで既存のアニメ管理、過去のエピソードのダウンロード、エントリの削除が可能です。4.0 からは複数のダウンローダーに同時に接続し、ルールや購読ごとに指定できます。
|
||||
- icon:
|
||||
src: /image/icons/tmdb-icon.png
|
||||
title: TMDBメタデータマッチング
|
||||
@@ -36,7 +36,14 @@ features:
|
||||
- icon:
|
||||
src: /image/icons/plex-icon.png
|
||||
title: Plex / Jellyfin / Infuse ...
|
||||
details: マッチング結果に基づいてファイル名とディレクトリ構造を自動整理。メディアライブラリソフトウェアが高い成功率でメタデータをスクレイピングできるようにします。
|
||||
details: マッチング結果に基づいてファイル名とディレクトリ構造を自動整理。メディアライブラリソフトウェアが高い成功率でメタデータをスクレイピングできるようにします。メディアライブラリへのハードリンクや、整理完了後の Jellyfin / Emby / Plex の更新にも対応します。
|
||||
- icon:
|
||||
light: /image/icons/light-icon.svg
|
||||
dark: /image/icons/dark-icon.svg
|
||||
title: プラグイン
|
||||
details: 4.0 から、ダウンローダー、通知チャンネル、メタデータソース、検索サイト、リネーム方式をプラグインで提供できます。SDK と ab-plugin コマンドラインで独自のプラグインを作れます。
|
||||
link: /ja/dev/plugins
|
||||
linkText: プラグイン開発
|
||||
---
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user