-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replicate folders + albums from one library to another library (shared library) #1683
Comments
Hello @mschindl See if this ask is identical to yours #887 From it, @RhetTbull built the osxphotos sync option
|
Hi @mschindl OSXPhotos has two ways to do what you're looking for. You can use the The first is the
The second method uses the If you run the following command periodically on each user's Mac, it will create keywords in the form of osxphotos batch-edit --verbose --keyword "{album?album:{folder_album}}" --album "{keyword|filter(startswith album:)|sslice(6:)}" --split-folder "/" This command uses the osxphotos template language to create keywords if an album exists and then uses the template language to extract the folder and album names from the keywords which are then used to create the albums (if needed) and then add the photos to the appropriate albums. There is a limitation that if you remove a photo from an album, the keywords are not removed nor is the photo removed from the album. AppleScript, which OSXPhotos uses to add photos to the album, is not able to remove photos from albums. Photos will all be tagged with these new keywords with no easy way to remove them so keep that in mind before you run this. |
Great explanation and work. It sounds like osxphotos batch-edit will solve my request. Does it works also if same Photos located in multiple Albums? I would expect multiple album keyboards per album in this case, right? I will test it asap and give feedback. |
Yes it will work for multiple albums. Each album would result in a new keyword. |
Great, it works good also with special characters in the names. I'm using following command and removing "--verbose" will not speed up the process. In example it runs for over 10hours for round about 50k pictures/videos. |
This is because the AppleScript interface to Photos is really really slow and that's the only way to modify keywords. If Apple provided a better API, I'd use it but they seem uninterested in allowing users more control over the Photos library. One possible optimization would be to first read all the existing folders and keywords using OSXPhotos then only use AppleScript for the ones that need updating. First run would be slow but subsequent runs would be faster. Once you do the initial run, you can select only photos you've worked with recently or only albums you've added to then run the command on a smaller set of photos. |
I think all my questions are answered. I will close for now. Good to know, processing time per object (photo/video) takes 3 seconds which is in sum for 50k objects 42 hours. Thank you very much for your help! |
I executed the command on an other library (without any folder/album) and if I select only a few objects (pic/vid) then it works well, but if I select the complete library with round about 47k object then I got the message "No photos selected". Any idea why the error is shown? Is it a scaling issue? Selecting just the half of objects then it works as well. |
My guess is AppleScript is timing out getting the selected objects. You'll have to try with fewer photos to see what the limit is. |
It may take me a few days but I'll put together a script to remove the "album:" keywords in case you want to back out of this workflow. AppleScript limitations may prevent this from being tenable. |
If I understand it right then the usage of “album:” keywords will make trouble with future Photos release, right? What is your recommendation to use now? I used batch-edit successfully now, but of course it tooks time. |
I want to give some feedback: Unfortunately it does not scale, because after doing the batch job on the 2nd macOS for 30k objects it will not work for more as 150-250 objects now. (20k objects left) |
Thanks for the additional data. This is helpful. It will be some time before I can incorporate it but I've been doing some hacking on a side project that uses private APIs to do this type of thing natively. I did a test with ~1000 assets and results are much more promising:
|
I tried the "sync" command today because my folder structure is stable and does not change that often. Unfortunately, it creates a new/same album at the top level ("My Albums") and does not synchronize the images in the current folder/albumXYZ where the album already exists or needs to be created. I thought there was only an issue with folder creation. Btw: "-i" is not working and "--import" have to be used, because following error will occur I appreciate your work and I hope to help you with my tests and reports. |
This is a bug caused because
I will open a new issue for this.
I think this is the same as issue #1639. It's nearing the top of my queue but I've been blocked by limited time and working on same major changes to the date/time code in OSXPhotos that will improve handling of timezones but has requited extensive testing and updates to the test suite. Currently, the sync code only considers album names, not folders. |
Have you made progress? Can I give you more information to help you move forward? |
This has been on the back burner. I've been working on a rewrite of the date/time handling code to fix some bug and improve some features of the |
Is your feature request related to a problem? Please describe.
Is there a way replicate albums from one library to another library?
Shared library on both different devices and iCloud accounts in use and 95% of all pictures are stored there.
This feature request came from the use of a shared family library and currently only ONE iCloud has the folder + album structure.
The structure should be available on all devices.
Describe the solution you'd like
Describe alternatives you've considered
Nothing found yet
The text was updated successfully, but these errors were encountered: