Introduction

AutoBangumi is an “RSS-based fully automated anime tracking and download tool” (hereinafter referred to as AB), which is very suitable for users like me who use both qBittorrent (hereinafter referred to as QB) and Jellyfin. After using AB to track anime for a season, I have gained a deeper understanding of AB, Jellyfin, and concepts such as RSS and scraping. Although AB provides automation, it also increases the complexity of the tracking process, especially when AB encounters issues.

Based on my past experiences with the QB RSS feature and combined with my new understanding, I chose to stop using AB and instead use QB RSS. Although this adds a few more steps for tracking new anime each season, the overall system complexity and resource usage are reduced. Overall, I am satisfied with this change.

Automated Anime Tracking Workflow

flowchart LR
subgraph g1[RSS Subscriber]
a1[AB] ~~~ a2[QB]
end
subgraph g2[RSS Downloader]
b1[AB] ~~~ b2[QB]
end
subgraph g3[torrent Downloader]
c1[QB] ~~~ c3[Transmission]
end
subgraph g4["Post-Download Tasks (Optional)"]
d1[Email Notification] ~~~ d2[Rename Downloaded Videos] ~~~ d3[Make Hard Links]
end

subgraph g5["Jellyfin (Plugins) Scraping"]
e1[Bangumi] ~~~  e2[AniDB] ~~~ e3[TMDB]
end
g1-->g2-->g3-->g4-->g5

Introduction

In a previous article, I mentioned that ‘Jellyfin’s scheduled task “Scan Media Library” does not consume resources and can run frequently without issues’. In fact, this statement is not entirely correct. The resource consumption of the task depends on the number of media/files.

Recently, I developed a project to scrape videos while automatically generating NFO files and video posters. In this new video directory, there are up to 2000 files (mostly NFO and poster images, with videos not yet downloaded), organized into four-level subdirectories. However, the CPU usage of the scheduled task has increased significantly, indicating an issue.

After some research, I found that using crontab to periodically call the Jellyfin API is currently the only solution to customize scan frequencies for different media libraries.

Introduction

This post covers various scenarios for accessing Docker containers, exploring whether to use the container’s IP address or name in each case. While this information might be trivial for seasoned Docker users, I often find myself forgetting these basic concepts, wasting a lot of time. Hence, I decided to write a blog post in the form of a cheat sheet. Most of the content here is generated by ChatGPT.

In general, just remember these two points:

• Although we prefer to access containers by their names, this DNS service is provided by Docker and can only be used by containers.
• For port mapping -p 8080:80: Use the container’s port 80 when accessing the container via container name/IP, and use the host’s port 8080 when accessing from the host.

Introduction

This post mainly covers the mechanisms and syntax of Docker healthcheck and Docker Compose’s depends_on. This post can be viewd as a cheat sheet.

healthcheck Mechanism

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.

问题

最近外网爆出了 Intel 13、14 代 i9 打游戏会报显存错误。这个也许只是 CPU 不稳定导致的短时运算错误，不足为惧^[1]。但是，B站上有人讨论很多 14 代 i9 在待机模式下蓝屏，甚至 13700K 也出现了这种现象。如果消息准确，那么使用了半年的 14代 i9 就出现了“缩缸”现象（硬件损坏导致的永久性能损失）。理论上，CPU 的寿命至少是 10 年，而且大部分 CPU 都是不用了、而不是用坏了。我的 CPU 就是 13700K，这让我非常警惕。

对于这个问题的讨论有两点需要厘清：

1. 软件报错，比如游戏、压测工具和渲染工具。这一点占据了极大比例的流量。目前，无论是 Intel 官方还是第三方网站、博主，给出的解决方案都是限制功耗和降频，使得软件不会报错。Intel 把锅甩给主板厂商，要求它们按照 Intel 标准来设置 BIOS。目前来看，这个所谓的 Intel 标准电压更高、频率更低，跑分更差。要注意，频率降低等于消费者吃亏。因此，Intel 和主板厂商都有责任。
2. CPU“缩缸”，这是产品缺陷。这一点只占据很小比例的流量。显然，Intel 永远不会承认这一点。也许从 23 年 6 月 Intel 质保政策开始收紧时^[2]，Intel 已经知道了这一事实。

我是在 23 年初配的电脑，轻度办公、写一写代码，基本没玩过 3A 大作。最近，我用 CPU-Z 和 R23 测试了性能，和网上的结果^[3][4]差不多。因此，我的 13700K 应该没有“缩缸”。

话说回来，我倒不是很关心降频，我更关心 CPU 寿命。目前自动核心电压为 1.38 V，R23 跑一次就 100 度。这样的配置，迟早要“缩缸”。因此，本文主要记录我是如何给 CPU 降压的，以及在研究过程中发现的各种问题。