Why Does a Self-Hosted Gallery Split One Live Photo Into Unrelated Assets?

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

A self-hosted gallery usually splits a Live Photo when it can no longer prove that the still image and short motion clip belong together.

The failure often appears after export, renaming, migration, or an external-library import rather than during capture. Treat the still and motion files as evidence: compare one working pair with one broken pair, determine whether relationship metadata or naming survived, then repair only the layer that lost the association.

Prove the Two Assets Came From One Capture

Start with one broken example and identify the still image and its short motion clip by capture time, original filename, dimensions, and source-device export. Do not merge or delete anything yet.

A Live Photo is not one ordinary media file. The gallery has to recognize a relationship between components; preserving the Live Photo pairing metadata is therefore the first diagnostic boundary.

If the still and motion timestamps or base names clearly belong together, the split is a pairing problem. If they do not, first rule out an unrelated burst, edited copy, or separately exported video.

Check Whether Pairing Metadata Survived Export

Compare a pair that still works with the broken pair using metadata inspection rather than the gallery UI alone. Look for content identifiers, asset identifiers, or export metadata that ties the two components together.

Backup workflows that preserve both Live Photo files illustrate why moving only the image or only the motion file destroys the relationship even though both remaining files are individually valid.

When metadata is missing from only the failed pairs, repair or re-export those pairs from the authoritative source. Do not rebuild the entire gallery database for a metadata loss that exists in the source files.

Compare Filenames and Folder Placement

Some importers use filenames or colocated files as a fallback when richer pairing metadata is unavailable. Compare capitalization, suffixes, extensions, and whether a rename tool treated the image and video differently.

Independent analysis of the two-file Live Photo structure shows why a rename or move operation can preserve both files yet still make the pair harder for a self-hosted importer to reconstruct.

Test one copy with the original paired names in the same folder. If that restores grouping, fix the export or rename workflow rather than manually joining hundreds of database records.

-15% OFF
Single board computer zimaboard2

Retest Import Order With One Clean Pair

Create a small temporary import containing one known-good pair and one broken pair. Import both components together, then repeat with the motion file arriving later to see whether the gallery reconciles delayed companions.

Practical guidance on Live Photo backup pairing reinforces that preservation depends on carrying the pair through the backup and restore path, not simply proving both files exist somewhere on disk.

If simultaneous import works but delayed import does not, the operational fix is to change the ingest workflow or trigger the application’s supported rescan. Avoid database edits unless the application provides a documented repair path.

Repair the Smallest Broken Layer and Verify

Choose the repair from the evidence: re-export missing metadata, restore paired filenames, place components together, or re-import one pair. Keep originals outside the working library until the test succeeds.

For a broader self-hosted photo workflow, the related ZimaSpace guide on Immich family photo library helps keep the repair tied to a recoverable household photo-library design.

The fix is complete only when the gallery shows one Live Photo, preserves both still and motion playback, survives a rescan, and does not create a second duplicate asset.

Frequently Asked Questions

Can one Live Photo be repaired without re-importing the whole library?

Usually yes. Prove the still and motion files belong together, repair the smallest broken naming or metadata relationship, then test one controlled re-import before touching the full library.

Does converting the pair to one ordinary video preserve the Live Photo?

No. It can preserve motion content, but it removes the still-plus-motion relationship and the Live Photo behavior the gallery is trying to represent.

Should duplicate-looking still and video assets be deleted immediately?

No. First confirm they are the two components of one capture and preserve originals. Deleting one component can make later pairing impossible.

Support & Tips

More to Read

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.