Help & Documentation

A workflow built for the DIT and the data wrangler: from the day's folder structure to a verified copy of every card, a proof of parity for production and proxies for the editor.

• Organise the shoot in four levels: data project → shooting day → transfer session → offload. The data project is the long-running record; the shooting day is what changes with every call sheet.
• The Mac app copies the cards itself: it reads each card once, writes every destination at the same time, reads every copy back and writes MHL and ASC-MHL manifests. In a browser you create the folders, verify offloads that already exist, and copy with Offshoot Pro.
• Drives live on the data project and are reused across every shooting day.
• Label a drive (Label on the Drives step) to give it a name of your own, such as Mirror A. It is shown in front of the drive's real name — Mirror A (SSD_2TB) — everywhere the drive appears, including the Verify reports. It never renames the drive or its folder, and saving an empty label removes it.
• Cameras, sound mixer, folder template and reel counters carry forward from one shooting day to the next, so a new day starts filled in.
• Episodes fill in from the linked dashboard project when the data project is linked to one.
• Creating folders never overwrites, renames or deletes anything: folders that earlier days already made are reused.

Data Management is a signed-in Pro feature. Data Projects, shooting days, folder templates, and transfer history are stored per account and synced across your devices, so the wizard needs an account behind it.

• Signed out: the page shows a sign-in card instead of the wizard. Sign in from Settings → Account.
• Signed in on the Free plan: the page shows an upgrade card with a link to the plan comparison.
• Signed in with an active subscription: the full 9-step wizard, transfer history, and settings open normally.
• The lock only hides the UI. Existing data projects, folder templates, and transfer sessions stay stored and synced, and reappear as soon as the plan covers the feature again.

The Mac app runs everything. A browser needs the File System Access API to open your drives, so the page works in Chromium-based browsers only.

• Mac app: every step, plus copying the cards (Copy with verification), auto-assigning connected cards, Verify existing offload with plugged-in drives offered to you, and Proxies.
• Chrome, Edge, Opera, Brave and other Chromium browsers: every wizard step, creating the folders on your drives, and Verify existing offload. Copy with verification and Proxies say that they run in the Mac app.
• Safari, Firefox and the iPhone, iPad and Android apps show “This browser only shows past verifications” instead of the wizard — copying, verifying and proxies need Chrome, Edge or the Mac app — with a checklist: File System Access is required; Web Push, Notifications and Persistent Storage are optional. Below it, Verification history lists your past offload verifications read-only: pick a data project (each shows how many it holds), open a verification to see its results, and export its PDF report or CSV — the same reports Chrome builds.
• In Chrome or Edge, install Cine Power Planner from the address bar (the ⊕ icon) so drive permissions survive a browser restart. Until you do, a banner (Install for persistent drive permissions) reminds you that drives have to be picked again on every visit.

The step bar walks the offload routine in nine steps: Project, Shooting, Folder Structure, Cards, Drives, Review, Create, Transfer and Report.

1. Project — pick a data project or make one with + Create new. Optionally link it to a dashboard project (episodes then fill in from it), and set a default sound mixer and a default folder template.
2. Shooting — the shooting day: its date (Shoot day), Location, cameras, today's sound mixer and episodes. A new day is filled in from the day before it; Apply yesterday’s setup copies the cameras, template, mixer override and target subfolder again.
3. Folder Structure — pick, create or edit the folder template for the day.
4. Cards — list the cards each camera shot today (A001, A002, …) and the sound cards (+ Add sound card). Add one card per camera adds a card for every camera that has none yet. Reel numbers continue across days, and a reel you override carries forward.
5. Drives — add your destination drives (Add drive) and label them if you like. They stay on the data project for every shooting day; pick one again only when it shows offline.
6. Review — the folder tree with every placeholder filled in. Merge into existing structure appears when earlier days already wrote folders to these drives. Shoot details shows the day's Location — type or change it right there; if the template uses {{location}} and none is set, a warning says those folder names will leave it out. Anything listed under Resolve before continuing stops Next until it is fixed — for example two cards with the same label: rename one on the Cards step, because a copy is recorded under its card's label.
7. Create — Start creates the folders on every online drive. Folders that already exist are reused and never changed; offline drives are skipped and say so, and Retry failed tries the drives that failed again.
8. Transfer — copy the cards with Built-in copy (Copy with verification, Verify existing offload, Proxies) or on the Offshoot Pro tab. The tab you pick is remembered per data project.
9. Report — the day’s shooting report (Drehbericht): cameras with their settings, cards with clip counts, timecode, sound and audio tracks, notes. Download PDF saves it; Save PDF to drives writes it next to the footage on every destination drive.

Four built-in templates ship out of the box: Commercial Shoot, Feature Film, Documentary, Stills / Photo. They are read-only. Custom templates sync to the cloud so the same structure appears on every signed-in device.

• Built-in presets cover the common offload structure (Camera/A_CAM, Camera/B_CAM, Sound, Proxies, …).
• Your own templates are listed first. Built-in presets sit below under Presets, collapsed once you have templates of your own; each shows its folder count, and Preview expands the full folder tree before you pick it.
• Click New template to author your own. The editor is a tree view: Add root folder adds a top-level folder and Add child nests one under another. With the keyboard, the arrow keys move through the tree, Enter renames, Delete removes and Insert adds a child (Tab leaves the tree).
• Insert dynamic placeholders to keep folder names per-shoot: {{date}}, {{shootDay}}, {{projectName}}, {{episodeName}}, {{cameraName}}, {{cameraLetter}}, {{reelNumber}}, {{location}}. {{cameraName}} is the camera name you entered under Cameras on the Shooting step (e.g. ALEXA 35), {{cameraLetter}} its letter (A); renaming a camera there also renames its folders. {{location}} is the Location field on the Shooting step: it is filled in with the city you are in (a city name, never coordinates) when the day has none — on whichever step the day opens at — and a failed lookup is retried the next time you open the day. Only today’s day is filled in, and only until its folders are created, so existing folder names never change on their own. You can overwrite it, change it on Review, or press Use current location to detect it again. A blank location resolves to nothing. A folder name cannot start with a dot: Finder hides such a folder, so the editor and Review refuse it.
• Use Duplicate on a built-in preset to start from one of the presets without losing the original. Export saves a template as a file and Import reads one back, so you can hand a structure to another DIT.
• Closing an editor you have changed asks before discarding. The backdrop, Escape and Cancel all lead to the same question, and it counts the folder tree — nesting, renaming or deleting a folder all count, not just the template name. A template you opened without touching still closes on the first click.

