[NAS 系列第二彈]配置全自動的影視文件下載、刮削和整理

在上一篇文章中，我記錄了硬體組裝和系統安裝的過程，最後成功安裝了 Arch Linux：

接下來我將著重描述應用軟體的使用和配置。今天這篇主要寫如何配置全自動的影視文件下載、刮削和整理。

注：

讀者繼續前需確保自己對 BT、PT 等概念有著基本的認識；

nastools 需要有認證站點帳號才能正常使用，後續不會額外描述，請自行獲取認證站點帳號使用；

本篇僅描述思路和整體流程，不會將所有相關知識都羅列出來，還請結合相關資料食用；

本篇不解決網路問題，默認 docker 鏡像等均可連接外網，如果不行請手動為鏡像配置 HTTP_PROXY、HTTPS_PROXY。

總述#

在介紹流程前，我需要針對這套流程的各個組件分別做一個簡單的介紹，讓讀者對此有一個整體的認識。下面對這些組件分小節描述。

資源來源#

很好理解，我們要下載的文件總是有一個來源的，在這個場景中，我們的資源來源主要指各類 PT 站點。

索引器#

為了在站點中查找資源，我們需要索引器。顧名思義，索引器就是在站點中搜索用戶輸入的內容，並返回結果的工具。

下載器#

在索引結束，我們挑選出匹配的資源後，需要將資源的種子交給各類 BT 下載工具，讓其解析種子內容並下載到本地。

媒體伺服器#

在文件下載到本地後，我們需要一個集中入口以訪問和管理我們的視頻文件，提供遠程播放等功能。這種工具即媒體伺服器。

刮削器#

所謂刮削器，就是從一個視頻文件中提取這個視頻相關的影片圖片、評分、描述等信息的工具。這類工具一般的實現機制是使用視頻的文件名去開放的影片信息站點（如 TMDB）找到匹配的影片信息，然後用匹配到的影片信息標記這個視頻文件。
一般來說媒體伺服器會自帶刮削功能，可以識別本地文件對應的影片，但效果較差，往往無法匹配到。

轉移器#

轉移器和刮削器緊密相關。上面提到媒體伺服器會自帶刮削功能，但效果較差。主要有兩個途徑解決這一點：

不使用媒體伺服器的自帶刮削，自己手動使用第三方工具（如 TMM ）手動刮削；
把視頻文件的名字改為簡單的 “影片名 + 年份” 的格式，這種格式的命名被媒體伺服器的自帶刮削識別的概率幾乎是百分百。

這裡的第二種途徑就是我說的 “轉移”，但由於下載器不僅要下載視頻文件，還需要保證視頻文件存在，不然無法做種。因此轉移也大體分出了四個類型：

移動 / 重命名（直接修改原始文件，不能繼續做種）
複製（拷貝一份，可以繼續做種但浪費一半的硬碟空間）
軟鏈接（不額外佔用空間，但由於軟鏈接往往不會被視為文件，使用一般的文件管理器瀏覽目錄時無法看到軟鏈接）
硬鏈接（不額外佔用空間，可以被文件管理器識別，但無法跨硬碟分區）

實踐上往往選擇軟鏈接和硬鏈接做文件的轉移。

總結#

以上，我介紹了這個流程的各個組成部分，為了方便理解拆得比較零散，很多工具都是同時具有其中的多項功能的。

在後文中，我將使用 nastools 接入資源來源並作為索引器、轉移器， qbittorrent 作為下載器，emby 作為刮削器、媒體伺服器來進行配置。

前置依賴#

下列應用程序均使用 docker /docker compose 運行，在 Arch Linux 中，可以通過如下命令安裝：

sudo pacman -S docker docker-compose

運行 Qbittorrent#

使用 johngong/qbittorrent:latest 鏡像運行，以下是我的 compose.yml 範例：

services:
  container:
    network_mode: host
    environment:
      - UID=1000
      - GID=1000
      - UMASK=022
      - TZ=Asia/Shanghai
      - QB_WEBUI_PORT=54321  # web 端口
      - QB_EE_BIN=false
      - QB_TRACKERS_UPDATE_AUTO=true
      - QB_TRACKERS_LIST_URL=https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_best.txt
    volumes:
      - /home/amtoaer/Downloads:/Downloads  # 下載目錄
      - /home/amtoaer/.config/nas/qbittorrent:/config  # 配置文件
    image: johngong/qbittorrent:latest
    restart: always

使用 docker compose up -d 運行，打開 ip:${QB_WEBUI_PORT}能夠看到頁面即可，此處不贅述：

WX20230811-230514@2x

運行 Emby#

Emby 本身是付費軟體，此處使用的是破解版，如有需要還請購買正版。

使用如下 compose 文件：

services:
  container:
    network_mode: bridge
    image: lovechen/embyserver:latest
    environment:
      - UID=1000
      - GID=1000
      - GIDLIST=0
    volumes:
      - /home/amtoaer/.config/nas/emby:/config  # 配置文件
      - /home/amtoaer/Videos:/Videos  # 媒體目錄（非下載目錄）
    ports:
      - 54319:8096  # 左邊是宿主機端口
    devices:
      # 此處需參考官方文檔，可能需掛載內容不一致
      - /dev/dri:/dev/dri
    restart: always

同樣 docker compose up -d 運行，打開 ip:port 訪問 web 頁面，完成初始化過程，進入到主頁（初始化完成應該是空的，不過佈局與此一致）：

運行 nas-tools#

