Honor Motion Photos with embedded MP4 are displayed as still images: HiHonor/LIVE_ format is not detected

[sea-with-sakura]

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

• Yes

The bug

The bug

Motion Photos taken on an HONOR AAK-AN00 are uploaded to Immich with their embedded video data still present, but Immich displays them as ordinary still images.

This appears to be a detection issue rather than missing video data or a decoding failure.

Environment

• Immich Server: v3.3.5
• Deployment: Docker, official ghcr.io/immich-app/immich-server:v3.3.5 image
• Phone: HONOR AAK-AN00
• The affected original photos play as Motion Photos in the phone's stock gallery.

Reproduction steps

1. Take a Motion Photo on the HONOR phone.
2. Upload it using the Immich mobile app.
3. Wait for metadata extraction to finish.
4. View the uploaded asset: it is displayed as a still image without a linked motion video.

Expected behavior

Immich detects the embedded video in the Honor Motion Photo and makes it playable as a Motion Photo.

Actual behavior

The original JPEG, including its embedded video, is stored on the server. Metadata extraction completes, but livePhotoVideoId remains null and the motion component is not exposed for playback.

Evidence from an affected original

File: IMG_20261031_171652.jpg
Size: 7,903,337 bytes

Inspection of the server-side original found:

• Honor-specific strings including HiHonor_OfflineData, HiHonor_CWMV2, and a trailing LIVE_4729477 marker.
• An embedded MP4 beginning at byte offset 3,173,820, with ftyp, moov, and mdat boxes.
• No MotionPhoto, MicroVideo, or MicroVideoOffset tags returned by the server's bundled exiftool-vendored reader.
• The XMP Container directory describes the primary image and HDR gain map, but has no MotionPhoto entry.

After locating the embedded MP4 in memory, ffprobe identified:

• Video: HEVC, 1296 × 1728, approximately 3.081578 seconds.
• Audio: AAC, approximately 2.965333 seconds.

A frame-counting probe read 40 video frames, and an ffmpeg decode check completed with exit code 0.

Scope

A read-only scan of 443 non-trashed images uploaded during the last seven days found:

• 228 JPEGs with an embedded MP4 file-type header and movie box near the position indicated by their LIVE_ trailer.
• These included 160 of 294 images identified as HONOR AAK-AN00.
• None of those 228 assets had a linked livePhotoVideoId.
• Six additional samples were probed successfully and contained identifiable video and audio streams.

The full set was checked for embedded video structure; it was not exhaustively decoded.

Suspected cause

In v3.3.5, isMotionPhoto() only enters the motion-photo extraction path when either tags.MotionPhoto or tags.MicroVideo is present:

https://github.com/immich-app/immich/blob/v3.3.5/server/src/services/metadata.service.ts#L669-L671

The affected Honor files contain embedded video but do not expose either tag, so they appear to bypass extraction entirely.

Could Immich support this Honor trailer format, either through metadata-reader support or a validated fallback that locates and extracts the embedded MP4?

Related reports

• Detect Live Photos on Huawei Devices #13911 / Discussion Detect Live Photos on Huawei Devices #13912: Huawei Live Photo detection, although that report concerns mobile discovery/upload rather than this server-side detection case.
• Huawei Live Photos split into separate JPG and MP4 files after download #25702: Huawei Live Photo download behavior; a different issue, but relevant to preserving embedded motion data.

The OS that Immich Server is running on

Ubuntu 26.04.1 LTS (Docker Compose)

Version of Immich Server

v3.3.5

Version of Immich Mobile App

3.3.3

Platform with the issue

• Server
• Web
• Mobile

Device make and model

HONOR AAK-AN00

Your docker-compose.yml content