How the Shooting and Cards steps save your edits, what archiving a Data Project keeps, and what the transfer history does with deleted sessions.

• Text fields on the Shooting and Cards steps save when you leave them (click elsewhere, Tab or Enter); Escape undoes the edit. Clearing a required field such as a card label to retype it is fine — left empty, the previous value comes back.
• The Shoot day date opens the day once you pause typing, leave the field or press Enter. A date with no day yet — and today, when you open the wizard — opens as a new day that is stored only once you change something or continue past the Shooting step.
• Day numbers follow the dates: adding an earlier date, deleting a day or restoring one renumbers the other days, and a notice lists them. Days that sync in from another device or a team member renumber them too; that notice names only days whose folders exist. A day whose folders are already created keeps using their number for new folders and for the Transfer step, so its cards stay in one tree; Use new numbers in the notice switches those days to the new number (create the folders again before copying).
• Camera letters are one letter A–Z, stored upper-case and unique per day; S is reserved for sound. The field says why it refuses anything else.
• Cards whose camera or mixer you removed stay listed under “Cards without a source”. Folders are still created for them, so remove any you no longer need.
• A step you cannot open yet names the first thing still missing on the way to it.
• Archive hides a Data Project with its shoot days, sessions and offloads; Restore in the archive view brings all of them back, so reel counters and day numbers continue.
• Transfer history: Delete moves sessions and their offloads to Trash (with Undo), and only rows the current filter shows are deleted. Edit sets the shoot date with a date picker; it is the date the report uses.
• Transfer history records itself: creating the folder structure or finishing a card with the built-in copy opens the day's session; each card is recorded with its file count, and the session completes once every card on the Cards step is copied (or fails with the card).
• The history is sorted by shoot date. Deleting from a session's own page asks first. Restoring a session from Trash also restores its deleted shoot day; if the project is archived or another day now uses that date, you are told why. A session opened from Trash shows a Trash banner with Restore only. Each session counts the files that did not match the source as verification issues, and Drives lists where the cards were actually copied.

A new shooting day in an existing data project starts with these fields filled in from the most recent day before it:

• Cameras (letters and names).
• Reel counters — they continue across days, per camera and data project.
• Today's sound mixer, if the day before had one of its own.
• Folder template — the day keeps its own copy, so a teammate without that template can still continue.
• Target subfolder pattern.

A data project can be linked to a dashboard project. Set it in the data project's editor (+ Create new, or Edit in the picker) under Linked dashboard project (optional), or leave it on — Unlinked —.

• Linked: episodes fill in from the project, the data project's shooting days appear in the project's Daily Shooting Report tab, and Proxies can take scene and take from the project's camera log. A data project linked to a shared project is shared with that project's team — see the next section.
• Unlinked: for offloads that belong to no project in the app. Type the project name on the Shooting step so it shows up in folder names and reports. Copying, Verify existing offload, Proxies, the Shooting Day Report and Transfer history all work the same.

A data project linked to a shared project is shared with that project's team, with the same roles.

• Editors see the data project on their Data Management page and in the project's Daily Shooting Report tab, and can work in it. Shooting days, transfers, offloads and verifications sync to the whole team.
• Viewers see it read-only: a View only notice sits at the top of the page, and every step after the project picker is disabled. A session's detail page shows the same notice, and Regenerate report is the only action it offers.
• A shared data project shows a Shared badge in the project picker, also after a reload and offline. Only the project owner can change which project it is linked to, and only the person who created it can archive it, because only they can restore it.
• Offload, transfer and verification paths are shared, so the team can see where the copies are. Drive permissions, remembered drive locations and folder templates stay with you. A shoot day keeps a copy of its folder template, so a teammate without that template can still continue on the Cards step.
• When someone is removed from the project, the shared data projects disappear from their devices. When the owner unlinks one data project, a teammate's device removes it, with a notice, the next time it tries to save a change to it; until then their old copy stays, but nothing changed in it is shared. Work that had not synced yet moves into a private data project named “… (recovered)”.

In the Mac app, Transfer → Built-in copy → Copy with verification is a three-column board: the cards you declared on the left, every connected drive in the middle, your destinations on the right.

Drag a drive where it belongs

— Drag a drive from the middle column onto a card slot to make it that card's source, or onto the destinations to copy onto it. On a wide window the middle column stays in view and scrolls on its own, and holding a dragged drive near the top or bottom of the window scrolls the page to cards further down. Without a mouse, click a drive (or press Enter) to pick it up, then click “Place … here” on the target; Esc puts it down. A drive has one role at a time, so moving it elsewhere takes it out of its old role. Read-only drives cannot be destinations, and neither can this Mac's startup disk itself — pick a folder on it with “Add a folder…” instead.

Every card gets its own folder

— Each slot shows the folder the card will be copied into, taken from the same folder template and names the Create step used, and the full path on every destination. A template folder with {{reelNumber}} is used as is (260928_A7cii_C_Karte_001). A camera folder such as A_CAM gets one sub-folder per card (A_CAM › A001), and sound cards go into the sound folder. A template without a sound folder gives a sound card its own card folder, with the sound mixer's name in place of the camera name. Two cards never share a folder. Click the pencil to choose a different folder for one card. A folder you type that is another card's folder, contains it or lies inside it blocks Start until you change it; upper and lower case and the way an accented letter was typed make no difference.

Your Drives-step drives

