starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

Apple: Support new Live Photo file names #1277

New issue

Open

opened 2026-02-20 00:09:34 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 00:09:34 -05:00

Owner

Originally created by @aniqueta on GitHub (Jan 5, 2022).

What does not work as expected?

I'm pointing my PhotoPrism originals folder to my Apple Photos library, and I've noticed that this results in Live Photos not always stacking in PhotoPrism, meaning there are separate entries for the image and videos in the index. It appears this happens for newly imported photos, and old ones in that have been in the Apple Photos library for a while are handled well.

From researching this issue and how PhotoPrism works, I think it's a result of Apple Photos' naming convention for its library package. Each photo gets a random UUID and is organized in a folder structure based on the first character of the UUID and then mapped to a database, thumbnails, etc. It seems that recently, Apple decided to append _3 to the UUID file name for the video associated with a Live Photo image. So, for example the Live Photo will have two files: DFD48C6B-7A49-49A8-86D6-EECA35ABD59B.heic and DFD48C6B-7A49-49A8-86D6-EECA35ABD59B_3.mov.

My assumption is that since these file names (sans extension) are not exact matches, PhotoPrism does not stack them together. And, given that Apple Photos seems to have not always had this convention, PhotoPrism handles old Live Photos fine, but new ones that do follow this convention with the appended _3 do not get stacked correctly.

How can we reproduce it?

Steps to reproduce the behavior:

Set PhotoPrism's originals directory to the originals subfolder within the Apple Photos Library. This is usually, ~/Pictures/Photos Library.photoslibrary/originals
Start PhotoPrism and index
Browse and notice that Live Photos have two entries, one for the image and one for the video.
Inspect the file names for these to confirm the above naming convention issue

What behavior do you expect?

PhotoPrism stacks Live Photos when handling Apple Photos libraries, and to do this, it would need to match videos associated with images based on having a file name format that is a UUID for the image and then a UUID with appended _3.mov for the video.

I'm happy to help try to code this; I would need some guidance on where this logic should go though, as from a quick search of the code, I cannot find where the matching currently happens in the code.

Can you provide us with example files for testing or screenshots?

I can take and provide some Live Photos without personally identifiable information if needed, but I think the above explanation of file naming covers it?

What version you are using?

Built from source on Dec 29, 2021.

Any other helpful information?

Thanks again for a great project, and I'm happy to help work on this. I suspect I might be the only one using PhotoPrism like this right now, but this is probably useful if/when there's a macOS binary and the average user tries to do something like this.

Originally created by @aniqueta on GitHub (Jan 5, 2022). **What does not work as expected?** I'm pointing my PhotoPrism originals folder to my Apple Photos library, and I've noticed that this results in Live Photos not always stacking in PhotoPrism, meaning there are separate entries for the image and videos in the index. It appears this happens for newly imported photos, and old ones in that have been in the Apple Photos library for a while are handled well. From researching this issue and how PhotoPrism works, I think it's a result of Apple Photos' naming convention for its library package. Each photo gets a random UUID and is organized in a folder structure based on the first character of the UUID and then mapped to a database, thumbnails, etc. It seems that recently, Apple decided to append `_3` to the UUID file name for the video associated with a Live Photo image. So, for example the Live Photo will have two files: `DFD48C6B-7A49-49A8-86D6-EECA35ABD59B.heic` and `DFD48C6B-7A49-49A8-86D6-EECA35ABD59B_3.mov`. My assumption is that since these file names (sans extension) are not exact matches, PhotoPrism does not stack them together. And, given that Apple Photos seems to have not always had this convention, PhotoPrism handles old Live Photos fine, but new ones that do follow this convention with the appended `_3` do not get stacked correctly. **How can we reproduce it?** Steps to reproduce the behavior: 1. Set PhotoPrism's originals directory to the originals subfolder within the Apple Photos Library. This is usually, `~/Pictures/Photos Library.photoslibrary/originals` 2. Start PhotoPrism and index 3. Browse and notice that Live Photos have two entries, one for the image and one for the video. 4. Inspect the file names for these to confirm the above naming convention issue **What behavior do you expect?** PhotoPrism stacks Live Photos when handling Apple Photos libraries, and to do this, it would need to match videos associated with images based on having a file name format that is a UUID for the image and then a UUID with appended `_3.mov` for the video. I'm happy to help try to code this; I would need some guidance on where this logic should go though, as from a quick search of the code, I cannot find where the matching currently happens in the code. **Can you provide us with example files for testing or screenshots?** I can take and provide some Live Photos without personally identifiable information if needed, but I think the above explanation of file naming covers it? **What version you are using?** Built from source on Dec 29, 2021. **Any other helpful information?** Thanks again for a great project, and I'm happy to help work on this. I suspect I might be the only one using PhotoPrism like this right now, but this is probably useful if/when there's a macOS binary and the average user tries to do something like this.

deekerman added the

enhancement

metadata

live

labels

2026-02-20 00:09:34 -05:00

deekerman commented

2026-02-20 00:09:35 -05:00

Author

Owner

@upward4 commented on GitHub (Jan 31, 2022):

Please correct me if I'm mistaken, but shouldn't we rely on file metadata rather than filenames to match live photo pairs? See: https://stackoverflow.com/a/35286486

@upward4 commented on GitHub (Jan 31, 2022): Please correct me if I'm mistaken, but shouldn't we rely on file metadata rather than filenames to match live photo pairs? See: https://stackoverflow.com/a/35286486