name: immich
services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION}
    env_file:
      - .env
    ports:
      - 127.0.0.1:2283:2283
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - ${THUMB_LOCATION}:/data/thumbs
      - ${ENCODED_VIDEO_LOCATION}:/data/encoded-video
      - ${EXTERNAL_LIBRARY_LOCATION}:/external/fnos-photos
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - redis
      - database
    restart: unless-stopped
    healthcheck:
      disable: false
  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION}
    env_file:
      - .env
    environment:
      HTTP_PROXY: ${ML_HTTP_PROXY:-http://<REDACTED_PROXY_HOST>:7890}
      HTTPS_PROXY: ${ML_HTTPS_PROXY:-http://<REDACTED_PROXY_HOST>:7890}
      NO_PROXY: ${ML_NO_PROXY:-localhost,127.0.0.1,immich-server,immich-machine-learning,database,redis}
    volumes:
      - model-cache:/cache
    restart: unless-stopped
    healthcheck:
      disable: false
  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:9@sha256:c123e3715db63d06d4ad6964884037aa0d5d4d703939b9929954112889708e1d
    restart: unless-stopped
    healthcheck:
      test: redis-cli ping | grep -q PONG || exit 1
  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    env_file:
      - .env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: --data-checksums
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb
    restart: unless-stopped
    healthcheck:
      disable: false
volumes:
  model-cache:

Your .env content

UPLOAD_LOCATION=<REDACTED>
THUMB_LOCATION=<REDACTED>
ENCODED_VIDEO_LOCATION=<REDACTED>
EXTERNAL_LIBRARY_LOCATION=<REDACTED>
DB_DATA_LOCATION=<REDACTED>
TZ=Asia/Shanghai
DB_PASSWORD=<REDACTED>
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
DB_STORAGE_TYPE=SSD
IMMICH_VERSION=v3.3.5

Reproduction steps

1. Take a Motion Photo on an HONOR AAK-AN00 and verify that it plays in the phone's stock gallery.
2. Upload the original photo using the Immich mobile app to Immich Server v3.3.5.
3. Wait for metadata extraction to complete.
4. Open the uploaded photo in Immich. It is displayed as a still image without a playable motion component.
5. Inspect the server-side original JPEG: the embedded MP4 is still present and can be extracted and decoded, but the asset's livePhotoVideoId is null.

Expected: The embedded video is detected and the photo can be played as a Motion Photo.
Actual: The original file retains its video data, but Immich does not recognize it as a Motion Photo.

Relevant log output

No corresponding metadata-reading or motion-video extraction errors were found in the server logs examined. Metadata extraction completed for the affected asset, but livePhotoVideoId remained null.

File inspection and probe results are provided under Additional information.

Additional information

Server-side inspection of IMG_20261031_171652.jpg:

• File size: 7,903,337 bytes.
• Contains Honor-specific strings: HiHonor_OfflineData, HiHonor_CWMV2, and a trailing LIVE_4729477 marker.
• Embedded MP4 starts at byte offset 3,173,820 and contains ftyp, moov, and mdat boxes.
• ffprobe identified HEVC video at 1296 × 1728, duration approximately 3.081578 seconds, plus AAC audio.
• A frame-counting probe read 40 video frames; an ffmpeg decode check completed with exit code 0.
• The bundled exiftool-vendored reader returned no MotionPhoto, MicroVideo, or MicroVideoOffset tags.
• The XMP Container directory describes the primary image and HDR gain map, but has no MotionPhoto entry.

Suspected detection gap:

In v3.3.5, isMotionPhoto() requires tags.MotionPhoto or tags.MicroVideo before attempting extraction:

https://github.com/immich-app/immich/blob/v3.3.5/server/src/services/metadata.service.ts#L669-L671

This Honor file contains video but has neither tag, so it appears to bypass motion-video extraction.

Scope:

A read-only scan of 443 non-trashed images uploaded during the preceding seven days found 228 JPEGs with embedded MP4 headers and movie boxes near the positions indicated by their LIVE_ trailers. These included 160 images identified as HONOR AAK-AN00. None of those 228 assets had a linked livePhotoVideoId.

Six additional samples were probed successfully and contained identifiable video and audio streams. The full set was checked for video structure, not exhaustively decoded.

Related, but different, reports:

• Detect Live Photos on Huawei Devices #13912
• Huawei Live Photos split into separate JPG and MP4 files after download #25702