アプリデータをいっぱいにせずライブTV録画の保存先を設定する方法

ライブTV録画は大容量で長期保存されるメディアファイルですが、アプリケーションデータはサーバーの起動と管理に必要な、小容量で遅延の影響を受けやすい状態データです。両方を同じコンテナボリュームに保存すると、1つの録画だけでデータベース、ログ、アップグレードに必要な容量を使い果たす可能性があります。

安全な構成では、録画専用のホストデータセットまたは共有を用意してコンテナにマウントし、DVR設定でコンテナ内のパスを指定します。トランスコード用の一時領域は3つ目のデータクラスであり、設定ボリュームに暗黙的にフォールバックしないようにしてください。

3つのストレージの役割を分離する

永続的な設定パス、録画ライブラリ、トランスコードまたはタイムシフト用のワークスペースを特定します。ホスト側のパスとコンテナ側のパスを小さな対応表に記録してください。コンテナから保存先が見えない場合、ダッシュボードのフィールドだけを変更しても不十分です。

設定は、通常のバックアップ対象となる信頼性の高いストレージに保存します。録画は想定される書き込み速度に対応できる容量重視のストレージに保存し、一時的なトランスコードデータはデータベースの容量を圧迫しない場所に配置します。

平均的なエピソードではなく、最悪の場合の録画容量を見積もります。チューナーのストリームビットレートに最長の予約時間を掛け、同時録画分を加算し、ファイルシステムとアプリケーションの動作に必要な運用上の空き容量も確保します。

録画専用の保存先をマウントする

/srv/media/recordings のようなホストディレクトリまたはデータセットを作成し、/recordings のような分かりやすいパスにコンテナへマウントします。コンテナを再作成しても保持されるバインドマウントまたは管理ボリュームを使用してください。

所有者とアクセス権を、Jellyfinプロセスが使用するUIDとGIDに合わせます。見えるものの書き込めない保存先では、権限エラーが発生することが多く、運用担当者がデフォルトのアプリデータパスに戻したくなる場合があります。

録画パスの権限エラーに関するコミュニティの報告は、見えるだけでは十分なテストにならない理由を示しています。実際の番組を予約する前に、コンテナユーザーとして小さなファイルを作成し、削除してください。

DVRと一時領域のパスを適切なボリュームに指定する

ライブTVまたはDVRの設定で、録画パスにはホスト側のパスではなく、コンテナから見える録画マウントのパスを指定します。インストールしているバージョンで映画とシリーズの保存先を分けられる場合でも、分割する理由がない限り、両方を同じ容量管理対象の録画データセット内に保持します。

トランスコードパスには、短期的なデータ量に十分対応できる専用の一時マウントを指定します。録画をトランスコードディレクトリに保存しないでください。一時データは積極的に削除できますが、完成した録画はユーザーデータです。

ポストプロセスを使用する場合、Jellyfinのポストプロセスの動作では、完成した録画のパスがスクリプトに渡されます。スクリプトから同じマウントパスが見えることを確認し、誤ってアプリケーションボリュームにファイルを移動できないようにしてください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

障害状態をテストし、容量のガードレールを追加する

短い手動録画を開始し、録画データセット上でサイズが増加することを確認してから停止し、結果を再生します。コンテナを再起動して再度再生し、マウントが匿名のコンテナレイヤーではなく永続的なものであることを確認します。

録画データセットとアプリデータボリュームの両方について、空きバイト数または使用率に対するアラートを設定します。保持ルールは役立ちますが、クリーンアップの失敗、重複した予約、想定外に長いイベントによって見積もりを超える可能性があるため、アラートの代わりにはなりません。

小容量の設定ボリュームは、大容量の録画とは別にバックアップします。Jellyfinの廃止チェックリストには、必須の状態データと交換可能なメディアサーバーコンポーネントを区別するための、役立つ棚卸しモデルが示されています。