序言

如果要用数据库保存文件目录的结构，应该使用哪种数据库？ —— 要么 NoSQL，要么 RDBMS。选取 NoSQL，应该选择支持树形结构的；选取 RDBMS，重点在于表的设计和查询操作。

这个问题的关键在于：我们要对数据库中的目录结构做何种操作？ 显然，这些操作本质上是对文件系统上文件的操作。

• 操作1：单个文件/目录的增删改查，即拷贝、删除、剪切某个文件/目录；
• 操作2：递归遍历某个目录；

只有考虑了这两点，才能设计出高效的方案。本文给出了 NoSQL 和 RDBMS 的方案，重点在于后者。另外，本文还探讨了使用 JSON 的方案。

序言

AutoBangumi 是一款“基于 RSS 的全自动追番整理下载工具”（以下简称 AB），很适合我这种同时使用 qBittorrent （以下简称 QB） 和 Jellyfin 的用户。在使用 AB 追了一个季度的番剧后，我对于 AB、Jellyfin等软件以及 RSS、刮削等概念有了更深的理解。尽管 AB 提供了自动化，但引入它也增加了追番流程的复杂度 —— 尤其表现在 AB 出问题时。

回顾以往使用 QB RSS 功能的经历，加上新的理解，我选择不再使用 AB，而是使用 QB RSS 来代替。尽管在每个季度追新番时的步骤增加了一些，但整个系统的复杂度和资源占用量降低了。总的来说，我对这个改变是满意的。

自动化追番流程

flowchart LR
subgraph g1[RSS订阅器]
a1[AB] ~~~ a2[QB ]
end
subgraph g2[RSS下载器]
b1[AB] ~~~ b2[QB]
end
subgraph g3[torrent下载器]
c1[QB] ~~~ c3[Transmission ]
end
subgraph g4[下载后任务（可选）]
d1[邮件通知下载完成] ~~~ d2[修改下载视频名] ~~~ d3[创建硬链接]
end

subgraph g5[Jellyfin（插件）刮削]
e1[Bangumi] ~~~  e2[AniDB] ~~~ e3[TMDB]
end
g1-->g2-->g3-->g4-->g5

序言

在之前的文章中，我提到“Jellyfin 计划任务『扫描媒体库』并不吃资源，频繁运行也没事”。实际上，这不准确。这个任务对于资源的占用取决于媒体/文件的数量。

最近我写了一个项目，用来爬取视频，同时自动生成 nfo 文件和视频海报。在这个新的视频目录中，最多有 2000 个文件（大部分是 nfo 和海报图片，视频还没怎么下载），有四级子目录。但此时计划任务的 CPU 占用量已经大幅增加。这显然有问题。

经过一番研究，我发现使用 crontab 定时调用 Jellyfin API，是目前唯一实现不同媒体库不同扫描频率的解决方案。

序言

本文包括了多种访问 Docker 容器的情况，探讨了每种情况应该使用容器的 IP 地址还是容器名。本文的内容对于熟练使用 Docker 的人不值一提，但在实践中，我常常忘记这些基本概念，浪费了不少时间。因此，我决定以 cheat sheet 的形式写一篇博文。本文的大部分内容由 ChatGPT 生成的。

总的来说，记住以下两点就够了：

• 尽管我们喜欢用容器名访问容器，但这个 DNS 服务是由 docker 提供的，因此只能被容器使用。
• 对于端口映射 -p 8080:80 ：用容器名/容器 IP 访问容器时，用容器的端口 80；用主机访问容器时，用主机的端口 8080。

序言

本文主要包括 Docker healthcheck 的机制、语法，以及 Docker compose 的 depends_on 机制、语法。本文可以视作一个 cheat sheet。

healthcheck 机制

When a container has a healthcheck specified, it has a health status in addition to its normal status. This status is initially starting. Whenever a health check passes, it becomes healthy (whatever state it was previously in). After a certain number of consecutive failures, it becomes unhealthy.