Jellyfinはデバイス間の変更をどのように検出し、整合させるのか?

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

Jellyfinは、ライブラリーの更新を検出し、共有状態を確定し、その結果のビューをクライアントに提供する中央サーバーを通じて、ほとんどのデバイス間の変更を調整します。

通常、スマートフォン、テレビ、ブラウザー、タブレットが互いに直接メディアライブラリーの正しい状態を調整することはありません。これらは同じJellyfinサーバーと通信し、サーバーがインデックス化されたライブラリーメタデータと、視聴進捗などのユーザーごとの状態を管理します。ファイルシステムの検出、再生状況の更新、クライアントの更新はそれぞれ別の段階ですが、1台のサーバー上の権威ある状態に集約されます。そのため、サーバーが変更を受け入れ、各クライアントが更新すれば、通常はデバイス間で同じ状態になります。

共有の権威は個々のクライアントではなくサーバーにある

クライアントはライブラリーのビューを表示し、ユーザー操作を送信しますが、永続的な共有カタログはサーバー上にあります。この構成により、テレビとスマートフォンがデータベース全体をデバイス間でコピーしなくても、同じアイテムを表示できます。各クライアントは表示状態をキャッシュできますが、ライブラリーへの登録状況やユーザーの進捗について権威を持つ記録は中央に保持されます。

メディアサーバーは通常、実際に利用可能なコンテンツと、そのサーバー上のユーザーが何を再生したかについての権威です。情報源を一元化するモデルでは、再生用のメディアサーバーを、持ち運び可能なトラッキングシステムとは別のものとして扱います。同じ考え方がJellyfinクライアントにも当てはまります。クライアントはピアデバイスの中から勝者を選ぶのではなく、サーバーの状態に収束します。

このモデルでは、受け入れられた変更を永続化する場所が1つになるため、競合の管理が簡単になります。クライアントが一時的に古いキャッシュデータを表示することはありますが、まだ更新していないというだけで、同等の第2のデータベースになるわけではありません。調整とは、クライアントの表示をサーバーが受け入れた状態に戻すことです。

ファイルシステムの変更はサーバー側の検出によってライブラリー状態になる

メディアファイルの追加、置換、名前変更、削除によって最初に変わるのはストレージであり、Jellyfinのカタログではありません。サーバーはスキャン、監視トリガー、または自動化シグナルを通じてファイルシステムのイベントを検出し、影響を受けたパスを調べ、インデックス化された表現を更新する必要があります。その更新が確定して初めて、クライアントは新しいライブラリービューを受け取れます。

対象を絞ったライブラリー更新のような自動化ツールが存在するのは、広範な定期スキャンを待つよりも、検出を正確にトリガーできるためです。アーキテクチャ上の要点は変わりません。ファイルイベントは、デバイス間のUI変更になる前に、サーバー側のライブラリー更新へ変換されます。

この仕組みにより、検出中はストレージの状態とカタログの状態が分かれます。ディスク上にファイルが存在していても、クライアントにはまだ表示されないことがあります。また、削除処理が完了するまで、インデックス化されたアイテムが一時的に残ることもあります。そのため、ファイルシステムの変更からサーバーのインデックス更新までの時間と、サーバーが変更を確定した後にクライアントが更新するまでの時間は、別々に測定する必要があります。

再生進捗は同じサーバー側のユーザー状態に戻される

視聴進捗は、ファイルシステムの検出とは異なる入力経路をたどります。視聴者が40分地点に到達してもメディアファイルは変化しません。クライアントが認証済みユーザーに関連付けられた再生状態を報告し、サーバーがそのユーザー固有の更新を記録します。同じアカウントでログインしている別のデバイスは、後から共有サーバーの状態を問い合わせ、受け入れられた位置から再生を再開できます。

このため、Jellyfinではテレビとスマートフォンの間でローカルの進捗ファイルを直接コピーしなくても、視聴履歴をクライアント間で同期できます。両方のデバイスが同じサーバー上のユーザーレコードを通じて読み書きするために収束するのであり、ピアツーピアで調整するためではありません。

注目すべき境界は書き込みのタイミングです。デバイスが進捗の更新をサーバーに届ける前にオフラインになると、別のデバイスがサーバー上の古い値を表示しても不自然ではありません。接続が戻った後の最終結果は、アプリケーションがどの更新を受け入れ、どの順序で処理するかによって決まります。オフライン中のローカル進捗を、すでに確定した共有状態と混同してはいけません。

クライアントは互いにマージするのではなく、サーバーから更新して調整する