— The drives you chose on the Drives step are the default destinations. They are found on this Mac by name; a drive that isn't found shows “Not connected” and is skipped. Drop the drive on it, or use Locate…, and this Mac remembers where it is. Untick a destination's checkbox to leave that drive out of one offload.

Start, and what it tells you first

— The button names the offload (“Start offload — 3 cards → 2 destinations”). While it can't start, the reasons are listed above it. A destination that looks too small for the cards on it is flagged before you start.

While it runs

— Cards are copied one at a time in slot order, each onto every destination at once. A failure or Cancel stops the run, and the later cards are not copied. Resume (also after Cancel, once the card was read) skips what is already verified and carries on with the rest; it stops if a different card is in the reader. Leaving the step or reloading the page does not stop the copy: the run list comes back with the current card's progress. The Mac does not go to sleep while a copy runs (the screen can still turn off; closing the lid still sleeps it). If the Mac app was quit mid-card, that card offers Resume, and the cut-off attempt is listed in the Copy log as stopped. A card that had failed before the reload comes back with the same failure and its file list. When everything is done, each card has its own result and Eject button.

What a copy includes

— Put the card itself into the slot, not a folder inside it. The copy skips the bookkeeping macOS and Windows put on every card (.Spotlight-V100, .fseventsd, .Trashes, .DS_Store, ._ files, and Offshoot's .hedge-enabled marker) and copies everything else. In the Mac app a card with no files on it is not copied: the copy stops and says so instead of reporting an empty copy as verified. The card is read once and every destination is written at the same time; each file is verified while the next one copies, read back from the drive itself rather than from memory. Photo and sound cards with thousands of small files copy several of them at once. Every copy keeps the card's file dates and its whole folder structure, empty folders (such as Sony's PRIVATE/M4ROOT/SUB) and folder dates included.

One folder holds one copy

— Two destinations that point at the same folder — a drive you told the board is another drive, or two drives with the same name — count once, and the second says why it is skipped. Destinations are locked while an offload runs. A card from one camera is never put into a folder named for another camera, and sound cards never go into camera folders.

• Verification, above Start: Re-read card and destinations (recommended) reads the card a second time and every copy back from the drives, so it catches a card read error as well as a copy that landed wrong — use it before formatting a card. Re-read destinations reads only the copies (faster on a slow card, but a card read error is not caught). Copy only reads nothing back. If the card reads differently the second time, do not format it; copy it again.

What it proposes

— In the Mac app, once you have declared your cards on the Cards step, the app reads the clip names on every connected card (names only, never the footage). A card whose clips name one of your cards is proposed right in that card's slot, even when the card is mounted as “Untitled”. Nothing is copied until you press “Use it” (or “Use all suggestions”), and you still press Start.

How it decides

— In order of trust: a clip filename on the card that names one of your cards (A001C001… is card A001), then the card's own volume label, then a camera name like “B CAM” when that camera has exactly one card that day. What is on the card beats what it is called — a volume label is stale the moment a card is swapped.

What it refuses to guess

— A drive it cannot place is never guessed: its tile in the middle column says why — the evidence points at more than one card, nothing on it names a card, or two connected drives both claim the same card. The clips outrank the label: a drive whose clips belong to a card that is not waiting for a source is not proposed by its name either, and its tile says which card the clips belong to. In that last case neither is proposed. Drag such a drive onto its card by hand.

Cards you have not declared

— No proposal appears until the Cards step has cards on it. You can still drag any drive into Sources; the suggestions only speed things up.

A camera that loses power mid-take leaves the take on the card without its index. Copy with verification (Mac app) and Verify existing offload both warn about these files as soon as the card is listed.

What is recognised

— Sony Alpha and FX cameras (FX3, FX30, FX6, a7S III …) leave a .RSV file in place of the .MP4 or .MXF. Panasonic Lumix cameras leave a .MDT file. Canon EOS R and Cinema EOS cameras leave a .DAT file in the clip folder, or a .DAT and .DMV pair. A clip file of 0 bytes is flagged for any camera. A clip that kept its normal name is recognised from its content: an MP4 or MOV with footage and no index (DJI, GoPro, Atomos, Blackmagic), and a WAV whose length was never written.

Where the warning appears

— In the Mac app, above the Transfer board for every connected card and every folder assigned to a card slot, before you press Start. In Verify existing offload, on the card's row as soon as the card has been listed, while it is still being hashed.

What to do

— Do not format the card and do not record on it. Copy it first: the file is copied and verified like every other file. Then repair the copy, for example with Wondershare Repairit; the button in the warning opens its website. Sony cameras may offer to recover the clip when the card is put back in, newer Lumix cameras have Video Repair in the Playback menu, and Canon cameras may offer it when you play the clip.

Where it is recorded

— The warning stays with the archived verification and shows again when you open it in the history. The PDF report lists the files under “Unfinished recordings on the cards”, and the CSV names the kind in its last column. In the Mac app, the card's Copy log entry lists the unfinished recordings that were copied.

What it does not do

— The warning never blocks a copy and does not change a verification's verdict. For clips that kept their normal name the app reads only the first header bytes; a file it cannot read is not flagged. A card too large to search completely says so.

Every card on the transfer board shows whether it is copied, and every copy is recorded in a log that syncs to your account as proof.

Grey, brand colour, green, yellow, red

— Grey: not copied yet or waiting. Brand colour: a drive is assigned (the slot shows the drive, an arrow and the card folder), suggested, or copying now. Green: copied, and every destination was re-read from the drive itself and matched. Yellow: copied without verification, or the Mac app could not confirm that a re-read came off the drive and not from memory (copy the card again before you format it), or a destination drive did not confirm that it wrote the files out of its own cache, which is common on network shares (eject it properly and check the copy with Verify offloads), files with the same name kept beside ours, a manifest not written, or a copy that was stopped and can be resumed. Red: the copy failed (a read or write error, or a checksum mismatch). A copy that does not read back as written is renamed to <name>.cpp-mismatch on that drive, so the clip's own name never holds a bad file; Resume copy writes the clip again. The strip at the top shows every card of the day in the same colours.

The board stays during a copy

— After Start the middle column shows Transfers: one row per card, source → destination drive and card folder, with a bar that turns green, yellow or red when the card is done. Switch back to Connected drives at any time. The card slots are locked until the run ends.

The copy log

— Every copy attempt goes into the shooting day's Copy log, newest first, synced to your account. Open it from the session in Transfer history (on the Transfer step it is listed below the copy tabs, whichever tab is open). Each entry holds the card, source and fingerprint, every destination with its MHL and ASC-MHL manifests, how it was verified, files and size, a SHA-256 run digest over the copied files (a copied ascmhl history left out, as in the manifests), who copied it on which device and app version, and any error. Download log (CSV) exports it for the production. A card's colour comes from this log, so it stays after New copy, a reload and on your other devices.

A running copy, card check or re-hash says how long it has left, how fast it goes, and counts what it has done.

What the run shows

— Above the transfer rows: the time left for the card being copied, the whole offload's time left when more cards are queued, the current speed and the bytes done across all cards. On the running card: files and bytes copied, and files and bytes verified when verification is on (the re-read runs one file behind the copy).

It follows the drive as it is now

— The estimate uses the recent speed, not the average since the start. When a drive slows down half-way (an SSD out of its fast cache, a busy hub) the time left follows within about half a minute and says the drive slowed down. When nothing moves for a few seconds it says for how long.

It learns from its own mistakes

— After every card that copied cleanly, the app records how far off its estimate was at 10, 25, 50, 75 and 90 % of the card, for each combination of card type, destination drives and verification setting, and corrects later estimates at the same point. It also learns the fixed time at the start (reading the card) and the end (writing manifests). When a correction is applied the readout says so. Failed, cancelled and resumed cards teach nothing. What it learned stays on this device, as speeds and timings only.

Queued cards and "at least"

— Queued cards are timed from the space used on them. A queued folder that can't be measured makes the whole offload read "at least".

Verify offloads

— The Cards heading counts cards checked, running and queued. A card being hashed shows files and bytes hashed, speed and time left; Re-hash drive copies shows bytes, speed and time left.

Before you press Start, the Mac app checks how each card and drive is connected, tests its speed for a few seconds and says what will limit the copy.

What it checks

— Under each tile in Connected drives: the connection speed of the cable or port, a short speed test (a read on a card; on a destination, once a card is placed for copying, a small test file that is removed again), read/write errors during that test, and a comparison with earlier tests of the same drive, reader and card on this Mac.

Connected slower than before

— "Connected at 480 Mb/s; on this port it reached 10 Gb/s before. Check the cable." The drive or reader was faster on this very port, so the cable is the first thing to swap. If it was only faster on another port, the note says so and is a hint, not a warning. A drive or reader this Mac sees for the first time has nothing to be compared with yet.

Slower than usual

— The speed test came out clearly below what this card in this reader, or this drive, usually reaches. The first three tests of something new only record its speed, separately for each connection speed; nothing is compared yet. Against cards or drives of the same type it is only a hint. Repeating a slow test does not make it the new usual; after three slow tests across a day it is, and the note then says what the drive used to reach. A card you formatted in camera is compared with cards of the same type.

Expected copy speed

— Above Start, per card: "A001: up to 92 MB/s, limited by the card. At that speed, everything on it takes about 45 min (without verification)." The copy runs at the speed of its slowest part. A warning about a part that does not limit the copy is shown as information only.

During and after the copy

— If read or write errors appear on a card or drive while it is copied, the run says so. If a copy stops because a drive dropped out, the run says how that drive is connected now, for example at USB 2 speed.

What it cannot tell you

— It cannot see a cable that works now and fails ten minutes later, it knows nothing about Thunderbolt connections, and a short test cannot see an SSD slowing down once its fast cache is full. "No finding" names what was checked; it is not a guarantee.

The Mac app never overwrites footage on a destination. What it does with a file that is already there depends on whether it is the same file.

• A file with the same name, size and checksum as the one on the card is the same footage — from an earlier run, or a copy you resume. It is kept, counted as verified and reported as already copied and skipped.
• A file with the same name but different content — typically another card's A001.mov in the same folder — is kept untouched. The new copy is written beside it with .1 added to its name, and no manifest is written for that card. The card turns yellow (Copied — needs a look); check those files before you erase the card. The same happens when a card holds two files whose names the destination drive treats as one name (for example names that differ only in upper and lower case): the first keeps its name and the second gets .1.
• Every card gets its own folder from your folder structure, and two cards never share one, so this normally happens only when you typed a folder by hand or the drive already held another shoot.
• A copy you resume, or start again after Cancel copy, first checks that the card in the reader is the one it started with, and stops if it is not.

What the failure messages mean, and the one thing not to do next.

• A copy that stops without reporting is not a copy that finished. Files can already be sitting at the destination and still be incomplete, so the card is the only intact copy until you have copied it again and seen it verified.
• “The copy process stopped unexpectedly” means the copy process ended before it could report anything, and the notice under it says Do not erase the card. It shows the exit code — quote it if you report the problem.
• Copying again is safe and is the right next step: Resume copy skips every file already copied and verified and carries on, and nothing already on a destination is overwritten.
• Several cards in one offload are copied one at a time, in slot order, each to every destination in the same pass — copying two cards at once would only make them compete for the same reader and the same drive.
• If a card fails, the run stops there. The cards after it are not copied, and the run says so instead of skipping over them. Fix the problem and start the copy again.

Pick the Offshoot Pro tab on the Transfer step when Offshoot copies the cards. You run the copy in Offshoot itself; Cine Power Planner creates the folders it copies into and, with the hook set up, records what Offshoot reports.

1. On the Transfer step, pick the Offshoot Pro tab. The tab you pick is remembered per data project.
2. In Offshoot, add the card as the source and the folders the wizard created on your drives as the destinations.
3. Click Start in Offshoot.
4. With the hook set up (next section), the Transfer status panel on this tab counts the cards and the verification issues Offshoot reports.

To see Offshoot's transfers and verification issues inside Cine Power Planner, set up the Offshoot hook. Offshoot runs it with its built-in scripting engine, which only Offshoot Pro includes.

1. On the Offshoot Pro tab, open Set up the Offshoot hook and click Download Python hook. It opens Settings.
2. Turn on Offshoot integration. Under Webhook bearer tokens, name the token if you like (for example DIT MacBook) and click Issue token. The token is shown once; right below it, Download script saves cine-power-planner-notifier.py with your webhook address and token built in. Do not share or commit this file — it contains a secret.
3. Move it to Offshoot's Scripts folder (macOS: ~/Library/Application Support/Hedge/Offshoot/Scripts/, Windows: %APPDATA%\Hedge\Offshoot\Scripts\).
4. In Offshoot → Preferences → Scripts, register the file for all three events: File Copy Completed, Verification Issue and Transfer Finished.
5. Click Test connection next to the token to check that the hook reaches the server. From then on the Transfer status panel follows what Offshoot reports.

In Settings, with Offshoot integration on, click Enable notifications once and approve the browser prompt. When an Offshoot transfer finishes or reports a verification issue, you get a system notification in your app language that says what Offshoot reported — a failed transfer is announced as failed. Clicking it opens Transfer history. Turn off transfer notifications mutes only these transfer alerts on this device; the app's other notifications stay on.

The Report step is the day’s shooting report, filled in for you as far as the clips allow. Camera settings, clip counts and timecode are read from the cards themselves; you add what no clip knows — sound track assignment, scenes, notes. The same report opens in the project’s Daily Shooting Report tab.

1. Copy the cards on the Transfer step. In the Mac app every card is read as soon as its copy finishes: the clip count comes from the copy itself, and the camera model, codec, resolution, frame rates, colour space, gamma, ISO and timecode from up to 40 of its clips on the backup drive.
2. Cards checked on the Verify existing offload tab are read the same way — open the Report step (or press Detect again) and their results come in, matched to the card by folder name.
3. For a card copied elsewhere, press Read card… on that card and pick the card or its folder.
4. Open the Report step (Open shooting report on the Transfer step). You can do that while cards are still copying: the queue keeps running and the next cards start on their own. Each camera’s strip is filled from its cards; a camera that changed frame rate shows both, e.g. 25 / 50. Fields filled this way say Detected under them.
5. Add the audio tracks per camera (Source and Channel — what is on each camera channel) and the recorder’s tracks in the Sound section. A recorder that writes iXML track names lays the tracks out for you.
6. Download PDF, or Save PDF to drives to put it into the day’s folder on every destination drive. A drive that is not connected is listed as skipped.

Transfer → Built-in copy → Verify existing offload shows that every card is on every drive and exports a proof of parity: it compares the hash lists on the drives with each other and with a fresh hash of each card. The files on the drives are read again only by Re-hash. A transfer that the built-in copy wrote without reading the drive back shows an amber note, copied without read-back — re-hash recommended, on its row and in the PDF until you have re-hashed it. It only reads — nothing is written to a card or a drive. It opens folders, so it needs Chrome, Edge or the Mac app.

Connect the drives

— Add every drive the cards were copied to; the drives of the current Data Project are added for you. They stay connected while you swap cards. Each drive is searched for MHL v1.1, ASC-MHL and Offshoot transfer logs, so copies made by Offshoot, ShotPut or Silverstack are found too.

Connected drives (Mac app)

— In the Mac app, a drive you plug in while Verify offloads is open appears under Destination drives as a suggestion with its name and size. Add puts the whole drive into the verification and searches it at once — no folder to pick. Not now hides it until you unplug it and plug it in again. Cards in a reader and this Mac's own disk are never suggested. A drive added this way reconnects by itself after you unplug it, reload the page or restart the app; its clip pictures come from macOS QuickLook, and Re-hash drive copies hashes it in the Mac app itself, at the drive's own speed.

One row per transfer

— Every manifest becomes one row, named by the folder it was copied into (a card called “Untitled” is shown with the folder above it); the same transfer on two drives is one row. “Other drive” (only with more than one drive) turns green when every drive holds the same files with the same hashes, red when one is missing or different. “Against card” stays empty until you plug in that card. Neither turns green while a drive of the session is unplugged, and a result stops counting when a rescan finds the copy changed.

Plug in the cards

— “Cards (sources)” sits directly under “Destination drives”. Add a card, or several at once — they queue. Each card is hashed once, matched to its transfer by its file paths or its hashes, and checked against every connected drive. While it is hashed, the matched transfer reads "checking against card … %". Cards and drives are hashed in the background, one worker per card or drive, so a re-hash reads every drive at its own speed. Swap in the next card; the session remembers every card you checked, and adding one that is already listed checks it again instead of listing it twice. A transfer whose manifest lists several cards (one manifest for the whole day) turns green only when every one of them was checked; until then it reads "card … matches — not checked yet: …". In the Mac app the check keeps running at full speed while the window is minimized, and the Mac does not go to sleep until it is done; in Chrome or Edge, keep the tab visible, because the browser slows down a tab you cannot see.

Recording standards and timecode

— Details shows what the clips were recorded in — frame rates (several if the card mixes them), resolution, codec, colour space, gamma, camera — and the first and last timecode of the first and last clip. Re-hash reads every copy again when the manifest alone is not enough — only while the transfer's card is connected: add the card under Cards first; a card put away with Done — next card, or unplugged, leaves Re-hash greyed out.

Clip pictures

— Each transfer shows its first and last clip — name and timecode — and a picture of both from every drive copy, plus from the card once it has been checked: always a frame decoded from the clip itself — MP4, MOV and MXF (Sony XAVC, Canon XF-AVC, Panasonic AVC-Intra), never the preview still a camera saves beside its clips (Sony THMBNL, DJI MISC/THM, GoPro THM), so a copy that holds the still and not the footage cannot look complete —, a sound recorder's WAV take as its waveform (one lane per channel), else the format with “no preview” (BRAW, R3D, ARRIRAW, ProRes in MXF). A clip that gave no picture because it could not be read at that moment (a busy drive) is tried again a little later, up to three times. A drive that does not hold the clip says “Not on this drive”. Each drive and the card show their clip count, and a line under the pictures says “Clip count matches” or “Clip counts differ” with every count. The top of the screen counts drives, transfers, how many the drives agree on and how many a card confirmed; each row's coloured edge turns green once drives and card agree, red on a difference, amber when incomplete. A previous verification shows names and timecodes without pictures. A card under Cards shows its own first and last clip as soon as it is plugged in, while it is queued or being hashed.

Data and cameras

— Under the tiles at the top, Data shows how much each drive holds, how much each card carries, the footage itself (each transfer once) and all drives and cards together, as a size and as the exact number of bytes with the file count. Cameras sums up every camera: model, cards, clips, data, the time it rolled and what it recorded in. A matched card's row under Cards shows what it was recorded in. Every transfer, card and camera also counts its files by type (for example 34 MOV · 34 XML · 34 JPG · 1 ARW).

Filter by shooting day and camera

— Above the transfers, pick one or more shooting days and cameras to show only their transfers; none picked shows all. A drive often holds several shooting days, so every transfer shows the day it was detected on: from the folder names on the drive — a folder starting with a date (20260928_…, 260928_…) or naming a day (Day_02, DT03, Drehtag 4) — and, when no folder says, from the recording date the camera wrote into the clips; hover the day to see which. The project's shooting days name it, so a Day_02 folder and a folder dated that day are one choice, shown as “Day 2” with its date, and the day you are working on is marked “current day”. The camera comes from the letter in the card folder (C-Cam_Karte_1 → C camera), else the camera model read from the clips. Show all clears it. The PDF and CSV reports follow the filter: they hold only the transfers shown, with their timeline warnings and cards, say so at the top, and carry the day in the file name when one day is picked — pick the current day to hand in that day's report. “Report the whole session” under Session and report clears the filter; New session always keeps the whole verification. Gaps and early ends in the timeline warnings are judged within one shooting day, never between two.

Timeline warnings

— A soft warning is raised when a card number is skipped, when one camera stops for more than 20 minutes while another keeps rolling, or when one camera ends more than 30 minutes early — the signs of a card that was never copied. A sound recorder is named Sound, not as a camera. Open Details under a warning to see each camera and the sound on the day's clock with the stretch in question shaded, and every card around it with its times, clips and first and last clip. Check it by hand, add an optional note and press Checked manually — accept; the note goes into the report.

The report

— PDF is the proof of parity for production. It opens with an overview: one verdict for the whole report (all match the hash lists, all verified with the drives read again, attention, or not complete), the figures, bars for drive parity, the card checks and the warnings, an index of every transfer with its three verdicts, the files that need attention, the drives, the cards with when and how fast each was checked, the cameras, and what each check proves. A transfer is complete only when the drives agree and its card was checked on every drive; the report says "verified" only when the drives were also read again with Re-hash. Then every transfer has its own section with recording standards and every file with its hashes; a file that fails is tinted. Each transfer shows its first and last clip on every drive and on the card side by side — a picture, the name and the size to the byte — so a copy that stopped early shows on paper; keep the drives and the card plugged in while it is built. CSV has one row per file per drive with every hash; a drive that does not hold a transfer at all gets its own rows, marked not-on-drive. The session is kept on this Mac across a reload or an app restart; the drives are scanned again and a result counts again only if that copy is unchanged. A card that was still being checked comes back interrupted — Check again. New session starts over while keeping the drives, and keeps the finished verification under Previous verifications.

Previous verifications

— New session keeps the verification you just finished under Previous verifications, against the open shooting day — a day can hold as many as you run. They are synced to your account as a backup and appear on your other devices. Grouped by shooting day, each opens and closes on its own and shows its transfers, marks, warnings and cards exactly as they were, read-only; export its PDF or CSV again, or delete it. Deleting a shooting day takes its verifications with it. In Safari, Firefox and the iPhone and iPad apps the same list opens under Verification history on the Data Management page, read-only (no Delete), with its own data-project picker. A verification too large to keep every file hash keeps its verdicts and counts but offers no CSV, and New session asks first if it was not exported.

What a check vouches for

— A card check or Re-hash only vouches for the drives it read: a drive added later, or offline during a re-hash, reads "not checked on …" / "not re-hashed on …". A drive unplugged during a re-hash reads drive not connected (amber), never corrupt. A drive that could not be searched completely — too large, or a folder on it would not open — says so and reads amber instead of reporting files as missing. A file an ASC-MHL history or an Offshoot log records as failed shows as recorded as failed and never passes a re-hash. Mac ._ files and manifest files listed in manifests and a card's own ascmhl/ folder are ignored, and accented names match however they are stored. Two files whose names differ only in upper and lower case count as one path, so only one of them is checked: such a transfer says so, reads amber, and its re-hash ends incomplete.

Compare first and last clip

— In Verify existing offload, once a card has been checked, open its first and last clip next to every drive's copy, each with its hash. This is where a copy that stopped before the last clip, or wrote a short last clip, becomes visible to the eye.

It works on formats nothing can play

— Parity comes from the hashes, never from the picture, so an ARRIRAW, RED or BRAW card is checked exactly as thoroughly as an XAVC one. Where the browser has no decoder, the cell names the format instead of going blank; the camera's preview still is never shown in its place.

Clips per card

— When the built-in copy engine finishes a card, the number of files it copied and verified is written onto that card on the Cards step, and appears on the Shooting Day Report. A run that was cancelled or failed writes nothing rather than a zero — an empty field means “unknown”, and zero would mean “the card was empty”.

Read from card

— In the project's Daily Shooting Report tab, each camera has a “Read from card” button. It reads one clip's metadata — codec, resolution, sensor FPS, ISO/EI, colour space, gamma — and offers what it found. Nothing is written until you press Apply, and only the fields the clip actually carried are filled, so anything you typed by hand survives. Sony and Blackmagic sidecars are read first because they are the cheapest and most complete; QuickTime and MP4 clips are read from their header. ARRI, RED and Canon Raw cannot be read and say so.

Transfer → Built-in copy → Proxies turns verified offloads into small, timecode-accurate proxies for the editor. The Mac app drives DaVinci Resolve Studio 21 or newer in the background; in the browser the tab explains where it runs. Each proxy keeps its original's name, frame rate, aspect ratio, start timecode and audio tracks, so it relinks to the camera original.

Resolve status

— The badge shows whether Resolve is ready. If Resolve is open with its window, save and quit it: the app starts its own copy in the background and quits it when done. While a run uses that copy, Resolve's own icon opens no window; quitting this app mid-run quits the copy too, and one left by a crash is quit at the next start. If it says “Allow scripting”, set Preferences → System → General → External scripting using to Local. The free edition cannot render in the background. If hardware decoding is off in Resolve (Preferences → System → Decode Options), a warning says so: H.264/H.265 originals then render several times slower; turn it on, quit Resolve and press Retry.

What to render

— Pick one or more shooting days; only verified copies are listed. When a day is on several drives, choose which one to read from — the proxies are written there too. “Add folder…” takes any folder as its own day; its cameras appear under Look after “Check clips”. Cards copied with OffShoot or Hedge are recognised by their transfer log: each card folder is one card, and the camera named in it (…_FX3_B_Karte_001) sets the camera. Clips are grouped by recording date so timecode never mixes, and images are ignored.

Format for the editor

— Avid Media Composer (DNxHR, MXF OP-Atom in Avid MediaFiles) is recommended. Avid (older versions) uses DNxHD, always 1920 × 1080: non-16:9 clips get black bars and some frame rates are skipped. ProRes suits Premiere, Final Cut and Resolve; Review makes small H.264/H.265 files with stereo sound, encoded by the Mac's hardware encoder. Quality, resolution and (for H.264/H.265) bitrate are per codec. The size estimate follows every change: GB per hour at the resulting proxy size before “Check clips” (for UHD 25p clips), the total and length of your footage after it. The total is checked against each drive's free space.

Sichtwurst

— Instead of one proxy per clip, “Sichtwurst — one file per day” puts every clip of a day, sorted by camera and timecode, into one file — for viewing, not for relinking.

Look

— Log footage is converted to Rec.709 per camera, suggested from the clip metadata (for example S-Log3 on Sony). Pick another colour space, no conversion, or your own .cube LUT, and optionally a show LUT on top. “All cameras” sets one look for every camera without its own — available right away for an added folder, whose cameras are known only after “Check clips”. LUTs stay with the production; another Mac asks for them again.

Burn-in

— On by default: clip name and source timecode. Choose further fields (record timecode, reel, camera, date, frame rate, scene/take, production, custom text), their corner, the text size and a dark box; the preview shows the result.

Sound sync

— Off by default. Sound files are matched by timecode and confirmed by the waveform. When only one of the two finds a match — for example because the recorder's timecode was not running — or when they disagree, the clip is flagged and you decide: timecode, waveform or no sound.

LTC and ZIP

— “Read LTC from camera audio” writes timecode recorded as audio into the ALE (Auxiliary TC1); the proxy keeps the camera's timecode. “ZIP for upload” adds one ZIP per day with proxies, ALEs, report and the day's sound files, and needs that space once more.

Check, review, render

— “Check clips” opens them in Resolve, reads timecode and format, detects the look and syncs sound. The review lists warnings to confirm, sync decisions and proxies that already exist (skip or replace). Render starts when nothing blocks it and shows the remaining time, Resolve's live speed (for example 290 fps (9.7× real time)) and a tile per camera timeline; clips whose card folder names no camera (…_B_Karte_001) are flagged. Cancel keeps the proxies already finished, and also works while Resolve is still starting or the upload ZIP is being written.

What ends up on the drive

— In Proxies/ inside each day's folder: the proxies, one ALE per day (tape from the embedded reel or the card name, scene/take from the camera report), the Resolve project (.drp) and proxy-report.json/.txt. Every proxy is then compared with its original — timecode, frames, frame rate and audio tracks. For Avid, copy the Avid MediaFiles folder to the root of the editor's drive and import the ALE.

While the Mac app copies cards, renders proxies or verifies offloads, your iPhone can show the run on the Lock Screen and in the Dynamic Island as a Live Activity.

Turn it on

— In the iPhone app open Settings → General → Notifications and switch on Live progress on the Lock Screen. The switch is per iPhone, off by default, and needs iOS 16.2 or later. If iOS has Live Activities turned off for Cine Power Planner, the row says so: turn them on in iOS Settings → Cine Power Planner.

What the card shows

— One row per running job — copy, verification, proxies — with a progress bar in percent, the time left, the card or camera in progress, and the queue (for example Queue 2/7 · Next A004). When a job ends the row shows Done or Failed, and the card disappears about ten minutes after everything ended. A verification you stop by leaving the Verify step is removed from the card a few seconds later. If the Mac app quits or goes offline in the middle of a run, the next run starts a new card.

Both apps, one account

— The Mac app and the iPhone must be signed in to the same account. Jobs are only sent while a phone listens, so the Mac does no extra work when nobody looks.

When the iPhone is locked

— The card stays on the Lock Screen. The bar and the time left keep moving on their own toward the predicted end. Real numbers arrive while the app is open; once push for Live Activities is enabled on the server, they also arrive while the iPhone is locked. A card that has not heard from the Mac for a while shows Updated with the time of its last news.

No footage leaves your machine.

• Copying, verifying and rendering proxies all happen on your own computer. What syncs to your account is the record: data projects, shooting days, cards, offloads with their paths, the copy log, transfer sessions and verifications.
• The Offshoot hook sends only the event type, a session label, the time, the project name, a status and counts — never file paths or footage.
• The hook file embeds your webhook token. Treat it like a password: do not commit it to git or share it. A token is shown only once, when you issue it, and Revoke stops it at once.
• Each account can read only its own transfer events.
• In a browser, a drive is a folder you granted access to, checked again on every read or write. Removing a drive from the list also forgets that access.
• In a shared data project, the project's members see the source, destination and drive paths it records — see “Sharing a data project with the project team”.

Common issues and fixes.

• A drive shows Offline → it is unplugged, or the browser lost its permission. Plug it in and click Reconnect; if that does not bring it back, pick it again with Re-pick.
• The Offshoot Pro tab says Not installed, but Offshoot is → the Mac app looks for it with Spotlight. Open Offshoot once from the Applications folder so Spotlight indexes it, then reopen the Transfer step.
• No real-time updates from Offshoot → the hook is not registered, or its token was revoked. Check that the file sits in Offshoot's Scripts folder and is registered for all three events, then restart Offshoot. If that does not help, issue a new token in Settings, download the script again and replace the old file.
• Notifications never arrive → notifications are blocked for the site, or the browser stopped its background worker. Allow notifications in the browser's site settings, then click Enable notifications again.
• A Mac-app copy stops with “… is not connected” → that destination drive is not mounted. Reconnect it or choose another destination, then start the copy again. A destination folder that does not exist yet is fine: the copy creates it and measures free space on the drive it belongs to.
• A Mac-app copy stops with “… was disconnected or remounted during the copy” → a destination drive (or the card) dropped off and came back mid-copy, or another volume took its place. The copy stops before writing a file anywhere else. Check that the drive is connected and press Resume copy; files already copied are checked and skipped.
• A Mac-app copy stops with “… ran out of room during the copy” → the card fitted when the copy started, but something else (another offload, a render, a sync app) filled the drive since. The copy asks for free space again before every file and stops before writing one that no longer fits. Free up space or stop the other program, then press Resume copy. This matters most for “Transfer only”, where nothing is read back: on a full exFAT drive a file can end up wrong without any error.
• A destination on the Transfer board shows “exFAT drive: eject it before unplugging…” → the drive is formatted exFAT, which has no journal: unplugged without ejecting, it can be left with files that are listed but empty. Eject it first, and prefer an APFS drive for the master copy. A failed verification lists each copy that was renamed (“kept as <name>.cpp-mismatch”); Resume copy writes those clips again.
• A Mac-app copy stops with “… changed size while it was being copied” → the file on the card got shorter or longer during the copy: a card reader that stopped early, or a clip a camera or recorder was still writing. The partial copy is not kept as a finished file and nothing is marked verified. Check the card, or wait until the recording has finished, then click Resume copy.
• Start is refused with “a copy into that folder is still running” → another copy in the Mac app is writing into that folder, or into a folder above or below it. Wait until it has finished, then start again.
• Start is refused with “the source lies inside a destination folder” → the card or folder you copy from sits inside one of the destinations. Choose a destination elsewhere.
• “Not enough free space on one or more destinations.” → each drive that is short is listed with what it needs and what it has free. Make room or choose another destination.
• A copy ends with “…the checksum manifest could not be written” and the reason “the name of … holds a control character that a checksum manifest cannot carry” → every file was copied and verified, but one file name contains an invisible control character that the MHL and ASC-MHL formats cannot store. Writing the manifest anyway would list a file name that does not exist, so no manifest is written. The character is shown as “?” in the message. Rename the file on the source and copy it again. Camera cards cannot hold such names; it happens with folders from a Mac.
• “This is not the card the copy started with” after Resume copy or after “Copy this card again from the start” → the app compared the card in the reader with the one the copy began with (its volume, its first file, how many files it holds and their total size) and they differ, so nothing was written. Both buttons do this check: a different card that mounts under the same name, such as “Untitled”, is not copied into the unfinished card’s folder. Put the first card back and resume. If the card in the reader really is the right one, press “This is the right card — copy it from the start”: that copies it without the check. A slot also stops showing “Copied” from the copy log when the card or drive now assigned to it is a different volume.
• A resumed copy fails and says “Some of these clips were already on the drive from the earlier copy and now read differently from the card” → a clip the earlier run had already copied no longer reads back like the card. The app kept that earlier copy as <name>.cpp-mismatch and copied the clip again under its own name. Choose Resume copy to verify the new copy; it then ends clean. One read cannot tell which side is wrong: if it fails again, try another reader or cable for the card, and treat the drive with suspicion. This only happens when you resume the copy of the same card; a file with a different date under the same name is treated as someone else’s file and your copy is written beside it as a “.1” variant.
• A failed copy also says “Before the copy stopped, files did not match the card when they were read back” → the copy stopped for another reason (the drive or card could not be read, or you cancelled), but before that at least one file had already read back wrong. The files are listed under the error. A drive that returns wrong data and then stops answering is the typical sign of a bad cable, port or drive: check them before you resume, and consider another drive. The copy log counts these mismatches for the failed run.
• “The card read differently the second time.” → with Re-read card and destinations, the card returned different bytes on its second read. Do not format the card; copy it again, and if it happens again, try another reader or cable. The copies of that clip may hold the bad read, so they were renamed to end in .cpp-mismatch; Resume copy writes the clip again under its own name.
• “This browser only shows past verifications” although you are in Chrome → a private or guest window, or an enterprise policy, switched off File System Access. Use a normal profile or the installed app.

Things to keep in mind:

• Copying, auto-assign and Proxies run only in the Mac app. In a browser, Copy with verification points you to the Mac app; Verify existing offload works in Chrome and Edge, but not in Safari or Firefox, which cannot open a folder; there, past verifications stay readable and exportable under Verification history.
• The Mac app is not available as a public download at the moment.
• Cine Power Planner does not start Offshoot: you set up and start the transfer in Offshoot yourself. Offshoot reports back only through the hook — without it, the Transfer status panel shows the cards but no verification issues from Offshoot.
• Network drives mounted as local volumes work, but their speed depends on the share. In a browser, folders are created one after another.