ライブラリのメンテナンス中にメディアメタデータの書き換えを防ぐ方法

エヴァ・ウォン

IceWhale author

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

How to Avoid Media Metadata Rewrites During Library Maintenance - Zima Store Online

ライブラリ全体のメンテナンスを始める前に、厳選したフィールドやアートワークを永続的なソースで保護しておくと、メディアメタデータの書き換えを最も簡単に防げます。

スキャン、プロバイダー情報の更新、データベースのクリーンアップ、パスの移動、サーバーのアップグレードでは、メディアライブラリ内のまったく異なる層に変更が加わることがあります。メンテナンス前に、どのタイトル、ポスター、コレクション、NFOファイル、手動編集フィールドが正しい情報源なのかを確認してください。サーバーが対応している項目はロックし、ローカルのサイドカーとアートワークをバックアップし、まずテスト用の1項目で最も破壊的でない更新モードを実行します。メンテナンス作業がライブラリ全体に関係するというだけで、「すべてのメタデータを置き換える」を選択しないでください。

メンテナンス前に厳選したメタデータを一覧化する

代表的な映画やエピソードをいくつか選び、カスタムタイトル、並べ替え名、プロバイダーID、コレクション、ポスター、背景、エディション、手動で修正した説明を記録します。それぞれの値がデータベースにしか存在しないのか、それともローカルのNFOファイルやアートワークファイルにも存在するのかを確認してください。

最新のJellyfinメタデータガイドでは、広範囲にわたるメタデータ作業の前に、厳選したフィールドをロックすることを推奨しています。

どの値が意図的なものか特定できない場合は、すべてを置き換える更新を開始しないでください。まず小規模な監査対象をエクスポートするかスクリーンショットを撮り、望ましくない書き換えを数週間後に気づくのではなく、すぐに検出できるようにします。

NFOファイルとローカルアートワークを永続的なソースとしてバックアップする

ライブラリでローカルのNFOファイル、ポスター、背景を正しいメタデータのソースとして使用している場合は、それらをメディアと一緒にコピーするか、メンテナンス用バックアップに含めます。いくつかのサンプルでタイムスタンプとチェックサムを確認してください。

Jellyfinは、ローカルメタデータとしてNFOファイルをサポートしており、NFOセーバーを有効にするとメタデータをこれらのファイルに保存できます。

データベースのバックアップだけで、手動管理しているすべてのサイドカーが保存されるとは限りません。逆に、ライブラリで編集内容をサーバーのデータベース内にしか保存したことがない場合は、NFOが正しい情報源だとも限りません。

ポスターの安定性が重要な場合はローカルアートワークを優先する

プロバイダーの変更後も維持したいポスターや背景については、メディアサーバーがサポートするローカル命名規則で選択した画像を保存し、メディアライブラリと一緒にバックアップします。

Plexopediaでは、ローカルポスターはプロバイダーの変更に強いことを説明しています。アートワークを永続的なローカルアセットとして保持できるためです。

ライブラリ全体にこの命名規則を適用する前に、1つのタイトルでテストしてください。ローカルアートワークによって再現性は高まりますが、バックアップ、同期、権限のポリシーで保持すべきファイルも作成されます。

Featured

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

ZimaCube2

最も破壊的でない更新モードを使用する

通常のライブラリスキャン、メタデータ更新、すべてのメタデータを置き換える操作、既存画像を置き換えるオプションを区別してください。ストレージパスやデータベースインデックスだけを変更するメンテナンスであれば、通常、すべてのフィールドや画像を置き換える必要はありません。

Embyのトラブルシューティング事例では、手動更新中にすべてを置き換える操作でアートワークが上書きされる可能性が示されています。

目的を達成できる場合は、まず「新規または更新されたファイルをスキャン」など、プラットフォームにある同等の限定的な操作を使用します。メタデータを意図的に再構築する項目に限って、破壊的な更新へ進んでください。

メディアフォルダーに書き戻す前に正しい情報源を確認する

複数のアプリケーションで同じメディアツリーを共有している場合は、NFOファイル、アートワーク、タグの書き込みを許可するアプリケーションを決めてください。2つのサーバーが同じサイドカーに書き込むと、通常のメンテナンスがアプリケーション間のメタデータ競合につながる可能性があります。

Firecoreのメタデータガイドでは、アートワークを意図的に上書きできることが説明されています。

可能であれば、共有サイドカーの書き込み担当を1つの永続的なライターに限定するか、ファイルを読み取るだけのアプリケーションではメディアマウントを読み取り専用にします。目的は、メタデータを書き込むアプリケーションの数を最大化することではなく、正しい情報源を明確にすることです。

まず小規模なテストライブラリでメンテナンスを実行する

一時的なライブラリを作成するか、カスタムアートワーク、ローカルNFOファイル、コレクション、編集済みタイトル、通常の未編集項目を含む小さなフォルダーを選びます。計画しているメンテナンス操作とまったく同じものを、まずそこで実行してください。

Plexでは、ローカルアセットが命名規則に従うことが文書化されているため、テストライブラリで、メンテナンス後も永続的なローカルアセットが読み込まれることを確認できます。

スキャン、更新、パス変更、アップグレードの前後で、テスト項目を比較します。厳選したフィールドが安定しており、意図したプロバイダー更新が引き続き機能する場合にのみ、そのメンテナンスポリシーは安全です。厳選したアートワークがすでに変更されている場合は、更新後にカスタムポスターが元に戻る場合に関するZimaSpaceの関連記事が復旧の手がかりになります。