晓风残月

前回の記事では、ハードウェアの組み立てとシステムのインストールの過程を記録し、最終的に Arch Linux を成功裏にインストールしました：

次に、アプリケーションソフトウェアの使用と設定について詳しく説明します。今日の記事では、完全自動の映画ファイルのダウンロード、スクレイピング、整理の設定方法について主に書きます。

注：

1. 読者は、BT、PT などの概念について基本的な理解があることを確認してください；
2. nastools は認証サイトのアカウントが必要ですので、後述はしませんので、自分で認証サイトのアカウントを取得してください；
3. 本記事では、考え方と全体の流れのみを説明し、すべての関連知識を列挙することはありませんので、関連資料と併せてご利用ください；
4. 本記事ではネットワークの問題を解決しません。docker イメージなどは外部ネットワークに接続できることを前提としています。接続できない場合は、手動でイメージに HTTP_PROXY、HTTPS_PROXY を設定してください。

概要#

プロセスを紹介する前に、このプロセスの各コンポーネントについて簡単に紹介し、読者が全体を理解できるようにします。以下にこれらのコンポーネントを小節に分けて説明します。

リソースの出所#

理解しやすいように、ダウンロードするファイルには常に出所があります。このシナリオでは、私たちのリソースの出所は主に各種の PT サイトを指します。

インデクサー#

サイト内でリソースを検索するために、インデクサーが必要です。名前の通り、インデクサーはサイト内でユーザーが入力した内容を検索し、結果を返すツールです。

ダウンローダー#

インデックスが完了し、マッチするリソースを選択した後、リソースのトレントを各種の BT ダウンロードツールに渡し、トレントの内容を解析してローカルにダウンロードします。

メディアサーバー#

ファイルがローカルにダウンロードされた後、私たちの動画ファイルにアクセスし管理するための集中入口が必要です。これがメディアサーバーです。

スクレイパー#

スクレイパーとは、動画ファイルからその動画に関連する映画の画像、評価、説明などの情報を抽出するツールです。この種のツールは一般的に、動画のファイル名を使ってオープンな映画情報サイト（例えば TMDB）でマッチする映画情報を見つけ、その情報を使ってこの動画ファイルにタグ付けします。
一般的に、メディアサーバーはスクレイピング機能を内蔵しており、ローカルファイルに対応する映画を認識できますが、効果はあまり良くなく、マッチできないことが多いです。

トランスファー#

トランスファーはスクレイパーと密接に関連しています。上記で述べたように、メディアサーバーはスクレイピング機能を内蔵していますが、効果はあまり良くありません。これを解決するための主な方法は二つあります：

• メディアサーバーの内蔵スクレイピングを使用せず、手動で第三者ツール（例えば TMM）を使用して手動でスクレイピングする；
• 動画ファイルの名前をシンプルな「映画名 + 年」の形式に変更する。この形式の命名は、メディアサーバーの内蔵スクレイピングによってほぼ 100% 認識されます。

ここでの二つ目の方法が私が言う「トランスファー」ですが、ダウンローダーは動画ファイルをダウンロードするだけでなく、動画ファイルが存在することを保証する必要があります。そうでなければ、シードできません。したがって、トランスファーは大きく四つのタイプに分かれます：

1. 移動 / 名前変更（元のファイルを直接変更し、シードを続けることはできません）
2. コピー（コピーを作成し、シードを続けることができますが、ハードディスクのスペースを半分浪費します）
3. ソフトリンク（追加のスペースを占有しませんが、ソフトリンクはファイルとして認識されないことが多いため、一般的なファイルマネージャーでディレクトリをブラウズする際にソフトリンクが見えません）
4. ハードリンク（追加のスペースを占有せず、ファイルマネージャーで認識されますが、ハードディスクパーティションを越えることはできません）

実際には、ファイルのトランスファーにはソフトリンクとハードリンクが選ばれることが多いです。

まとめ#

以上のように、このプロセスの各構成要素を紹介しました。理解を容易にするために、比較的散発的に分けましたが、多くのツールは同時に複数の機能を持っています。

後の文では、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} を開くとページが表示されますので、ここでは詳述しません：

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 を開いてアカウントにログインします：

設定#

次に、これらのプログラムを連携させるために設定を行います。全体の作業フローは次のようになります：

1. nastools で PT サイトのアカウントを設定し、対応するインデクサーを有効にします；
2. nastools でリソースを検索または購読し、ダウンロード時に Qbittorrent にダウンロードタスクを投げます；
3. ダウンロードが終了した後、nastools のトランスファーをトリガーし、動画ファイルを指定されたトランスファー方法でダウンロードディレクトリからメディアディレクトリに移動します；
4. emby はメディアディレクトリをメディアライブラリとして設定し、ファイルの移動が完了した後にメディアディレクトリに新しいファイルがあることを認識し、スクレイピングプロセスをトリガーして動画を emby に表示します。

以下でそれぞれ詳述します。

アカウントの設定とインデクサーの有効化#

nastools のサイドバーの「サイト管理」に入り、右上の「新しいサイト」をクリックしてサイトの関連情報を追加します：

次に、サイドバーの「設定 -> インデクサー」で、すべてのサポートされているサイトを有効にします：

ダウンローダーの設定#

サイドバーの「設定 -> ダウンローダー」で、自分のダウンローダーへの接続を設定します：

注：

1. nastools は docker 内で実行されており、172.17.0.1 は docker のデフォルトネットワークのデフォルトゲートウェイで、ホストを示します。

