transfer-failed-retry

転送失敗の再試行

構造化された moviepilot_api 操作のみを使用し、現在のスキーマを確認してください。

必須のフロー

1. 指定された正確なすべての履歴 ID を確認します。ソース／ストレージ、宛先、モード、識別情報、シーズン／エピソード、ステータス、エラー、永続的なタスクコンテキストを記録します。タスクの所有者が不明な場合は永続的なものとして扱い、別のレコードには決して操作を行わないでください。
2. storage.list でソースが利用可能か確認します。ファイルが見つからない場合、ストレージ／権限／設定の問題がある場合、手動確認が必要な場合、影響が不確かな場合、または再試行回数の上限に達している場合は停止します。ターゲットを削除したり、グローバルルールを変更したりしないでください。
3. ファイル名とエラーを分析します。media.recognize または media.search で識別情報を確認し、media.detail または media.seasons で TV のシーズン／エピソードを確認します。誤った識別結果をそのまま再利用しないでください。Season 2 - 03 の場合、S01 と決めつけずに S02E03 であることを確認します。共有されていることが確認できた識別情報のみグループ化し、各ファイルのシーズン／エピソードを確認してください。
4. 元のソース、宛先、モード、確認済みの識別情報、シーズン／エピソードを使用し、preview=true を指定して transfer.file でプレビューします。修正を送信する前にプレビューを確認してください。
5. 永続的なレコードには、指定されたコンテキストに含まれる正確な履歴 ID、元の task_id と settlement_revision、確認済みの media_source、media_id、media_type（movie／tv）、および任意の season／episode を指定して、transfer.history.replan を使用します。ファイルへの影響がなく、計画時の却下によって失敗したケースのみ受け付けます。タスク、元の計画／ステップの証拠、決済レシート、ソースの重複排除、消費済みの再試行回数は保持されます。
6. 再計画が却下された場合は停止し、阻害要因を報告してください。永続的なタスクの確認を回避するために、transfer.history.delete、通常のやり直し、プレビューなしの新たな transfer.file、ターゲットのクリーンアップ、証拠の削除を決して行わないでください。音楽、およびファイル操作の証拠があるタスクには手動での復旧が必要です。
7. legacy と明示されたレコードのみ、ソース／ターゲットファイルを削除せずに transfer.history.delete を呼び出せます。その後、応答で履歴の削除が確認されてから transfer.file を続行してください。確認済みの識別情報、元のストレージ／モード／宛先、シーズン／エピソード、音楽のエンティティフィールドを保持します。同じディレクトリにあることが確認済みの完全なアルバムは、アルバムとして一度だけ再試行できます。アーティストを転送先にしてはなりません。
8. 確認済みの修正、受け付け済み／キュー登録済みの再計画、確認済みの転送成功、未解決の阻害要因を正確に報告します。再計画がキューに登録されても、転送が完了したことにはなりません。失敗／再試行の証拠をリセットしたり削除したりしないでください。