メディアサーバーが移行したライブラリをスキャンする前に、古いパスと新しいパスが相互に重複しないようにして、映画の重複登録を防ぎましょう。
ストレージの移行では、2つのバインドマウント、2つのライブラリルート、一時コピー、または古いパスを削除した後も残るデータベースの古いレコードによって、同じ映画が2つの場所から参照されることがあります。最も安全な手順は、自動スキャンを停止し、アプリケーションデータベースをバックアップし、古いパスと新しいパスを正確に対応付け、管理された時間帯にメディアを移動またはコピーし、ライブラリから不要になったソースを削除してから、サーバーが正規の場所を1つだけ認識できる状態で、意図的に1回だけ再スキャンすることです。
同じ映画に到達できるすべてのパスを確認する
ライブラリルート、Dockerのバインドマウント、シンボリックリンク、mergerファイルシステム、ネットワークマウント、一時的な移行フォルダーを一覧にします。ホストとコンテナの両方から、1本の映画が実際にどのパスにあるかを確認してください。
スキャナーが同じファイルを新しいパスとして受け取る一方で、古いデータベース項目が有効なまま残ると、重複が発生しやすくなります。Jellyfinの移行レポートでは、ライブラリフォルダーの移動によって重複が作成された事例で、この問題が再現されています。
たとえば /media/movies のように、正規のコンテナパスを1つ選び、ホスト側のストレージソースが変わってもそのパスを固定します。コンテナパスを安定させると、プールやドライブを移行するたびにアプリケーションが新しい場所を学習する必要がなくなり、今後のデータベースの変更を抑えられます。
メディアのコピーや名前変更の前に自動スキャンを停止する
移行中は、リアルタイム監視とスケジュールされたライブラリスキャンを無効にします。無効にしないと、サーバーが不完全なコピーをインデックス化したり、両方の場所を認識したり、フォルダー名を段階的に変更している間に同じタイトルを記録したりする可能性があります。
パスを変更する前に、メディアサーバーの設定とデータベースをバックアップします。これにより、視聴済み状態、アートワークの選択、コレクション、ユーザー、プロバイダー識別子を保護できます。クリーンなライブラリを再構築しても、これらが完全に同じ状態で復元されるとは限りません。
まず小さなテストフォルダーを1つだけコピーまたは移動し、チェックサムまたはファイルサイズを確認します。新しい場所をサービスアカウントが読み取れるようになるまで、古いソースは変更せずに残してください。この確認期間中に、両方のパスをアクティブなライブラリルートにしないでください。
新しいパスをスキャンする前に古いライブラリパスを削除する
新しいパスを確認できたら、ライブラリ設定から不要になったフォルダーを削除するか、既存のコンテナパスを新しいホスト側ソースに再マッピングします。別のライブラリやシンボリックリンクを経由して古いパスにアクセスできないことを確認してください。
パスを削除しても、関連するすべてのレコードが直ちに削除されるとは限りません。Jellyfinの課題では、削除したパスに関連付けられたメタデータが残った事例が報告されています。そのため、パスのクリーンアップは想定で済ませず、実際に確認する必要があります。
古いソースにアクセスできなくなってから、アプリケーションがサポートするライブラリのクリーンアップまたは完全スキャンを実行します。十分にテストしたバックアップと、バージョンに応じた復旧計画がない限り、データベースを手動で編集しないでください。
ファイルの移動中もメディアの識別情報を維持する
映画のフォルダー名、ファイル名、年の表記、エディションラベル、プロバイダーID、ローカルメタデータファイルの内容を一貫させます。同じ移行中にタイトルまで変更すると、動画データが同じでも別の項目として扱われる可能性があります。
ローカルメタデータとアートワークは意図的に保存してください。TMDBやIMDbのIDなどの識別子が名前やNFOファイルに埋め込まれている場合は、それらを維持します。そうすれば、新しいパスでも別の曖昧な候補ではなく、同じ映画として認識されます。
ZimaSpaceのNASデータ移行ワークフローでは、古いコピーを削除する前にソースデータを保護し、権限を確認するための関連手順を説明しています。
2つのパスと、2つのバージョンまたはエディションを区別する
重複している両方の項目を開き、ファイルパス、メディア情報、プロバイダーID、再生時間、エディションタグ、利用可能性を比較します。2つの項目が、2つのパスを通じた同じファイル、2つの物理コピー、または誤ってグループ化された正当なバージョンである可能性があります。
パスが消えた後も、古いレコードが引き続きアクセス可能な場合があります。Jellyfinのレポートでは、こうした項目をゴースト項目と呼んでいます。これは、実在する2つ目の映画ファイルと混同しないでください。
両方の項目が有効なパスを指している場合は、意図しないパスをライブラリの対象範囲から削除します。一方のパスが存在しない場合は、サポートされているクリーンアップ処理を使用し、レコードが消えることを確認します。ファイルが意図的なエディションである場合は、片方を無条件に削除せず、メディアサーバーがサポートする命名規則とグループ化ルールを使用してください。
| 重複パターン | 考えられる原因 | 正しい対処 |
|---|---|---|
| 2つの項目、2つの有効なパス | 古いルートと新しいルートの両方をスキャンした | 正規パスを1つにする |
| 2つの項目、1つの無効なパス | データベースの古いレコード | バックアップ後にライブラリをクリーンアップする |
| 2つのファイル、同じタイトル | 移行時のコピーが残っている | 確認して古いコピーを廃止する |
| 2つの意図的なエディション | 命名またはグループ化の不一致 | サポートされているエディション命名を使用する |
この分類により、データベースのクリーンアップで正当な別カットや高品質版まで削除してしまうのを防げます。
管理された再スキャンを1回実行し、状態を確認する
正規パスがマウントされ、古いパスがなくなり、サービスユーザーが新しい場所を読み取れることを確認してから、スキャンを再び有効にします。完全スキャンを1回だけ開始し、移行した映画について削除イベントと追加イベントが発生するかを確認します。
設定から古いパスを削除した後も、ストレージ移行によってファイルが削除されないライブラリがあります。Jellyfinのレポートでは、削除したファイルがライブラリに残った事例が記録されています。そのため、最終確認ではデータベースの項目と実際のパスを照合する必要があります。
各映画が1回だけ表示され、新しいパスから開け、視聴済み状態とコレクションが維持され、サービスの再起動後も状態が変わらないことを確認します。この監査に合格するまで、古いストレージはオフラインにしたまま intact に保管し、その後、バックアップおよび移行計画に従って廃止してください。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