services:
  container:
    network_mode: bridge
    ports:
      - 54317:3000  # 左邊是宿主機端口
    volumes:
      - /home/amtoaer/.config/nas/nas-tools:/config  # 配置文件
      - /home/amtoaer/Downloads:/Downloads  # 下載目錄
      - /home/amtoaer/Videos:/Videos  # 媒體目錄
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=022
      - NASTOOL_AUTO_UPDATE=false
      - NASTOOL_CN_UPDATE=false
    image: nastool/nas-tools:latest
    restart: always

運行命令與上面相同，打開 ip:port，登錄帳號：

配置#

接下來需要通過配置來讓這幾個程序聯動，整體的工作流程是這樣：

nastools 中配置 PT 站點的帳號，並開啟對應的索引器；
在 nastools 中搜索或訂閱資源，下載時向 Qbittorrent 拋出下載任務；
下載結束後，觸發 nastools 的轉移，將視頻文件通過指定的轉移方式從下載目錄轉移至媒體目錄；
emby 將媒體目錄設置為媒體庫，文件轉移結束後識別到媒體目錄下有了新的文件，觸發刮削流程，將視頻顯示在 emby 中。

下面分別詳述。

配置帳號並開啟索引器#

進入 nastools 側邊欄的 “站點維護”，點擊右上角 “新增站點”，添加站點相關信息：

接著在側邊欄 “設置 -> 索引器” 中，打開所有支持的站點：

設置下載器#

側邊欄 “設置 -> 下載器” 中，配置連接自己的下載器：

注：

nastools 運行於 docker 中，172.17.0.1 是 docker 默認網路的默認網關，表示宿主機。

監控設置成 “是” 表示下載完畢時觸發轉移，設置成 “否” 表示監聽下載目錄，當下載目錄下有新文件時觸發轉移。個人設置為 “否”，通過監聽下載目錄完成轉移。

設置監聽目錄#

如果下載器的監控設置選擇了 “否”，需要在側邊欄 “設置 -> 目錄同步” 中開啟對下載目錄的監聽，樣例如下：

這裡我轉移方式選擇了 “複製”，讀者可能會感到奇怪，因為複製明明會佔用雙倍的存儲空間，造成嚴重浪費。對此好奇的讀者可以查看文末我的解釋。

設置媒體伺服器#

點擊側邊欄 “設置 -> 媒體伺服器”，選擇 Emby 並填寫內容：

API Key 通過 Emby “設置 -> API 密鑰” 生成。

設置 Emby 的媒體庫目錄#

在 Emby “設置 -> 媒體庫” 中新增媒體庫，一個示例的配置如下：

總結#

經過上述配置後，這套流程應該已經可以正常工作了，以下作為演示：

在搜索框搜索影片名稱，並點擊影片左下方的搜索

點擊想下載的種子，選擇分類（當然也可以自動）後下載

看到 nastools 自動為 Qbittorrent 添加了任務：

下載完成後自動轉移，並被 Emby 刮削展示在媒體庫中

至此配置完成。

拓展閱讀#

為何寧可使用閉源付費的 emby 破解版也不使用 emby 的開源 fork jellyfin？#

一言以蔽之，使用體驗差異巨大。

最開始我也抱著支持開源的心態，首先嘗試了 jellyfin，但在使用過程中，至少發現了如下問題：

整體 UI 醜陋且幾乎毫無變化
雖然最近推出了 jellyfin-vue，但也還沒有應用到客戶端，而且 android 客戶端不會使用系統字體，而是自帶了一套，觀感割裂。
令人難以忍受的高強度磁碟 IO
在刮削時 jellyfin 的硬碟讀寫極其頻繁，emby 這邊即使開啟 “識別視頻片頭” 這種依賴讀取視頻文件的功能，都要比 jellyfin 的普通刮削更加安靜迅速。
慢到令人發指的初次刮削速度
曾經我有將近 8T 的資源，使用 jellyfin 在無任何額外設置的前提下居然刮削了數個禮拜。查詢 jellyfin 的相關 issue，發現這個問題在很久前就有人提過，但掛了三年多還是 open。

因此，我拋棄了 jellyfin，轉投到了 emby 的懷抱。

雖然但是，十分不推薦小夥伴們用盜版軟體。因為我最開始是抱著試試的心態，所以沒有下決心付費，畢竟 119 刀不是個小支出，但嫖了這麼久也差不多到補票時間了。
~~最近人民幣跌太狠了，等漲一些就打算補票入正了。~~

轉移方式為何選擇複製，不會佔用額外存儲空間嗎？#

如我上文所述，為了不浪費額外存儲空間，轉移方式往往會在軟鏈接和硬鏈接中選擇，但為什麼我要選擇複製呢？是因為我硬碟使用的 btrfs 文件系統支持 cow 機制。

簡單來說，文件系統中的 cow 是指在複製文件時，新文件僅僅包括了一份元信息，實際的數據塊是和原始文件共用的，在後續要對複製的文件做修改時才會實際複製這個文件的數據塊。考慮我們的文件轉移場景，其實僅僅是想要把視頻文件移動到一個新位置，並沒有任何對視頻文件做修改的需求，所以可以完美利用這個機制達到復用空間的目的。

這樣做一方面避免了軟鏈接在文件管理器中無法識別的弊端，又繞過了硬鏈接只能在同一塊物理硬碟的限制（未實際嘗試但理論上可行，因為 btrfs 既支持創建跨多塊物理硬碟的磁碟分區，又支持分區內子卷的 cow 複製）。

但實際使用發現 nastools 中的複製不支持該特性，查看源碼可以得知 nastools 中使用的複製是 shutil.copy2(os.path.normpath(src), os.path.normpath(dest))，而該方法是不支持這種空間復用（又被稱為 reflink）的特性的。因此我將代碼中此處換成了第三方庫 reflink 來達到目的。

實際可以看到通過 reflink 複製過來的視頻文件都是沒有佔用任何額外空間的：

晓风残月