fix(server): motion photo asset linking & management

[Ynng]

Description

• close [BUG] android motion photos fail to link when asset is uploaded separately #8508
• and close Some Live Photos are Split (Again) #8503
  • link existing motion asset to motion photo if checksum and library matching
  • hide motion asset after linking (isVisible false)
  • prevent cross library motion asset linking
    • refactor getByChecksum to take libraryId instead of ownerId.
• close [BUG] Deleting android motion photos cause storage usage to go negative #8511
  • update storage usage on motion asset creation
  • exclude external library motion asset from storage usage
• close [BUG] live photo video asset of motion photos in external library incorrectly marked offline #8562
  • skip non isExternal assets in external libraries during asset refresh
  • correctly delete external library motion assets

How Has This Been Tested?

Manually tested locally with MP, MVIMG and apple HEIF motion photo formats.
The video portion of each test photo was uploaded first before the image is uploaded.
The video asset is successfully hidden, and motion photo is linked properly.

Also tested with external library. The same motion photo is added to an external library and uploaded through the web gui. Immich correctly created 2 separate video assets.

Discussion

This PR introduces a nuanced approach regarding the handling of video assets from motion photos in external libraries, potentially raising discussion.

Specifically, I mark video assets derived from motion photos in external libraries isExternal = false, despite their library being EXTERNAL. (what a mouthful)

It only makes sense to keep these video assets in the same external library as their corresponding motion photo, even though they are physically stored in the encoded-video folder internally.

I'm interested to hear what your thoughts are

[carloslockward]

Tested this. Seems to be working as intended

[carloslockward]

Should this be done after deleting the old live photo asset asset.livePhotoVideoId?

[Ynng]

The original code was in this order (update livePhotoVideoId before deleting old motion video assets)
I think this works because the livePhotoVideoId update is not reflected in asset immediately.

open to discussion

[carloslockward]

Mhh yeah is see the original has this order aswell. Perhaps I am missing something but I think its wrong. What if the update to livePhotoVideoId happens before reaching the deletion part? It could delete the new livePhotoVideoId that was just updated.

[Ynng]

I doubt that's possible.
We don't re-fetch or update the existing asset object from the database

[Ynng]

Sorry for the back and forth between draft and PR but I think this PR is ready for review

[jrasm91]

Man, this is kind of annoying. It deals with excluding external library quota stuff and also live motion linking changes. Those should be two separate, unrelated pull requests.

[jrasm91]

I spent awhile looking at this pull request, but there are just too many different things going on here for me to feel comfortable merging it. This PR touches library scanning, quotas, live photo linking (several different scenarios here), as well as updates several queries that might have performance implications. I think most of the code is correct, but the way it is all lumped together makes it hard to review, at least for me personally. I'd be much more likely to merge and include it if you would submit separate pull requests for:

1. migrating getByChecksum from ownerId to libraryId
2. linking existing android motion videos (what I think this PR was originally about)
3. fixing offline motion video files for external libraries.

[carloslockward]

I spent awhile looking at this pull request, but there are just too many different things going on here for me to feel comfortable merging it. This PR touches library scanning, quotas, live photo linking (several different scenarios here), as well as updates several queries that might have performance implications. I think most of the code is correct, but the way it is all lumped together makes it hard to review, at least for me personally. I'd be much more likely to merge and include it if you would submit separate pull requests for:

1. migrating getByChecksum from ownerId to libraryId
2. linking existing android motion videos (what I think this PR was originally about)
3. fixing offline motion video files for external libraries.

@jrasm91 Also:
4. Update storage usage on motion asset creation so that deleting motion assets reflects correctly on the storage usage.

[Ynng]

Will split into smaller RPs

[jrasm91]

Awesome, thank you for being understanding.