2. 監視設定を「はい」にすると、ダウンロード完了時にトランスファーがトリガーされ、「いいえ」にすると、ダウンロードディレクトリに新しいファイルがあるときにトランスファーがトリガーされます。個人的には「いいえ」に設定し、ダウンロードディレクトリの監視を通じてトランスファーを完了させます。

監視ディレクトリの設定#

ダウンローダーの監視設定を「いいえ」にした場合、サイドバーの「設定 -> ディレクトリ同期」でダウンロードディレクトリの監視を有効にする必要があります。サンプルは以下の通りです：

ここで私はトランスファー方法として「コピー」を選択しました。読者は、コピーは明らかに二倍のストレージスペースを占有し、深刻な浪費を引き起こす可能性があるため、奇妙に感じるかもしれません。この点について興味がある読者は、文末の私の説明を参照してください。

メディアサーバーの設定#

サイドバーの「設定 -> メディアサーバー」をクリックし、Emby を選択して内容を記入します：

API キーは Emby の「設定 -> API キー」で生成します。

Emby のメディアライブラリディレクトリの設定#

Emby の「設定 -> メディアライブラリ」で新しいメディアライブラリを追加します。以下は一例の設定です：

まとめ#

上記の設定を経て、このプロセスは正常に機能するはずです。以下はデモです：

1. 検索ボックスで映画名を検索し、映画の左下にある検索をクリックします。

2. ダウンロードしたいトレントをクリックし、カテゴリを選択（もちろん自動でも可能）してダウンロードします。

3. nastools が自動的に Qbittorrent にタスクを追加したことが確認できます：

4. ダウンロードが完了した後、自動的にトランスファーされ、Emby によってスクレイピングされ、メディアライブラリに表示されます。

これで設定が完了しました。

拡張リーディング#

なぜ閉源の有料 Emby クラック版を使用するのか、Emby のオープンソースフォーク Jellyfin を使用しないのか？#

一言で言えば、使用体験の差が非常に大きいです。

最初はオープンソースを支持する気持ちで Jellyfin を試しましたが、使用中に少なくとも以下の問題を発見しました：

1. 全体の UI が醜く、ほとんど変化がない
   最近 Jellyfin-vue がリリースされましたが、まだクライアントに適用されておらず、Android クライアントはシステムフォントを使用せず、自前のフォントを使用しているため、視覚的に不一致です。
2. 耐え難い高強度のディスク IO
   スクレイピング中、Jellyfin のハードディスクの読み書きが非常に頻繁で、Emby では「動画の冒頭を認識する」といった動画ファイルの読み取りに依存する機能を有効にしても、Jellyfin の通常のスクレイピングよりも静かで迅速です。
3. 初回のスクレイピング速度が遅すぎる
   かつて私は約 8T のリソースを持っていましたが、Jellyfin を使用して何の追加設定もせずに数週間もスクレイピングされました。Jellyfin の関連 issue を調べると、この問題はずっと前に誰かが提起していたことがわかりましたが、3 年以上もオープンのままです。

したがって、私は Jellyfin を捨て、Emby に移行しました。

ただし、友人たちに盗版ソフトウェアを使用することは非常にお勧めしません。最初は試してみるつもりだったので、決心して支払うことはありませんでした。119 ドルは小さな支出ではありませんが、こんなに長い間試してきたので、そろそろ補填の時期です。
最近人民元が急落したので、少し上昇したら正規版を購入するつもりです。

なぜトランスファー方法としてコピーを選択するのか、追加のストレージスペースを占有しないのか？#

上記で述べたように、余分なストレージスペースを浪費しないために、トランスファー方法は通常ソフトリンクとハードリンクの中から選択されますが、なぜ私はコピーを選択したのでしょうか？それは、私のハードディスクが btrfs ファイルシステムを使用しており、cow メカニズムをサポートしているからです。

簡単に言うと、ファイルシステム内の cow は、ファイルをコピーする際に、新しいファイルはメタ情報のみを含み、実際のデータブロックは元のファイルと共有されます。後でコピーしたファイルを変更する必要がある場合にのみ、実際にそのファイルのデータブロックがコピーされます。私たちのファイルトランスファーのシナリオを考えると、実際には動画ファイルを新しい位置に移動したいだけであり、動画ファイルを変更する必要はありません。したがって、このメカニズムを完璧に利用してスペースを再利用することができます。

このようにすることで、ソフトリンクがファイルマネージャーで認識されないという欠点を回避し、ハードリンクが同じ物理ハードディスク内でのみ機能するという制限を回避できます（実際には試していませんが、理論的には可能です。なぜなら、btrfs は複数の物理ハードディスクにまたがるパーティションを作成することをサポートし、パーティション内のサブボリュームの cow コピーもサポートしているからです）。

しかし、実際の使用では、nastools のコピーはこの機能をサポートしていないことがわかりました。ソースコードを確認すると、nastools で使用されているコピーは shutil.copy2(os.path.normpath(src), os.path.normpath(dest)) であり、このメソッドはこのようなスペース再利用（別名 reflink）の特性をサポートしていません。したがって、私はコードのこの部分を第三者ライブラリ reflinkに変更して目的を達成しました。

実際に reflink を使用してコピーされた動画ファイルは、追加のスペースを占有していないことが確認できます：

関連資料#

上記で紹介した機能は、これらのツールのごく一部に過ぎません。nastools は動画の購読、自分で定義した認識語、自分で定義した無視語などもサポートしています。emby は冒頭のマーク付け、ユーザー管理、動画のトランスコードなどもサポートしています。ユーザーは資料を参照して自分で探索してください：

1. nastools 公式 wiki
2. emby ドキュメント