複数ユーザー向けホームストリーミング用にJellyfinをセットアップする方法

複数人で使うJellyfinでは、まず安定してダイレクトプレイできる構成を整え、そのうえで、例外に対応できるだけのトランスコード、ネットワーク、ストレージ、復旧能力を追加しましょう。

複数人で使う家庭では、複数の経路に同時に負荷がかかります。あるテレビでは4Kファイルをダイレクトプレイしながら、ブラウザーでは動画の変換が必要になり、別のユーザーがライブラリを検索し、バックアップがバックグラウンドで始まることもあります。計算処理、メディアストレージ、Jellyfinのアプリデータ、ネットワークアクセス、バックアップをそれぞれ独立した役割として扱い、どこか1つの経路の過負荷が気づかないうちに全員の制限にならないようにしましょう。

サーバーの仕様表ではなく、クライアントから考える

実際にメディアを再生するデバイスをリストアップしましょう。テレビ、ストリーミングボックス、ブラウザー、スマートフォン、タブレット、リモートクライアントなどです。代表的な動画コーデック、音声形式、字幕の種類、HDRの使用状況、通常のビットレートを記録します。これにより、漠然とした「3ユーザー」ではなく、具体的な再生経路を把握できます。

Jellyfinは、クライアントの機能とストリームの制約に応じて、ダイレクトプレイ、リマックス、トランスコードのいずれにするかを判断します。公式のトランスコードのドキュメントによると、クライアントは対応機能のプロファイルを送信し、サーバーはそれに適合する出力を選択します。そのため、異なるファイルを視聴する2人のユーザーが、サーバーにまったく異なる負荷をかけることがあります。

まず一般的な使い方を基準に設計しましょう。リビングの主なデバイスでライブラリをダイレクトプレイできるなら、すべてのストリームでソフトウェアによる動画エンコードが必要になると想定してサーバー全体の性能を決める必要はありません。代わりに、非対応の動画形式、音声変換、字幕の焼き込み、ビットレート制限、リモート接続時の帯域幅など、変換が必要になる繰り返し発生する条件を特定しましょう。

Jellyfinのアプリデータは高速ストレージに、メディアは大容量ストレージに保存

Jellyfinのアクティブなデータ経路を、大容量メディア用の経路から分けましょう。データベース、メタデータ、インデックス、キャッシュ、トランスコード用の作業領域では小さな読み書きが頻繁に発生しますが、映画やエピソードのファイルは主に大きなデータをシーケンシャルに読み込みます。

Jellyfinのハードウェア選定ガイドでは、Jellyfinのファイルはランダムアクセスが多いためSSDストレージを推奨しています。一方、メディアの保存には、メディアのビットレートを上回るシーケンシャルスループットがあれば十分です。そのため、すべてを1台の大容量ディスクに置くよりも、アプリデータ用のSSDとメディア用のHDDまたはNAS容量を組み合わせるほうが実用的です。

高速ストレージ層には、インポート、生成画像、一時的なトランスコード用セグメントのための空き容量を十分に確保してください。アプリデータ用ボリュームが満杯になると、メディア用プールに大きな空きがあっても役に立ちません。詰まっているのは動画ファイル側ではなく、データベースやキャッシュ側の経路だからです。

家庭内ネットワークへの安定した有線経路をサーバーに1つ確保する

Jellyfinホストはイーサネットで接続し、Wi-Fiはサーバーの主要な上り回線ではなく、クライアント側の利便性のためのものと考えてください。個々のクライアントが複数の無線アクセスポイントに分散していても、複数のユーザーの通信はサーバーに集中します。

Jellyfinの最新のネットワーク設定ガイドでは、サーバーにはイーサネットを推奨しており、ローカルデバイス検出はサブネット内に限られると説明しています。VLAN、ゲストネットワーク、または複数のサブネットを使用する場合は、ブロードキャストによる検出が境界を越えると想定せず、明示的なルーティングと名前解決を計画してください。

