クラウドからエクスポートした後、ファイル自体は残っているのにフォトライブラリからアルバム情報が失われるのは、アセットをまとめていたサービス固有の関連付けがインポート時に復元されないためです。
アルバム情報は、各JPEGやRAWファイルの内部に永久に埋め込まれているとは考えず、独立したメタデータとして扱ってください。すべてをセルフホスト型ライブラリにインポートする前に、クラウドからのエクスポートにアルバムディレクトリ、JSONサイドカー、アルバム単位のメタデータ、お気に入り、説明、同一ファイルへの重複参照が含まれているか確認します。そのうえで、エクスポートの構造を理解できるインポーターを使用するか、エクスポートから実際に確認できる関連付けだけを再構築します。
写真は残っていても関連付けが失われたことを確認する
既知の写真を5〜10枚含むアルバムを1つ選び、すべてのオリジナルがエクスポート内に存在することを確認します。次に、それらのアセットが移行先のライブラリに表示されているか、単にアルバムとの関連付けだけが失われているのかを確認します。
Googleは、追加メタデータはJSONに保存されると説明しており、クラウドライブラリのすべてのフィールドが画像自体に書き戻されるわけではありません。
オリジナルが見つからない場合は、不完全なエクスポートが原因です。オリジナルが存在するのに整理されていない場合は、画像ファイルを再コピーするのではなく、エクスポートの構造を保持したままアルバムメタデータを確認してください。
エクスポートを平坦化する前にアルバムメタデータを確認する
元のTakeoutまたはクラウドエクスポートのアーカイブは、そのまま保持してください。アルバムフォルダ、アルバム単位のメタデータファイル、JSONサイドカー、同じ写真への繰り返し参照、年別フォルダとアルバムフォルダで異なるファイル名を探します。
セルフホスト型への移行手順では、Takeoutにはアルバムメタデータも含まれると説明されています。
インポーターがこれらの関連付けを読み取る前に、すべてのディレクトリを1つのフォルダに平坦化しないでください。フォルダの重複排除によって容量は節約できても、アルバムを再構築するために必要な情報が失われる可能性があります。
クラウドの関連付けを理解できるインポーターを使う
一般的なファイルアップローダーは写真を取り込めても、ファイルパスや認識可能なサイドカーデータにその関連付けが記録されていない限り、どのアルバムに属していたかを推測できません。小規模なテストアルバムを使って、通常のアップロードとTakeout対応インポーターを比較してください。
Immichへの移行レポートでは、インポーターがクラウドエクスポートのコンテキストを保持すれば、アルバムメタデータを再構築できると説明されています。
Takeout対応インポートでテストアルバムが復元された場合は、完全移行にもその方法を使ってください。通常のアップローダーと、アルバム対応の別のインポートの両方を使って、アセットを重複作成しないようにします。
インポート前にサイドカーを正しい写真に対応付ける
クラウドからのエクスポートでは、大きなアーカイブが分割されたり、メタデータファイルの名前が変更されたり、アルバムメタデータが別の場所にある同一アセットを参照したりすることがあります。移行先のアプリを疑う前に、ファイル名の対応とサイドカーの配置を確認してください。
Googleフォトの移行ガイドでは、Takeoutの構造を意図的に扱うことで、移行ツールがメタデータを保持すると説明されています。
編集済みコピー、同名ファイル、Live Photos、長いファイル名については、サイドカーとの対応がずれやすいため、必ずテストしてください。すべてのアルバム数を確認するまで、元のZIPまたはTGZアーカイブを保持します。
エクスポートから確認できるアルバムだけを再作成する
一部のクラウドアルバムには、他のユーザーがアップロードした共有アセット、自動生成されたグループ、通常のユーザー作成アルバムとは異なるサービス生成コレクションが含まれています。元のサービスに表示されるアルバム一覧と、エクスポートに実際に含まれるメタデータを比較してください。
実用的なImmich移行メモでは、エクスポートされた関連付けデータが利用できる場合、Immich-Goでアルバムを保持できると説明されています。
その近似で問題ないと判断できない限り、撮影日やフォルダ名から不足しているアルバム情報を推測して作らないでください。正確に再構築できるアルバムと、手動または部分的な再構築が必要なアルバムを記録します。
クラウドのコピーを削除する前にアルバム数を確認する
インポート後は、大規模なアルバム、小規模なアルバム、共有アルバム、古いアルバム、最近編集したアルバムをサンプルとして比較します。アセット数を数え、代表的な写真を開き、日付と説明を確認し、重複ファイルをアルバム情報の欠落と誤認していないことを確認してください。
Takeoutメタデータツールは、ローカルライブラリへ適切にインポートする前に、サイドカーによってエクスポートされたメタデータが復元される理由を示しています。
重要なアルバムと代表的なアセットが、家庭で必要な範囲で元の状態と十分に一致して初めて、移行は完了です。最後のクラウド側コピーを削除する前に、セルフホスト型の家族向けフォトライブラリに関するZimaSpaceの関連ガイドで、バックアップの基本方針を確認できます。
よくある質問
写真はすべてあるのに、なぜアルバムがすべて空なのですか?
インポーターがメディアファイルだけをアップロードし、アセットをコレクションに関連付けていたサービス固有のサイドカーやアルバムメタデータを読み取っていない可能性があります。
EXIFだけでGoogleフォトのアルバムを再構築できますか?
いいえ。EXIFは日付、カメラ情報、位置情報には役立ちますが、通常のアルバム所属は別の関連付けであり、通常はエクスポートメタデータまたはアルバム対応インポーターが必要です。
インポート前に重複して見えるアルバムのコピーを削除すべきですか?
インポーターの重複排除の動作を理解するまでは削除しないでください。同じ写真が複数のアルバムから参照されていても、独立したオリジナルが複数存在するとは限りません。
サポートとヒント
もっと読む

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

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

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

