Tecnología · GUÍA PRÁCTICA
Immich guarda la Live Photo como foto fija: revisa el par antes de cambiar metadatos
La reproducción remota, la coincidencia de identificadores y una imagen guardada demuestran cosas distintas. Revisa los dos archivos originales y el elemento restaurado en Fotos antes de dar la copia por recuperada.
Si una Live Photo se mueve en Immich pero el elemento recién guardado en Fotos de Apple es una imagen fija, su restauración todavía no está verificada. Conserva los archivos originales. Primero comprueba que tienes la imagen y el vídeo que la acompaña, examina sus tipos de archivo reales y los identificadores pertinentes, y después revisa el elemento restaurado en Fotos. Cambiar un UUID no es el primer paso.
Hay una razón concreta para separar esas comprobaciones. En el servicio de guardado de la app móvil de Immich que examinamos en v3.2.1 y v3.3.5, una rama que maneja un error de Fotos intenta guardar solo la imagen fija y considera satisfactorio un resultado de ese guardado distinto de null. Es evidencia de una alternativa de guardado en el código fuente; no demuestra que haya causado tu resultado ni que todos los mensajes de finalización procedan de ese valor devuelto.
Un vínculo del servidor, dos archivos y una Live Photo restaurada son pruebas distintas
Immich puede asociar una imagen con un vídeo y reproducir el movimiento en su propio visor. Eso responde a una pregunta sobre el servidor. Tener ambos archivos descargados responde a una pregunta sobre su conservación. Ver que el nuevo elemento funciona como Live Photo en Fotos de Apple responde a la pregunta sobre la restauración que realmente te interesa. Ninguna de esas observaciones debe sustituir sin más a la siguiente.
Apple documenta una asociación entre el identificador de contenido del vídeo y los metadatos Exif MakerNote de la imagen fija correspondiente. El vínculo propio de Immich es una relación en la base de datos. Por tanto, volver a vincular dos elementos en Immich no demuestra por sí solo que sus metadatos de Apple integrados hayan cambiado ni que Fotos pueda aceptar el par.
Conserva los recursos originales y anota cómo se produjo el fallo
Trabaja con copias de la imagen fija original y del vídeo que la acompaña, obtenidas de tu archivo o de una descarga de archivos originales. Guárdalas juntas en una carpeta aparte. Si la exportación solo produjo una imagen fija, localiza primero el vídeo original correspondiente: una captura de pantalla, una vista previa o un archivo renombrado como .MOV no pueden sustituir los datos de movimiento que faltan. No modifiques los archivos dentro del almacenamiento gestionado por Immich para intentar repararlos.
Anota las versiones del servidor de Immich, de la app móvil y de iOS, y si el resultado procede de Guardar en el móvil, de una descarga web o de otra exportación. Indica si el material era originalmente una Live Photo de Apple o una foto con movimiento de Android. Esta guía examina la restauración en Apple; no promete que una conversión de fotos con movimiento entre plataformas funcione.
Examina los tipos de archivo y los grupos de identificadores sin escribir cambios
Con ExifTool instalado, ejecuta `exiftool -ver` y después `exiftool -a -G1 -s -FileType -ContentIdentifier "photo.JPG" "photo.MOV"`, sustituyendo las dos rutas entre comillas por las de tus copias. Estas opciones leen los metadatos. Conserva la separación entre archivos y las etiquetas de grupo en la salida. Un nombre terminado en .MOV no sustituye al tipo de archivo que indique la herramienta.
En las muestras de iPhone que examinamos, la imagen fija mostraba [Apple] ContentIdentifier y el vídeo mostraba [Keys] ContentIdentifier. Compara esos valores. No los sustituyas por ImageUniqueID, un UUID del nombre del archivo o un valor XMP ajeno solo porque se parezca. Si falta un grupo, aparecen varios valores contradictorios o la herramienta no puede leer el archivo, registra esa incertidumbre en vez de declarar válido el par.
Dos muestras de fallos reales muestran por qué una única receta de metadatos no basta
Examinamos con ExifTool 13.59 los archivos públicos con pares JPEG/MOV adjuntos a las incidencias 14066 y 15805 de Immich. Ambos contenían un JPEG y un MOV. Los identificadores de contenido de Apple y Keys diferían en el primer par y coincidían en el segundo. Las comprobaciones SHA-256 anteriores y posteriores a la inspección de solo lectura confirmaron que los cuatro archivos permanecían intactos.
Esos resultados clasifican los archivos aportados; no diagnostican los fallos originales. La incidencia 14066 también incluía un error por la ausencia de un registro de tarea. La incidencia 15805 figuraba expresamente entre las resueltas por una corrección posterior de una URL de descarga de vídeo incorrecta. No realizamos una restauración en iOS ni en macOS, y un par correcto exportado por el servidor no demuestra qué datos entregó una descarga móvil anterior.
Elige el siguiente paso según las pruebas de las que dispones
Si falta el vídeo, no se puede leer o en realidad es otra imagen, recupera el recurso original correcto antes de intentar asociar los archivos. Si los identificadores pertinentes faltan o son distintos, vuelve a los archivos de origen y al historial de exportación para determinar qué imagen y qué vídeo forman el par. Compartir el nombre base o una hora de captura parecida es una pista, no una autorización para sobrescribir identificadores de archivos elegidos arbitrariamente.
Si los identificadores pertinentes coinciden, deja de tratar la sustitución del UUID como una reparación universal. Conserva ese par e investiga la entrega de los archivos y el proceso de guardado en Fotos. Las herramientas de reparación existentes pueden copiar un identificador entre archivos, pero eso no certifica el vídeo, sus demás metadatos ni la aceptación por parte de Apple. Una restauración fallida con identificadores coincidentes exige reunir mejores pruebas, no seguir reescribiendo el mismo valor.
Distingue las correcciones anteriores del cliente y el guardado alternativo de una imagen fija
Aquí son relevantes dos correcciones ya realizadas en el cliente. La PR22708 corrigió una solicitud de vídeo que utilizaba la URL de la imagen fija. La PR29952 corrigió la agrupación de las tareas completadas de descarga de Live Photos y la interacción entre las funciones de retorno. Demuestran que puede existir un problema de entrega independiente de los identificadores del par original. Ninguno de los parches prueba la causa de todos los informes posteriores sobre imágenes guardadas sin movimiento.
El código de guardado examinado de v3.2.1/v3.3.5 sigue capturando un error cuyo código empieza por PHPhotosErrorDomain, intenta ejecutar saveImageWithFile y devuelve si ese guardado estático produjo un elemento. No hemos seguido ese valor booleano hasta todos los estados de la interfaz. La conclusión útil es más limitada: el progreso de la transferencia y una imagen fija guardada no bastan para demostrar una restauración completa de la Live Photo. Anota las versiones y vuelve a probar un ejemplo con sus originales protegidos tras una actualización compatible, en vez de aplicar un parche antiguo a ciegas.
Comprueba el elemento recién restaurado en Fotos de Apple
Examina el elemento creado por esta restauración, en lugar de una copia anterior que ya funcionaba en la fototeca. En el iPhone, las instrucciones actuales de Apple sitúan las Live Photos en Fotos → Colecciones → Tipos de contenido → Live Photos; abre el elemento y mantén pulsada la pantalla para reproducirlo. Si Fotos sigue ofreciendo los controles Live, comprueba si el efecto estaba desactivado antes de concluir que falta el movimiento.
Un MOV que se reproduce por separado es material conservado útil, pero no demuestra que Fotos haya restaurado una Live Photo como un único elemento. Conserva los originales hasta que el dispositivo y el procedimiento previstos superen esta comprobación. No borres la única copia que funciona solo para hacer una prueba desde cero; utiliza un ejemplo que ya haya fallado y cuyos recursos hayas guardado por separado, o un destino de prueba aislado cuando sea posible.
Registra el resultado sin exagerar lo que se ha recuperado
Para el ejemplo probado, conserva las versiones, el método de exportación, los dos tipos de archivo, si coincidían los identificadores pertinentes y el resultado real de la reproducción en Fotos. Un informe útil para soporte distingue entre «falta el vídeo original», «ambos recursos conservados, restauración sin verificar» y «restaurado y reproducido en este dispositivo». Incluye el error exacto si apareció alguno, sin asumir que su ausencia demuestra que se guardó una Live Photo.
Este procedimiento ayuda a decidir el siguiente paso; no recupera fotogramas ausentes ni certifica todos los pares con identificadores coincidentes. Su resultado práctico es una descripción fiel de la restauración y la conservación del material de origen. Que el servidor reproduzca el movimiento no debe ser la única razón para descartar la copia restante de una Live Photo que todavía necesitas restaurar.