サーバーが変更を確定した後も、クライアントは新しい状態を取得する更新、イベント、画面遷移、または後続のリクエストを必要とします。テレビが古いポスター一覧をメモリ上に保持している間に、ブラウザーではすでに更新が表示されることがあります。この一時的な不一致は、サーバー自体に競合する記録がない限り、表示キャッシュの問題です。

クライアントの多様性によって、この違いが明確になります。さまざまなJellyfinクライアントが、異なるインターフェースや再生動作で同じサーバーを表示できるためです。1つのクライアントだけが古い状態に見え、別のクライアントが最新状態なら、まずサーバーの状態を確認し、その後、古いクライアントを更新または再接続してから、食い違いをデータベース競合として扱ってください。

この区別はデバッグ時に重要です。2つのクライアントが異なる表示をする場合は、まずサーバーの状態を問い合わせるか確認します。サーバーに期待どおりの値があり、1つのクライアントだけが古い場合は、更新またはキャッシュの挙動が原因である可能性が高いでしょう。サーバー自体に更新がない場合は、2台目のクライアントを疑う前に、検出、権限、または書き込みイベントを調べます。

障害の境界:別々のサーバーはデータベースを自動的には調整しない

中央権威モデルが適用されるのは、1つのJellyfinサーバーインスタンス内です。家庭内で独立した2台のサーバーを運用すると、それぞれが独自のユーザー、視聴状態、メタデータ編集、ライブラリーデータベースの変更を蓄積できます。似たメディアファイルを参照しているというだけで、それらのデータベースが互いを検出し、安全にマージするとは限りません。

明示的な視聴状態の同期のようなサーバー間ツールが存在するのは、独立したメディアサーバー間で共有進捗を調整するために、明示的な仕組みが必要だからです。このようなツールは定義された一部の状態を同期できますが、2つの完全なJellyfinデータベースを透過的なマルチマスタークラスターに変えるものではありません。

同じ境界はオフラインデバイスにも当てはまります。クライアントが古いローカルビューを保持することはありますが、それをJellyfinに手動でマージする権威あるデータベースとして扱うべきではありません。複数の書き込み元やサーバーを導入する場合は、その設計を「調整済み」と呼ぶ前に、どの状態を権威とするのか、どのフィールドを同期するのか、競合する更新をどう解決するのかを定義してください。

2台のデバイスで4段階の調整テストを実行する

同じテストユーザーでログインした2つのクライアントと、既知のメディアアイテムを1つ用意します。まずテストファイルを追加または名前変更し、サーバーが検出するまでの時間を測定します。次に、更新後の両方のクライアントが新しいカタログ状態を受け取ることを確認します。3番目に、クライアントAで視聴進捗を変更し、クライアントBがサーバーに受け入れられた値を受け取ることを確認します。4番目に、サーバーを再起動し、確定した状態が保持されることを確認します。

同時状態の整合性に関する内部的な説明は、補完的なデータベース境界を示しています。重複する処理によって途中までの更新が見えないようにするには、受け入れられた書き込みにトランザクションと順序付けのルールが必要です。デバイス間テストでは、こうした永続状態の保証に加えて、検出とクライアント更新のタイミングも検証します。

各段階の後にサーバーが同じ観測可能な権威となって初めて合格です。つまり、ストレージの変更が一度だけインデックス化され、両方のクライアントが同じライブラリー結果に収束し、ユーザーの進捗が重複したり失われたりせず、再起動しても確定済みの更新が元に戻らないことを確認します。不一致が残る場合は、問題が検出、サーバーでの確定、クライアントの更新、別サーバー間の境界のどこで発生したのかを特定してください。

よくある質問

Jellyfinクライアントは互いに直接同期しますか?

通常はしません。スマートフォン、テレビ、ブラウザー、タブレットはJellyfinサーバーを通じて収束します。クライアントが更新をサーバーに送り、その後サーバーの状態を読み取る仕組みです。クライアントをピアレプリカとして扱うと、実際には存在しない競合が、通常の更新遅延によって起きているように見えてしまいます。

Jellyfinの1つのクライアントだけが古いライブラリーデータを表示するのはなぜですか?

サーバーがライブラリーや再生の変更をすでに確定していても、1つのクライアントが古いキャッシュビューを表示し続けることがあります。別のクライアントまたはWebインターフェースからサーバー側の状態を確認し、その後、古いクライアントを更新または再接続してから、検出やデータベースの問題を調査してください。

別々のJellyfinサーバー間で視聴進捗を自動的に同期できますか?

別々のJellyfinサーバーが自動的にマルチマスターの状態システムを構成することはありません。同じユーザーが独立したサーバー間で視聴履歴を引き継ぐ必要がある場合は、明確な情報源を定めた明示的な同期ワークフローを使用し、依存する前に競合時の動作をテストしてください。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.