使い方

インストールと設定の後に使う日常フローです。

セットアップと最初の同期

/setup は言語、サーバー、TMDB、プロバイダー、ライブラリ、最初の同期を順に案内します。Plex は PIN／検出、Jellyfin／Emby はユーザー名／パスワードまたはキーに対応します。各ステップはサーバー成功後だけ進みます。スキップはウィザードを終了し、最初の同期は終了状態まで追跡して、失敗時は詳細と再試行を表示します。

同期と完全再スキャン

ダッシュボードの同期は、アクティブな名前付きサーバーから映画／番組を取り込み、TMDB ID とメタデータを更新します。INCLUDED_SECTIONS またはライブラリ選択で範囲を限定します。GUID がない項目も未解決として残ります。

通常同期は既定で増分で、前回の同期以降に変わった項目だけを解決し直します。ただし 1 種類だけ意図的にこのスキップから外れます。保存済みの TMDB 識別がメディアサーバー自身の映画／番組の種別と矛盾する項目は毎回処理し直されるため、古い不一致が増分同期をいつまでもすり抜けることはありません（TMDB 一致の修正を参照）。完全再スキャンはすべてを読み直し、削除項目と外部アートワーク変更を照合しますが、スナップショット／履歴を消したり自動適用したりしません。

ジョブは待機、フェーズ、進捗、試行、結果をライブ表示します。ページ更新ではキャンセルされず、同一要求はアクティブジョブを再利用します。

大規模ライブラリ操作

Library はサーバー側で種類、ライブラリ、有効／無視、ポスター不足、全候補、MediUX 候補、変更、評価、ジャンルを検索・絞り込みます。タイトル、年、評価、上映時間、最近の変更、追加日で並べ替え、項目を開いて戻っても URL の条件を保持します。

これとは別にアートワークの適用状況のフィルターがあります——このサーバーに適用済み、Kometa にエクスポート済み、アートワークが必要、適用状況は不明。Review も同じコントロールを持ち、値の意味も両方で同一なのでリンクをそのまま渡せます。頼りにする前にアートワークの適用状況を読んでください。これらは PosterPilot が何をしたかについての主張であって、タイトルにポスターがあるかどうかについてのものではありません。

一括操作はページを選択またはすべての結果を選択し、読込数と総数を確認します。全結果は正確なフィルターからサーバーで確定し、検索条件を変えると選択は無効になります。

Review インボックス

Review は新規、未解決、候補なし、候補あり、ステージ済み、部分失敗、外部変更、無視、完了に整理します。フィルター／並べ替えを保存でき、項目の前／次／戻るはコンテキストを保ちます。状態フィルターの隣にはアートワークの適用状況のフィルターが並び、答える問いが違います。「状態」はあなたがワークフローのどこにいるか、「適用状況」は宛先で実際に何が起きたかです。

各スロットで現在、候補、ステージ済みを比較します。候補の採用は明示操作で、ページを開くだけでは保存しません。キーボードショートカットは入力欄やモーダル中に発火しません。

適用して次へは通常のプレビュー／確認を使い、ジョブと書き込み後検証を待ち、すべての選択宛先が成功した場合だけ進みます。失敗、スキップ、部分結果なら現在の項目に詳細と再試行を残します。

TMDB 一致の修正

下流のすべて——どのアートワークを探すか、どの Kometa エントリーを書くか、同じタイトルの 2 つのコピーを同一と認識できるか——は、PosterPilot がその項目に解決した TMDB 識別に懸かっています。

TMDB は映画と番組に別々の番号を振ります。映画の 105 と番組の 105 は無関係な 2 作品です。メディアサーバーはどちらであるかをすでに知っているので、PosterPilot はそれを正とし、その名前空間の中だけで解決します。項目が持つ GUID は固定の優先順で試されます。まず TMDB ID、次に IMDb、最後に TVDB です。直接指定された TMDB ID は該当エンドポイントから読み戻して検証され（番組は TV として、映画は映画として照会）、もう一方の名前空間にしか存在しない ID は解決しません。IMDb や TVDB の ID は TMDB の find エンドポイントを通し、一致する結果バケットだけを受け入れます。別のバケットのヒットは借用せず破棄します。その結果、番組ライブラリが映画に解決することはなくなりました。TMDB が「この名前空間にはない」と答えた項目は未解決のまま残ります。これはネットワークや資格情報の失敗とは別の結果です。後者は項目を未解決かつ未同期のままにするので、次の同期は誤った答えを受け入れる代わりに再試行します。

