Skip to content
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

Easiest way to move video files to a different location? #721

Open
Austinzveare opened this issue Jan 1, 2025 · 3 comments
Open

Easiest way to move video files to a different location? #721

Austinzveare opened this issue Jan 1, 2025 · 3 comments
Assignees

Comments

@Austinzveare
Copy link

I use iCloudPD to get my ProRAW files easily into my Lightroom/Immich workflow, but I'd love to be able to move just the video files into a different folder somewhere else on the system that will still be picked up by Immich, but not clog my Lightroom import process. Is this something that can be done currently? Ideally by specifying the file extension.

@boredazfcuk
Copy link
Owner

The download utility just scans icloud.com for images/videos and downloads whichever are missing from the local file system.

If files are moved elsewhere, the utility will see these as not having been downloaded and will re-download them.

@Austinzveare
Copy link
Author

I understand that, but I use the delete_after_download variable to just pull everything down and delete so I don't run into that issue. Maybe an extension of jpeg_path could do it?

@boredazfcuk
Copy link
Owner

I've just pushed a new container which should add this functionality.

Upgrade to the latest version and you should see three new configuration options appear in your icloudpd.conf file:

sideways_copy_videos=false
sideways_copy_videos_mode=copy
...
video_path=

From the bottom upwards...

video_path is where you want it to copy the videos to. You'll want to make this a persistent mount, or you'll lose everything in that directory when then container is next upgraded/recreated.

sideways_copy_videos_mode can be set to either copy or move and will default to copy. I suggest using copy for the time being, as I've not tested it properly yet. Also, it gives you a bit more protection in case something weird happens. If you set it to move, then delete_after_download has to be set too. This prevents icloudpd downloading all the videos, moving them to the video_path, then not deleting them from icloud, and re-downloading them all again on the next run.

sideways_copy_videos is what you need to enable the feature. Just set it to true and it should start processing them on each download run.

I've not tested any of this, so can't be 100% sure if it will work or not.

However, I've also made a --sideways-copy-all-videos command line switch. Provided a location has been specified in video_path, running sync-icloud.sh --sideways-copy-all-videos will scan your entire download_path location, and copy/move all videos into the target video_path directory. I've tested this (in copy mode) and it works fine. It's pretty much identical to the code that process the files after each download, so hopefully all should be OK.

Some things worth noting...
It currently does not sync deletes, so if a video is downloaded from icloud, copied to the video_path then removed from icloud, it is not removed from video_path
It will replicate the folder structure and owner/permissions of the download path. If the owner/permissions change in the download_folder these changes will not be replicated as these are only set at folder creation time.
At present, it only looks for *.mov and *.mp4 videos. It will ignore all *hevc.mov files, as these are usually the video portion of "live photos", and moving these would basically "split up" the live photo from its partnered .heic file. I may add an "include live photos" switch at some point in the future if there is appetite for it in future. I could also add the option to move the accompanying .heic file if desired.

Let me know how you get on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants