Report metadata (size in bytes, date and time, format) in --dry-run or similar new option

[joeharr4]

It would be helpful to report the file metadata (date, time, size in bytes, maybe format if that's available) in --dry-run, at least as an option. Adding it now might break some scripts, so either tack it onto the end of the existing output (so scripts parsing the existing output don't break) or add another [DRY RUN] or maybe [METADATA] line in the output.

Use case:

I am managing a large series of 4-hour videos taken of events I host. I download these once a year when they fill my 1TB of iCloud storage. It takes all night to pull them down, so I'd like to do some quick planning runs to ensure I have the space to store them locally.

--jh--

[AndreyNikiforov]

How many 4-hour videos fit in 1T storage?

[joeharr4]

Good question! I've discovered that the number of bytes I have to budget on my hard drive for the downloaded video is more than the number freed up when I delete the video. I suspect they have some splufty new (proprietary?) compression scheme that they use internally. Same on Google Drive.

The size of video varies depending on the dimensions, bit depth, frame rate, content (how redundant is it frame to frame), and how much processing power was available at time of shoot to do compression. I'm shooting with a 12 Pro Max in 0.5x mode. My camera is on a tripod in a corner of the room, so redundancy is high. I'm getting about 5GB/4 hours in "medium" size, and about 25GB in "original" size. So, about 40 events fit 1TB of space in "original", and 200 in "medium". I can tell the difference, but I have to look at the details (hair, clothing patterns) to see it.

Any idea why the app saves files as .MOV no matter the format? I know it's legal - MOV is a container that can hold QT or MP4 - but Apple makes it simpler to tell what you have by downloading with .qt or .MP4 as the filename.

The reason I came here in the first place is that the Apple iCloud downloaded .zip file not only has the download date on all the videos and images. I originally thought that it does not have the shoot date in the (very minimal) metadata, but I was looking for the wrong kind of metadata (id3v2, not EXIF). The EXIF is great, actually. That would have killed me if I were trying to find a video from a given event! Now that I know that it's EXIF, I am good with the iCloud download, but this package still makes automating the download a little easier.

The other features I'd like here are renaming the file to include the ISO date in the name (e.g., 2025-06-06T19:23:45-IMG_6789.MOV) and downloading specific files from a list, rather than just albums or everything. I haven't dug enough to know whether those exist, yet. Do they? If not, I'll start separate threads for them. I could consider coding some of these features, but they are the kind of thing that someone familiar with the codebase could sneeze out in 5 minutes, where it might take me 2 days to get into it deeply enough not to mess it up.

--jh--

[AndreyNikiforov]

What is the reason you are downloading assets to your local storage? If it is for backup/redundancy, you may consider running icloudpd more often/all the time; and you would not have to worry about checking for space as you will notice shrinking of your local storage through regular means. If are organizing your assets after downloading, then tools for organization read metadata from assets themselves and you do not need file renaming; there is also --xmp-sidecar option to get metadata into separate file.

[joeharr4]

I have filled my 2 TB iCloud plan and don't want to pay more. I keep the videos from my events in case someone brings a lawsuit. They would document what actually happened. I don't need to look at them ever again unless it happens, so I make two copies on HDDs and forget them. When I started looking at icloudpd, I thought Apple had stripped the metadata. I thought the videos were downloading from iCloud's web app with no date/time info. I was using the wrong app (id3v2, an audio app). I have since found exiftool and have written a script to read the date and time and then rename the file.

--jh--

[AndreyNikiforov]

What I understood so far: you have 40 videos filling 1TB icloud that you need to move to your local drive (to free icloud). The ask is to modify icloudpd to show the size of assets in dry-run mode, so that availability of local storage can be confirmed before the start of the downloading by running prost processing script.

What I don't understand: if you know you need to free 1TB of icloud storage, then with high accuracy you can say that you need 1TB on local storage to fit that volume in without extra dry-run of icloudpd.

Other thoughts/refs:

• calculating size of assets in icloud based on a given criteria may be a general use case. Approach on using dry-run mode with filters and then relying on summary may be more flexible when dumpling metadata for each line item and expect users to post-process that data. ref Add summary at the end of execution process #183
• making icloudpd a platform for post processing metadata is an option too RFC: Extract iCloud communication logic into a standalone proxy #382