deekerman commented

2026-02-20 00:09:35 -05:00

Author

Owner

@lastzero commented on GitHub (Jan 31, 2022):

If you want to strictly limit the functionality to Apple devices, then deep inspection of all metadata as outlined on Stackoverflow makes sense. Note we already stack by unique ID, independent of Live Photos.

At the time we implemented this, our users asked for a simple 3 seconds rule:
https://docs.photoprism.app/user-guide/organize/video/#live-photos

@lastzero commented on GitHub (Jan 31, 2022): If you want to strictly limit the functionality to Apple devices, then deep inspection of all metadata as outlined on Stackoverflow makes sense. Note we already stack by unique ID, independent of Live Photos. At the time we implemented this, our users asked for a simple 3 seconds rule: https://docs.photoprism.app/user-guide/organize/video/#live-photos

deekerman commented

2026-02-20 00:09:36 -05:00

Author

Owner

@vmartinv commented on GitHub (Feb 15, 2022):

Also interested in this. EDIT: the following bash script is a workaround:

cd imports && for f in $(find . -iname *_3.mov); do echo mv $f ${f/_3.mov/.mov}; done

Note: this is a dry-run, remove echo to actually perform the mass renaming.

@vmartinv commented on GitHub (Feb 15, 2022): Also interested in this. EDIT: the following bash script is a workaround: `cd imports && for f in $(find . -iname *_3.mov); do echo mv $f ${f/_3.mov/.mov}; done` *Note: this is a dry-run, remove echo to actually perform the mass renaming.*

deekerman commented

2026-02-20 00:09:36 -05:00

Author

Owner

@tlvince commented on GitHub (Apr 25, 2022):

Please correct me if I'm mistaken, but shouldn't we rely on file metadata rather than filenames to match live photo pairs? See: https://stackoverflow.com/a/35286486

Besides the filename and creation time hints, they can be grouped on "Media Group UUID" on the image and "Content Identifier" on the video:

❯ exiftool -MediaGroupUUID import/FFFEC3A1-7BE2-4FF6-9F4F-BB6708EA7EF0.heic
Media Group UUID                : 4C9FAD49-046A-4267-815B-31E7F7B20A93
❯ exiftool -ContentIdentifier import/FFFEC3A1-7BE2-4FF6-9F4F-BB6708EA7EF0_3.mov
Content Identifier              : 4C9FAD49-046A-4267-815B-31E7F7B20A93

@tlvince commented on GitHub (Apr 25, 2022): > Please correct me if I'm mistaken, but shouldn't we rely on file metadata rather than filenames to match live photo pairs? See: https://stackoverflow.com/a/35286486 Besides the filename and creation time hints, they can be grouped on "Media Group UUID" on the image and "Content Identifier" on the video: ```shell ❯ exiftool -MediaGroupUUID import/FFFEC3A1-7BE2-4FF6-9F4F-BB6708EA7EF0.heic Media Group UUID : 4C9FAD49-046A-4267-815B-31E7F7B20A93 ❯ exiftool -ContentIdentifier import/FFFEC3A1-7BE2-4FF6-9F4F-BB6708EA7EF0_3.mov Content Identifier : 4C9FAD49-046A-4267-815B-31E7F7B20A93 ```

deekerman commented

2026-02-20 00:09:36 -05:00

Author

Owner

@aniqueta commented on GitHub (May 29, 2022):

Also interested in this. EDIT: the following bash script is a workaround:

cd imports && for f in $(find . -iname *_3.mov); do echo mv $f ${f/_3.mov/.mov}; done

Note: this is a dry-run, remove echo to actually perform the mass renaming.

I haven't tested this, but I think it would likely break one's photo library, when PhotoPrism is pointed to a Mac's Apple Photos library. This is my setup, so I don't have a full duplicate of the library and can use both PhotoPrism and Apple Photos.

Anyhow, I have found that turning on "Sequential Name" under Settings -> Library has resolved the stacking issue. :)

Edit: I think it's worth leaving this issue open though, so that the stacking could use the identifiers per above.

@aniqueta commented on GitHub (May 29, 2022): > Also interested in this. EDIT: the following bash script is a workaround: > > `cd imports && for f in $(find . -iname *_3.mov); do echo mv $f ${f/_3.mov/.mov}; done` > > _Note: this is a dry-run, remove echo to actually perform the mass renaming._ I haven't tested this, but I think it would likely break one's photo library, when PhotoPrism is pointed to a Mac's Apple Photos library. This is my setup, so I don't have a full duplicate of the library and can use both PhotoPrism and Apple Photos. Anyhow, I have found that turning on "Sequential Name" under Settings -> Library has resolved the stacking issue. :) Edit: I think it's worth leaving this issue open though, so that the stacking could use the identifiers per above.

deekerman commented

2026-02-20 00:09:36 -05:00

Author

Owner

@Angelmmiguel commented on GitHub (Jul 11, 2022):

Anyhow, I have found that turning on "Sequential Name" under Settings -> Library has resolved the stacking issue. :)

I can confirm this solves the issue! Thanks for the tip 😄

@Angelmmiguel commented on GitHub (Jul 11, 2022): > Anyhow, I have found that turning on "Sequential Name" under Settings -> Library has resolved the stacking issue. :) I can confirm this solves the issue! Thanks for the tip 😄