実際に負荷が高まる時間帯に、2～3本の同時ストリーミング、ライブラリの閲覧、ファイル転送またはバックアップを組み合わせて経路を検証してください。ストレージ通信が発生したときだけ再生が不安定になる場合、必要なのは高性能なCPUではなく、通信経路の配置、回線容量、またはスケジュールの見直しかもしれません。

Featured

ZimaCube 2 パーソナルクラウド ホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

トランスコードは独立した容量を確保すべき例外的な処理として扱う

クライアントがソースをそのまま再生できない場合、動画のトランスコードが主要な計算処理になることがあります。ハードウェアアクセラレーションを使うと、対応するデコード、処理、エンコードの各段階を専用のメディア処理ハードウェアに任せられますが、対応していない段階は引き続きCPUにフォールバックする場合があります。

Jellyfinでは、Intel QSV、NVIDIA NVENC、AMD AMF/VA-API、Apple VideoToolbox、Rockchip RKMPPなどのアクセラレーション方式がサポートされています。ハードウェアアクセラレーションガイドでは、一部の処理だけがアクセラレーションされるとCPU負荷が高いままになる場合があるとも説明されています。そのため、「GPU有効」はストリーム全体がアクセラレーションされている証拠にはなりません。

難しいクライアントの種類ごとに、代表的なトランスコードを1つ強制実行し、ストリームの詳細とホストの動作状況を確認してください。ZimaSpaceのハードウェアトランスコード検証ワークフローでは、設定スイッチだけを信用せず、ダッシュボード、GPUの動作状況、FFmpegの証拠をひとつのテストとして確認するため、役立ちます。

世帯内のユーザー識別、リモートアクセス、管理者権限を分ける

視聴状況、保護者による制限、リモートアクセス、ライブラリの表示範囲を世帯のメンバーごとに変える必要がある場合は、それぞれに個別のJellyfinユーザーを作成しましょう。認証情報を共有すると便利な分離が失われ、ほかの全員に影響を与えずに特定の人の権限だけを変更することも難しくなります。

リモートアクセスでは、意図して管理する経路だけを公開してください。Jellyfinのネットワーク関連ドキュメントでは、インターネットへの直接公開を避け、リバースプロキシやVPNなどのより安全な方法を推奨しています。特にサーバーでほかのホームサービスも運用している場合は、管理者アクセスの範囲を通常の再生アクセスより狭く保ちましょう。

ユーザーの識別ルールを設定したら、通常のローカルユーザー、アクセス制限付きユーザー、リモートユーザーをそれぞれ別にテストしましょう。管理者が快適にストリーミングできても、別のプロフィールに誤ったライブラリが表示されたり、想定したネットワークから認証できなかったりするなら、世帯で共有する環境として検証は完了していません。

バックアップ、復旧、拡張の判断基準を整えて構築を完了する

Jellyfinの状態は、メディアライブラリとは分けてバックアップしましょう。メディアは再取得したり、別のスケジュールで復元したりできることが多い一方、ユーザー、視聴状況、メタデータの選択、字幕、サーバー設定は、すぐに復旧したい運用上重要なデータかもしれません。

組み込みのJellyfinバックアップシステムでは、データベース、メタデータ、字幕、トリックプレイデータをバックアップ対象にできます。同じアプリデータボリュームと一緒に失われない保存先にバックアップを保管し、セットアップ完了とみなす前に復元テストを行ってください。

測定によって制限が繰り返し確認された場合に限り拡張しましょう。たとえば、トランスコードが継続的に飽和している、アプリデータの応答が遅い、実用容量が不足している、バックアップ中に視聴と競合する、ネットワーク経路が上限に達している場合です。通常のクライアントでDirect Playがスムーズに再生され、アプリデータの応答性が保たれ、復元テストも済んでいるなら、ハードウェアの追加は必須ではなく任意です。