正規化バナー

この名前空間ガード以前のリリースは種別の誤った TMDB 識別を保存できてしまい、リゾルバーを直してもデータベースにすでにある行が遡って直るわけではありません。そこでアップグレード後、PosterPilot はそれらを数え、全ページ上部のバナーで「以前の TMDB 一致 N 件を正規化する必要があります。」と伝えます。バナーには一致を正規化の操作と、対象を限定した修復で完全再スキャンやアートワーク適用をせずに映画・番組の識別を修正する、という注記が付きます。

数える範囲は意図的に狭くしてあります。アクティブなサーバー上にあり、保存済みの TMDB メディア種別がメディアサーバー自身の種別と矛盾する項目だけです。手動で固定した項目は含みません——固定は識別についてのあなたの表明であり、どんな自動修復よりも優先されます。すでにライブラリから消えたコピーも含みません。この数値は表示のたびにデータベースから数え直されるため、バックアップの復元や行の手作業編集にフラグの修復は要らず、保留がなくなった瞬間にバナーは自然に消えます。

一致を正規化は、まさにそれらの項目だけに範囲を絞った修復ジョブを投入します。正しい名前空間の中で解決をやり直し、メタデータを補い直す——それだけです。アートワークは適用せず、ステージ済みの選択にも触れず、ライブラリの残りを走査もしません。ジョブ実行中はバナーが進捗を示してダッシュボードへリンクし、失敗・部分完了・キャンセル・中断で終わったジョブはコントロールを正規化を再試行に変えます。修復ジョブはサーバーごとに同時 1 件だけで、2 つめを開始するとその範囲をすでに保持しているジョブを名指しします。

完全再スキャンが修復ではなく代替手段である理由

ダッシュボードの完全再スキャンはサーバーのライブラリ全体を読み直します。すべての項目を照合し、解決し直し、メタデータを補い直し、現在のアートワークを観測し直します（サーバー側で変更されたものはレビュー対象として示されます）。オリジナルと履歴は保持され、アートワークが自動適用されることはありません。ローカルキャッシュ全体がずれた疑いがあるとき——バックアップの復元後や、メディアサーバー側で大規模な編集をした後——にはこれが正しい道具です。

識別の不一致に対しては、2 つの理由で誤った道具です。1 つめは、PosterPilot が影響を受けた項目をすでに名指しできること。対象を限定した修復はその行だけに触れますが、完全再スキャンは同じ結果に到達するためにライブラリ全体の走査と、メディアサーバーおよび TMDB への一巡分のリクエストを支払います。2 つめは、待っても直ること。保留中の種別不一致は増分スキップの対象外なので、通常の同期が次に到達したときに処理し直されます。修復ジョブはいま直すための手段であって、唯一の直り方ではありません。

「ローカルのコピー全体がまだ正しいか」が問いのときに完全再スキャンを使ってください。答えがすでに一覧になっているときではありません。

手動で一致を固定する

未解決または誤一致の項目をタイトル、年、映画／番組の種類で検索します。候補は TMDB 識別と識別用メタデータを表示します。確認は、何かを書き込む直前にその識別を TMDB から読み直すので、検索と確認の間に消えた候補は固定されずに拒否され、TMDB に到達できないときは現在の一致に手が付きません。確認が成功すると識別を固定し、旧識別の下で見つかった候補を無効化し、監査イベントを記録します。アートワークは適用されません——新しい識別のアートワークを見つけるにはカバーを検索をもう一度実行してください。

固定は権威的です。同期は上書きせず、正規化の一括処理も飛ばします。置換と解除も同じく明示操作です。解除すると、項目自身が保存している IMDb／TVDB の ID から自動解決をただちに再試行し——TMDB ID の列は固定に属していたので、安全に再利用できるのはこれら独立した ID だけです——どうなったかを報告します。自動一致が復元された、一致が見つからなかった、解決を実行できなかった、のいずれかです。どちらの ID も持たない項目は単に再び対象に戻り、後の同期が新しい TMDB GUID を供給できます。すべての遷移（固定、置換、解除、解決済み、未解決）は項目の一致監査履歴に残ります。

