複数ユーザーで自宅ストリーミングを利用するためのJellyfinの設定方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Set Up Jellyfin for Multi-User Home Streaming - Zima Store Online

複数ユーザーでJellyfinを利用する場合は、まず安定したダイレクトプレイを中心に構成し、例外に対応できるだけのトランスコード、ネットワーク、ストレージ、復旧容量を追加します。

共有家庭環境では、複数の経路に同時に負荷がかかります。あるテレビでは4Kファイルをダイレクトプレイしている一方で、ブラウザーでは動画変換が必要になり、別のユーザーがライブラリを検索し、バックグラウンドでバックアップが開始されることもあります。コンピュート、メディアストレージ、Jellyfinのアプリデータ、ネットワークアクセス、バックアップを別々の役割として扱い、1つの混雑した経路が全員の制限要因にひそかにならないようにしましょう。

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

実際にメディアを再生するデバイスを一覧にします。テレビ、ストリーミングボックス、ブラウザー、スマートフォン、タブレット、リモートクライアントなどです。代表的な動画コーデック、音声形式、字幕の種類、HDRの利用状況、通常のビットレートを記録します。これにより、「3ユーザー」という数字を、恣意的な同時接続数ではなく、複数の再生経路として捉えられます。

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

まずは一般的な利用状況を基準に設計します。リビングの主要デバイスがライブラリをダイレクトプレイできるなら、すべてのストリームでソフトウェア動画エンコードが必要になる前提でサーバー全体を設計する必要はありません。代わりに、変換を引き起こす再現性の高い条件、たとえば非対応の動画、音声変換、字幕の焼き付け、ビットレート制限、リモート接続時の帯域幅などを特定します。

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

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

Jellyfinのハードウェア選定ガイドでは、Jellyfinのファイルはランダムアクセスが多いためSSDを推奨しています。一方、メディアストレージに必要なのは、メディアのビットレートを上回るシーケンシャルスループットだけです。そのため、アプリデータをSSDに置き、メディアをHDDまたはNASの大容量ストレージに置く分離のほうが、すべてを1台の大容量ディスクに置くより実用的です。

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

家庭内ネットワークへの信頼できる有線経路をサーバーに1本確保する

Jellyfinホストはイーサネットで接続し、Wi-Fiはサーバーの主要アップリンクではなく、クライアント側の利便性として扱います。個々のクライアントが複数の無線アクセスポイントに分散していても、複数ユーザーのトラフィックはサーバーに集中します。

現在のJellyfinネットワークガイダンスでは、サーバーにイーサネットを使用することを推奨し、ローカル検出がサブネット単位で行われることを説明しています。VLAN、ゲストネットワーク、複数のサブネットを使用する場合は、検出用ブロードキャストが境界を越えると想定せず、明示的なルーティングと名前解決を計画してください。

現実的な混雑時間帯に、2～3本の同時ストリーム、ライブラリの閲覧、ファイル転送またはバックアップを組み合わせて経路を検証します。ストレージトラフィックがアクティブなときだけ再生が劣化するなら、次に必要なのは高速なCPUではなく、トラフィックの配置、リンク容量、スケジュールの見直しかもしれません。

Featured

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

ZimaCube2

トランスコードは専用容量を持つ例外経路として扱う

クライアントがソースを直接再生できない場合、動画トランスコードが最大のコンピュート処理になることがあります。ハードウェアアクセラレーションを利用すると、対応するデコード、処理、エンコードの各段階を固定機能のメディアハードウェアに移せますが、非対応の段階はCPUにフォールバックする可能性があります。

Jellyfinでは、対応するアクセラレーション方式としてIntel QSV、NVIDIA NVENC、AMD AMF/VA-API、Apple VideoToolbox、Rockchip RKMPPなどをドキュメント化しています。ハードウェアアクセラレーションガイドでは、部分的なアクセラレーションではCPU負荷が高いままになる可能性も説明されています。したがって、「GPU有効」と表示されることは、ストリーム全体がアクセラレーションされている証明にはなりません。

難しいクライアントの種類ごとに代表的なトランスコードを1つ強制し、ストリームの詳細とホストの動作状況を確認します。ZimaSpaceのハードウェアトランスコードの検証手順は、ダッシュボード、GPUの動作状況、FFmpegの証拠を1つのテストとして扱うため、単に設定の切り替えを信頼するよりも有用です。

家庭内のユーザー、リモートアクセス、管理者権限を分離する

視聴履歴、ペアレンタル制限、リモートアクセス、ライブラリの公開範囲を分ける必要がある場合は、家庭内のメンバーごとにJellyfinユーザーを作成します。認証情報を共有すると、有用な分離が失われ、全員に影響を与えずに1人だけの権限を変更することが難しくなります。

リモート利用では、意図的に管理するアクセス経路だけを公開します。Jellyfinのネットワークドキュメントでは、インターネットへの直接公開を避けるよう警告し、リバースプロキシやVPNなど、より安全な方式を案内しています。特にサーバー上で他の家庭向けサービスも稼働している場合は、管理者アクセスを通常の再生アクセスよりも厳しく制限してください。

ユーザー設定を整えたら、通常のローカルユーザー、制限付きユーザー、リモートユーザーをそれぞれ個別にテストします。管理者として問題なくストリーミングできても、別のプロフィールで誤ったライブラリが表示されたり、想定したネットワークから認証できなかったりするなら、共有家庭環境としてはまだ検証済みとはいえません。

バックアップ、復旧、拡張の判断基準で構成を完成させる

Jellyfinの状態は、メディアライブラリとは別にバックアップします。メディアは別のスケジュールで再取得または復元できることが多い一方、ユーザー、視聴履歴、メタデータの設定、字幕、サーバー設定は、運用上すぐに復元したい状態である可能性があります。

組み込みのJellyfinバックアップシステムには、データベース、メタデータ、字幕、トリックプレイデータを含めることができます。バックアップは同じアプリデータボリュームと一緒に失われない保存先に置き、構成が完成したと判断する前に復元テストを実施してください。

拡張は、繰り返し発生する制限を測定で特定できた場合にだけ行います。たとえば、トランスコードの継続的な飽和、アプリデータの遅延、利用可能容量の不足、視聴時間とバックアップ時間の衝突、ネットワーク経路の上限到達などです。通常のクライアントがスムーズにダイレクトプレイでき、アプリデータが快適に動作し、復旧テストも済んでいるなら、追加ハードウェアは必須ではなく選択肢です。