AI に Plex トランスコードを処理させ、指を離さずに 8.5 TB を節約しました

私の Plex ライブラリが大きくなりすぎたので、サイズを縮小する時期が来ました。もちろん、削除することもできますが、そこにあったもののほとんどは残しておきたかったのです。そこで、ライブラリ全体を H.265 に変換することにしたところ、10 TB 近くのスペースが節約されました。

NAS のダウンサイジングはライブラリのダウンサイジングを意味します

古い映画やテレビ番組を削除してもここまでしかできません

私は最近、12 ドライブ ベイと 80 TB のストレージを備えた古いエンタープライズ グレードの NAS から、6 ドライブ ベイに 3 つのドライブと合計 40 TB のストレージを備えた UGREEN NAS に移行しました。

この小型化により文字通り毎月数百ドルの電気代が節約できますが、欠点がないわけではありません。私の Plex ライブラリは非常に大きく、移転前は 40 TB をはるかに超えていました。

そこで、何年も誰も見ていないものを削除することから始めました。現時点で私は Plex ライブラリを約 6 年間実行していますが、最初からそこにあったものの、一度も見ていなかったコンテンツもあります。

最近は何にでも Codex を使用していますが、これを Tautulli と統合して、誰も見ていないメディアを見つけて削除候補のリストを提供してもらいました。同様のことは Maintainerr を使用しても実現できますが、私は Codex を使用することにしました。

そこから、本当に「必要のない」数十テラバイトのメディアをサーバーから削除しました。使用可能なスペースが 80 TB あったので、これまでは何もしなかったので、すべてをそのままにしておきました。

不要なものをすべて削除したら、約 30TB まで減りました。 40 TB を使用していたことを考えると、これは多すぎるように聞こえるかもしれませんが、それでも私にとって十分快適ではありませんでした。そこで、次のステップに進むことにしました。それは、自分のファイルをトランスコードすることです。 全体 プレックスライブラリ。

前回トランスコードを試みたときは、永遠に時間がかかり、大変な作業でした

Gemini に ffmpeg スクリプトを書かせましたが、あまりきれいではありませんでした

クレジット: Patrick Campanale / How-To Geek

2026 年の初めに、私は時間をかけていくつかの映画を H.264 から H.265 にトランスコードしました。正直に言うと、首が痛くて完全に混乱していました。確かに仕事はやり遂げましたが、複雑でした。

ffmpeg スクリプトの作成には AI を使用していましたが、すべて手動でした。自分のニーズとセットアップを Gemini (当時使用していた AI) に入力すると、使用するスクリプトが提供されます。失敗するまでテストしてから、Gemini でデバッグしてみます。

ここで何度もやり取りがあり、それが最も苦痛な部分でした。問題なく動作しているように見えても、一晩で障害が発生し、トランスコードに費やせるはずの時間が何時間も無駄になってしまうことがあります。

全体として、それは 働いた しかし、それは私が望んでいたようには機能しませんでした。私は大規模なライブラリを扱っていましたが、7 TB のスペースしか回復できませんでした。

しかし今回は、約 30 TB のメディアから始めたので、別のルートを選択しました。Codex に最初から最後まで処理してもらいました。

今回のライブラリの縮小はシンプルで簡単でした

Codex に面倒な作業を任せると、H.264 から H.265 への変換は簡単でした

Codex の私のお気に入りの機能の 1 つは、スケジュールされたタスクを実行できることです。そこで、今回ライブラリをトランスコードしようとしたとき、そのタスクを Codex に任せることにしました。

Codex は SSH を使用して、Tdarr に使用するすべてのノードを構成し、各ノードの Tdarr 内にカスタム ffmpeg スクリプトとプラグイン フローを構築しました。できるだけ早くトランスコーディングを完了するために、合計 5 つのノードを実行しました。

私の Plex サーバーは現在、HEVC コンテンツをネイティブに処理できる新しいプラットフォームで実行されているため、H.265 にトランスコードすることにしました。さらに、H.265 は H.264 よりも占有するスペースが大幅に少なくなります。

一部のノードでは NVIDIA CUDA が使用され、その他のノードでは統合された Intel グラフィックスが使用されました。プラグインのフローが面倒だったので、これは私が初めて Tdarr をセットアップしたときの最大の問題の 1 つでした。ただし、コーデックスはそれをチャンピオンのように扱いました。

私は基本的に Codex に希望を伝え、Codex がすべてを設定してくれました。そこから、Codex に 15 分ごとにトランスコード ステータスを監視するように指示しました。したがって、15 分ごとに現在の進行状況でスレッドを更新し、エラーがあればフラグを立てます。

ここで、Codex が本格的に力を発揮し始めました。私は、Codex にエラーを自動的に修正してもらいました。この時点ではメディアを失う心配はありませんでした。古い NAS にバックアップがあったので、必要なものはすべて再リッピングできました。

そのため、15 分間のチェック中に Codex が問題を検出すると、スクリプトを修正し、失敗したものを再度キューに入れます。基本的に、すべての処理が完了するまでにかかる時間として、Codex にトランスコードを約 72 時間実行させました。

すべての終わりに、8.5TBのスペースを取り戻しました ただ 私のメディアをトランスコーディングした Codex から。全体として、メディア ライブラリを約 40 TB から約 16 TB に縮小しました。これにより、時間の経過とともにサーバーが再び拡大するための十分な余裕が残されました。

AI は私のホームラボでその有用性を何度も証明しました

AI は完璧には程遠いものの、多くの点で優れていることは間違いありません。このトランスコードを実行させるのは、IT プロフェッショナルが私のオフィスに座って、睡眠や食事の休憩も取らずに 15 分ごとに監視しているようなものでした。 Codex の助けがなければ、少なくとも私がこれを達成できた時間とフラストレーションを最小限に抑えた限りでは、間違いなくこれを達成することはできませんでした。