プロバイダー障害は分離されます。一時障害では、そのプロバイダーの最後に判明していた候補を「古い」と明示したうえで保持できます。その後の正常な空応答は、「候補なし」を障害として扱う代わりにそれらを削除します。

アートワークの検索とステージ

カバーを検索は有効プロバイダーを問い合わせ、プロバイダー／セット別にポスターと背景、番組ではシーズン／タイトルカードを表示します。1 スロット、セット全体、混在をステージできます。最高スコア候補は表示されますが、採用操作が必要です。

プロバイダーカードは、設定 → メタデータとプロバイダーで設定した順に並びます。検索がたまたま終わった順ではありません——後者はどのプロバイダーが先に応答したかしか記録していないからです。この順序は表示順であると同時に、スコアが完全に等しい候補どうしの決着にも使われます。等しくないスコアを覆すことは決してないので、最後に置いたプロバイダーのより鮮明な画像でも候補としては勝ちます。設定のプロバイダーの並び順を参照してください。

プロバイダーのセクション、個々のセットカード、番組のシーズングループは折りたためます。初回表示では最初のプロバイダーとその最初のセットが開き——結果があれば ThePosterDB のグループも、単一のフラットなセットとして届くので開きます——残りは閉じた状態です。折りたたみ／展開の選択はブラウザーに保存され、再読み込みをまたいでも、項目を移動しても保たれます。

各プロバイダーグループには専用の ⟳ 再検索コントロールがあり、そのプロバイダーだけ検索をやり直して HTTP キャッシュをバイパスし、保存済み候補を新しい結果で置き換えます。他のプロバイダーの候補には触れません。

固定ビルダーは番組、シーズン、エピソードのステージ数をまとめます。カスタム URL も通常スロットです。ファイルアップロードはプレビュー／確認を行い、バイナリは Kometa YAML URL にできないため直接サーバーのみです。カスタム URL は正確なバイト列を検証するため PosterPilot 自身がダウンロードします。したがって URL は PosterPilot コンテナから到達可能である必要があり（メディアサーバーだけが見える場所では不可）、検証できない書き込みは意図的にサポートされません。

すべてを読み込まずに続きを表示する

大作は数百件のカバーを抱えることがあり、そこまでスクロールするかどうかに関わらず一度に描画するのは高くつきます。そこで各グリッドは 24 件で開き、さらに読み込むがもう 24 件（または残り全部）を出して、その後もまだ何件隠れているかを示します。24 なのは、ページが使うどのグリッドでも割り切れるからです——背景は 2 列、タイトルカードは 4 列、シーズンポスターは 8 列——だから展開しても半端な行が残りません。コントロール脇の一文は常に計算を明示します。何件表示中で、全体が何件で、何件隠れているか。

各グリッドは独立して開きます。ポスターを増やしても背景は増えず、同じプロバイダーの 2 つのセットは別々に展開し、各シーズンのポスターとタイトルカードもそれぞれ自分の件数を持ちます。まだ出していないタイルは遅延読み込みではなく、そもそも描画されません。遅延読み込みの画像でも要素 1 つ分のコストはかかるからです。

続きを出してもネットワークの負荷はゼロです。その項目について保持されている在庫はすでにページの中にあります。グリッドが届かないのは、PosterPilot が保持しなかった分です。TMDB は手元のすべての画像を返し、取り込みはアートワークの種類ごとに 200 件という防御的な上限をかけます。グリッドがその上限に達したときは、存在するすべてを見ているかのように見せる代わりに「そのプロバイダーは PosterPilot が保持する上限を超えるアートワークを返しました。このグリッドは完全な一覧ではありません。」と明示します。設定の候補インベントリと「さらに読み込む」を参照してください。

候補を拡大する

各タイルには画像の下に専用の拡大コントロールがあり、ステージするコントロールとは別です。拡大は見るだけで、選択ではありません。何もステージせず、何も保存せず、どのスロットも変えません。

ダイアログが表示するのは正規アセット——サーバーへアップロードされる、あるいは Kometa YAML に書き込まれるまさにそのファイル——で、切り取りなしの完全な形に、素の画像では伝わらない出所が添えられます。プロバイダー、ピクセル寸法、そしてプロバイダーが言語を報告している場合はその言語です。言語を一切付けないプロバイダー（MediUX、ThePosterDB）には言語の行が出ません。「言語タグなし」ではアートワークではなく取得元を説明することになるからです。

←／→ または矢印キーで並びをたどり、Esc または ✕ で閉じて、開いたときのタイルにフォーカスを戻します。並びの中の現在位置は 2 つのコントロールの間に表示され、変化のたびに読み上げられます。コントロールは折り返さず端で止まります。最初へ戻ってしまう「次へ」は、あなたが読んでいる位置と矛盾するからです。並びは画面にあるものそのものです。同じプロバイダー順、同じ展開状態のセット、同じ言語の絞り込み、同じ表示済みタイル。「次へ」がページ自身の隠しているアートワークに届くことはありません。プレビューを開いている間にグリッドが変わっても——もう 1 バッチ出した、バックグラウンドジョブが終わった——ダイアログは見ていたアートワークを追いかけ、表示するものが本当になくなったときだけ閉じます。原寸で読み込めなかったアセットはその旨を告げ、新しい候補の説明の下に前の候補の画像を出したりはしません。

閲覧で実際にダウンロードされるもの

どの候補にも正規アセット——実際に適用されるファイル——があり、プロバイダーによっては小さめの版も併せて公開しています。PosterPilot はどちらをいつ取得するかを意図して決めています。グリッドはプロバイダーが最適化版を出しているならそれを要求し（TMDB はオリジナルではなく w500 のポスターと w1280 の背景を提供します）、PosterPilot 自身のサムネイルキャッシュを通します。そのため、このバイトはプロバイダーから一度だけ取得され、ページ読み込みをまたいで、項目をまたいで、そのインスタンスを使う全員の間で再利用されます。MediUX、Fanart.tv、ThePosterDB は別のプレビューを公開していないので、そのタイルは正規 URL を表示します——これも同じキャッシュ経由なので、何度閲覧してもプロバイダーを叩き続けることはありません。拡大プレビューと適用の経路は正規アセットを使い、プロバイダーから直接取得します。プレビューが意図的にサムネイルキャッシュを迂回するのは、そのキャッシュがグリッドサイズの画像を置くためのものであり、オリジナルで埋めると本来提供すべきサムネイルを追い出してしまうからです。

拡大画像はダイアログを開いている間しか存在しないので、TMDB のタイルが 100 件並ぶグリッドはサムネイルを 100 件、オリジナルを 0 件ダウンロードします——あなたが 1 件を求めるまでは。プレビュー版を公開しないプロバイダーについては、グリッドの 1 回のキャッシュ取得が唯一の取得で、何度その項目に戻っても変わりません。キャッシュの寿命とサイズは THUMB_CACHE_TTL_DAYS と THUMB_CACHE_MAX_MB で調整できます。設定を参照してください。

アートワークの言語

TMDB アートワークの言語を設定していると、項目ページはグリッドをその言語に絞り込み、上部でそのことを伝えます——言語名と、他の言語で何件隠しているかを示します——そしてすべての言語を表示の切り替えを添えます。この切り替えはページ内だけのもので、保存した設定を書き換えることは決してありません（元に戻すときは「〈言語〉のみ表示」）。そのタイトルに一致するものがなければ、空のグリッドを見せる代わりに、他の言語に何件のカバーがあるかを伝えて同じ逃げ道を出します。この設定が支配するのは TMDB のアートワークだけで、決める前に設定の TMDB アートワークの言語を読む価値があります。

プレビューして適用

方法を選びます（DEFAULT_APPLY_METHOD から開始）。

• 直接サーバー (plex) — 以前の状態を保存し、アクティブ Plex／Jellyfin／Emby へ書き、対応時にロックして検証します。
• Kometa — posterpilot-movies.yml または posterpilot-shows.yml を更新し、無関係な内容を保持して YAML を検証します。
• 両方 — 宛先は独立し、一方の失敗が他方を隠しません。

まず項目、スロット、候補、現在状態、宛先、スキップの正確なプレビューを作ります。別の確認は期限付き 1 回限りで、選択／指紋に結び付いています。何か変わると書き込まず、再プレビューが必要です。警告のないプラン — スキップが 0 件で書き込みが 1 件以上 — はワンクリックで適用され、PosterPilot が同じ操作の中で確認を発行します。スキップがあれば明示的な確認に戻り、適用して次へは常にダイアログを保持します。

一括プレビューは全 ID を凍結し、プラン作成のため非破壊的に候補検索できます。実行時は再検索／置換しません。対応する子がないシーズン／エピソードはスキップし、1 スロットの失敗で他を中止しません。

Kometa がエクスポートを消費する方法

posterpilot-movies.yml は TMDB ID（なければ IMDb）、posterpilot-shows.yml は TVDB ID（なければ IMDb）を使い、シーズン／エピソードを入れ子にします。対応するファイルを Kometa ライブラリの metadata_files に追加してください。Kometa マネージャーでは接続に加えて、物理パスと Kometa の実行環境から見える file: プレフィックスの違いも説明しています。

アートワークの適用状況

アートワークのタイムラインは「PosterPilot が何をしたか」に答えます。適用状況は別の問い——「いま何が事実か」——に答え、両者は食い違うことがあります。だからこそ分けてあります。各項目ページのヒーローの下にアートワークの適用状況パネルがあり、Library と Review もこれで絞り込めます。

適用状況は常に宛先ごとに、2 つのパネルを並べて報告します。メディアサーバーは PosterPilot が Plex／Jellyfin／Emby にアップロードしたアートワーク、Kometa メタデータは PosterPilot が自身の Kometa YAML ファイルに書いたエントリーです。この 2 つが 1 つの判定に畳まれることはなく、件数が足し合わされることもありません。パネル全体はこの区別を守るために存在します。

Kometa へのエクスポートはアートワークの適用ではありません

エクスポートはディスク上の YAML ファイルの 1 行です。その行を書いたことが証明するのは、ファイルが書かれたことだけです。Kometa が実行されたことも、Kometa がそのファイルを読んだことも、メディアサーバーが結果を受け入れたことも、その URL がいまも解決することも証明しません。パネルはそのとおりに——「Kometa ファイルにエクスポート済みです。Kometa が適用したかは PosterPilot では確認できません。」——と述べ、エクスポートをサーバー側の主張に格上げすることは決してありません。Kometa の方法だけで適用した場合、メディアサーバーのパネルはそこには何も適用されていないと言い続けます。それは正しい言明であって、不具合ではありません。

同じタイトルのコピーにも同じ規則が働きます。2 台のサーバーに存在する映画も、Movies と Movies 4K の両方に置かれていて 1 台のサーバーに 2 回現れる映画も、証拠が独立した複数のコピーです。一方にポスターを適用しても、もう一方については何も証明しません。タイトルに複数のコピーがあるとき、見出しは件数を宛先ごとに報告し（「2 件中 1 件が適用済み」）、合算した 1 つの数字にはしません。あるコピーをサーバーに適用し、別のコピーを Kometa にエクスポートした状態は「2 件中 2 件」ではありません。

パネル内の各スロット——ポスター、背景、各シーズン、各エピソード——もそれぞれの状態を保ちます。番組のポスターはサーバー上で検証済みでも、エピソードのタイトルカードはそうでない場合、パネルは 1 つのバッジに丸めずそのとおりに述べます。

各状態の意味

状態	意味
このサーバーに適用済み	書き込み、期待していた指紋がいまサーバーの返すものと一致しています。メディアサーバーで肯定的かつ検証済みと言える唯一の状態です。
Kometa にエクスポート済み	現在のメタデータファイルにこのスロットの URL があります。ディスク上のファイルです——上の注意を参照してください。
適用済み・未検証	書き込みましたが、現在のサーバーの状態を確認できませんでした。履歴はあり、証明はありません。
PosterPilot の外部で変更	書き込みましたが、その後に何かが置き換えました。これ自体が 1 つの状態で、他の状態の言い換えではありません。
PosterPilot では未適用	信頼できる観測の結果、ここにアートワークを置いた証拠が見つかりませんでした。
適用状況は不明	信頼できる観測ができませんでした——Kometa ファイルが読めない、メディアサーバーに到達できない、履歴が不完全、など。

この 3 つの言い回しは荷重を受け持っており、緩く読むと判断を誤ります。

「PosterPilot では未適用」は「アートワークがない」ではありません。 これは私たちが何をしたかについての言明であって、あなたのサーバーに何があるかについてのものではありません。何年も前に Plex で手作業でポスターを付けたタイトルはここでは未適用と表示されます——そして立派なポスターを持っています。タイトルにアートワークがないと主張する適用状況もフィルター値も、意図的に 1 つも存在しません。PosterPilot にはそれを知る術がないからです。

「PosterPilot の外部で変更」はそれ自体が答えです。 何かが私たちのアートワークを置き換えました——Plex 自身のエージェント、別のツール、あるいは人です。これを「欠落」と読んで適用し直すと、ライブラリを上書きし続けている正体をいつまでも突き止められません。

読み取りの失敗は「不明」であって「未適用」ではありません。「確認できなかった」と「確認したが、そこにない」は別の事実です。混同すると、隅々まで適用済みのライブラリが空だと報告され、すべてをエクスポートし直したくなります。だから、読めない Kometa ファイル、解決できないディレクトリ、最後まで読めなかった履歴はいずれも「適用状況は不明」になります。ファイルが存在しないことは信頼できる観測なので、そうはなりません。

適用状況で絞り込む

Library と Review は 1 つのアートワークの適用状況コントロールを共有します。このサーバーに適用済みは、アクティブなサーバーで検証済みのスロットが少なくとも 1 つあること。Kometa にエクスポート済みは、現在のメタデータファイルに現れるスロットが少なくとも 1 つあること。アートワークが必要は、どちらの宛先でも適用されていないこと——PosterPilot が一度も触れていないタイトルもここに一致し、これは状態を引くだけでは実現できません。適用状況は不明は、証拠が確定しないスロットが少なくとも 1 つあること、つまりどちらかの宛先が「適用状況は不明」か、サーバー側が「適用済み・未検証」であることです。

「少なくとも 1 つのスロット」に注意してください。ポスターは適用済みでタイトルカードがない番組は「このサーバーに適用済み」に一致します。フィルターは開く価値のあるタイトルを見つけるためのもので、スロットごとの事実は項目ページのパネルにあります。適用状況はコピーが属するサーバーを範囲とするので、アクティブなサーバーを切り替えると答えも変わります。条件に何も一致しないときは、どのコントロールが空にしたのかを白いグリッドの前で悩ませる代わりに、空状態がその旨を伝えて「すべての適用状況」へ 1 クリックで戻せるようにします。

適用状況が最新に保たれる仕組み

適用状況は、自分では所有していない 3 つの情報源——追記のみのリビジョン台帳、サーバーに対するスロットごとの現在の観測、ディスク上の Kometa ファイル——から作り直される投影です。適用、元に戻す、同期、Kometa の移行や設定書き込みのあとに導出し直されます。加えて、誰かが Plex で直接ポスターを付け替えても PosterPilot に通知は来ないので、証拠が 15 分より古い項目ページは、開いたときにサーバーを観測し直します。

この設計から 2 つの帰結が生まれ、どちらも意図的です。再計算が、それを引き起こした処理を失敗させることはありません。成功したのに投影を更新できなかった適用は、それでも成功した適用です。代償は古さで、次のきっかけが直します。適用状況の照合は他の何も変えません。アートワークも YAML も一致も書かず、何かをレビュー済みにすることも決してありません。キューのどこにいるかはあなたの表明、宛先で何が真かは PosterPilot の表明であり、一方が他方を書き換えてはならないのです。

検証、履歴、元に戻す

タイムラインは宛先／スロット、由来、以前の状態、結果、正確／ベストエフォート検証を記録します。失敗や証拠不足を成功とは表示しません。

利用可能なリビジョン、シーズン、項目全体の復元をプレビューできます。確認は凍結スナップショット／値だけを戻し、検証して新しい履歴を追加します。部分失敗でも成功した復元を保持します。安全性と元に戻すを参照してください。

失敗と再試行

ジョブ詳細は宛先／スロットごとの成功、失敗、スキップ、中断と秘匿化エラーを表示します。失敗のみ再試行は対象だけを実行し、成功を繰り返しません。設定／プラン問題は修正と新しいプレビューが必要です。

FUN、コレクション、複数サーバー

FUN には最大 3 候補、ブラインド／カプセル、Poster Match、ギャラリー、時間予算セッションがあります。コレクションはメンバー、由来、整合性、ファミリーカバレッジ、上書きを表示し、メンバー全体の再検索も 1 操作で行えます。自動適用はしません。FUN とコレクションを参照してください。

複数サーバーではスイッチャーを使い、Library、ジョブ、Review、コレクション、自動化を分離します。複数サーバー移行も参照してください。

詳細ログは設定 → アクティビティ、診断／自動化／バックアップは自動化と復旧にあります。