Library: Stack files with vendor-specific naming schemes as used by Apple and iCloudPD

[epheterson]

Describe what problem this solves and why this would be valuable to many users
A fair amount of users backup photos with the iCloudPD docker package, which downloads Live Photos by default. The format used by iCloudPD does not automatically generate Live Photos within PhotoPrism. The issue is similar to #1885, though with a different naming scheme, and can be worked around in the same way by enabling Sequential Names for stacking.

Example filenames –
IMG_0108_HEVC.MOV
IMG_0108.HEIC

Describe the solution you'd like

Ideally PhotoPrism could notice the same image number with unique filetypes and the "_HEVC" appended to automatically create a Live Photo without having to first enable the Sequential Names stacks feature.

Describe alternatives you've considered

Alternatively we can keep things as-is and expect users to discover the feature. Unfortunately even a complete re-index does not stack the photos so it can lead to some data loss to purge/re-index to fix.

[Soulplayer]

I would love to see thix implemented :) (this is the same request as made here)

[lastzero]

@Soulplayer Thank you! I wasn't aware of this issue. The more our project grows, the harder it gets to stay on top of things :)

[lastzero]

As also mentioned in the related GitHub discussion, please note that .hevc.mov vs. _hevc.mov is a major difference which would explain why not all the "extensions" are stripped when comparing names to find related files (it's not an extension then, but a part of the name).

[Soulplayer]

I'll also post it here:
`This is the list of a folder it is _HEVC.MOV and not with .HEVC

-rw-rw-rw- 1 nobody users  1415689 Sep  1 08:13 IMG_1722.HEIC
-rw-rw-rw- 1 nobody users  2733959 Sep  1 08:13 IMG_1722_HEVC.MOV
-rw-rw-rw- 1 nobody users  1590062 Sep  1 08:13 IMG_1723.HEIC
-rw-rw-rw- 1 nobody users  1623035 Sep  1 08:13 IMG_1723_HEVC.MOV
-rw-rw-rw- 1 nobody users  1569422 Sep  1 08:25 IMG_1726.HEIC
-rw-rw-rw- 1 nobody users  2735557 Sep  1 08:25 IMG_1726_HEVC.MOV
-rw-rw-rw- 1 nobody users  1785158 Sep  1 08:30 IMG_1728.HEIC
-rw-rw-rw- 1 nobody users  2081097 Sep  1 08:30 IMG_1728_HEVC.MOV

So the _HEVC. addition causes a problem for the stacking.

Thank you for your development. Proud sponsor!

[lastzero]

As a workaround, you could move all affected files out of originals, run photoprism index & cleanup to purge the index and sidecars for those files, then move them back in with a script that replaces _HEVC with .HEVC, and finally index again to have them properly stacked. Not convenient, but should work.

[lastzero]

Since a lot of people are using it, we'll add a hack (as we did for Apple's _E for "edited") when we have a bit of time, and hope it doesn't break anything. Unfortunately, we're completely maxed out right now working on many different issues/PRs at the same time. If I forget, feel free to send a reminder in 4 to 8 weeks.

[lastzero]

@epheterson @graciousgrey My changes can improve indexing of (related) media files as created by Apple/iCloudPD in special situations, e.g. in case of a partial index update where IMG_1722_HEVC.MOV is changed but IMG_1722.HEIC remained unchanged.

However, I have found that ignoring the _HEVC suffix in video filenames to stack them with related HEIC files (or other media files) is essentially the same as stacking by Sequential Name, see https://docs.photoprism.app/user-guide/settings/library/#stacks.

When I had this stacking option enabled, indexing Live Photos with filenames as used by Apple/iCloudPD worked for me without any issues (unless the files were already indexed):

(a) Contrary to my earlier assumption, this means that it makes no sense to reuse/extend the following function, which is currently used to find additional versions of files edited with Apple devices:

photoprism/internal/photoprism/mediafile.go

Lines 444 to 455 in 54f281a

	// EditedName returns the corresponding edited image file name as used by Apple (e.g. IMG_E12345.JPG).
	func (m *MediaFile) EditedName() string {
	basename := filepath.Base(m.fileName)
	if strings.ToUpper(basename[:4]) == "IMG_" && strings.ToUpper(basename[:5]) != "IMG_E" {
	if filename := filepath.Dir(m.fileName) + string(os.PathSeparator) + basename[:4] + "E" + basename[4:]; fs.FileExists(filename) {
	return filename
	}
	}
	return ""
	}

(b) In addition, I noticed that adding settings for stacking with user-defined naming patterns already seems to be covered by this more general feature request:

• Stacks: Configure regex option for StripSequence  #2566

---

Based on these findings, it seems best (for now) to improve our documentation (e.g., the First Steps tutorial) to include a note on related files created by Apple/iCloudPD, with the recommendation to enable stacking by Sequential Name?

[lastzero]

@Soulplayer @epheterson @graciousgrey After looking at the problem again today, I was able to find an alternative solution that is a combination of the changes I made yesterday and the approach I originally proposed.

An updated preview build will be available for testing soon! ✨