Open m-georgi opened 2 months ago
I haven't noticed the API change. This explains some issues.
I'm not sure whether this is problematic, but it might be best to check for existing stacks (using searchStacks) first, and only create stacks if none exists yet. This is not yet implemented in my PR.
Thank you for your help! I'm in the middle of restructuring the code... Depending on the progression of our respective works, I'll either merge it to the current version or I'll do the adaptation for the refactored code
Great, sounds good.
I'll try to look into searching existing stacks tomorrow. I made some first experiments with the API, but it's not always behaving as expected (or documented).
@m-georgi have you had luck with solving the existing stacks issue? I'm planning my migration and this might be worth holding off for - or does the standalone stack
command do exactly the same thing as the upload stack options, so I could just run it any time later?
Up to version
0.112
ofimmich
it was possible to create stacks by updating the stacked assets using the/assets
endpoint and providing astackParendId
of the asset that should be used as the stack cover.Starting with
0.113
this field is no longer listed in the API description for updateAsset. Instead the API offers createStack to do this explicitly.I opened a PR #477 that changes the implementation to use the new API call.
Unfortunately it seems that multiple stacks can be created for the same assets by repeating the same call with the same asset IDs. The returned stack response has a new stack ID each time.
I'm not sure whether this is problematic, but it might be best to check for existing stacks (using searchStacks) first, and only create stacks if none exists yet. This is not yet implemented in my PR.