Update: Capture One 13.1.2 fixes this. You’re welcome!
Have you run into this annoying Capture One bug?
Say you’ve worked on a session on your capture machine, and now it’s time to copy the session over to your editing machine (or your backup drive). You copy the session over. When you open the session, Capture One proceeds to go through and uselessly repaint all the thumbnails and regenerate the previews, often twice if you’ve done edits on the session before copying it. For those of us who shoot 150MP files—or if you’re working on a slow drive—this can take forever, even on a fast machine.. Meanwhile, you’re off checking your email, fixing another cup of coffee, and checking Facebook while you wait for Capture One to give you your session back, when you would really rather be editing…
We run into this all the time, and it turns out that the cause has to do with how file dates get stored/compared in your C1 session files and subtly mangled by your machine’s filesystem(s). Modern filesystems (e.g. APFS, NTFS, ext4 on Linux) store modification dates as “number of seconds since 1 January 1970”, in fraction-of-a-second resolution. Older filesystems (FAT32, HFS+) are limited to storing modification dates rounded to the nearest second. Network file sharing protocols (SMB, AFP; possibly some NFS flavours but I haven’t tested it) are known to have issues truncating or rounding the fractional part of the date. So, a .cos file Capture One creates on your capture machine with an APFS filesystem might have the date stored as 1594937221.1234; copy it to your editing machine over the network and it might come up as 1594937221.1; save it on your HFS+ backup drive and it might come up as 1594937221.0. That loss of precision and lack of tolerance (as those of us with Computing Science degrees, like yours truly, would say) causes Capture One to go “whoa, the settings file changed outside of what the session says it should be!”, and proceed to resync everything. Slowly.
If you copy from one drive to another on the same machine that’s formatted identically (e.g. from one APFS drive to another), you’re home free, or if you’re copying from an older-formatted drive to a newer-formatted drive (say, an HFS+ RAID drive to your internal APFS-formatted SSD). If you’re starting off on an APFS drive and have to copy off it to an older-formatted drive, or over the network, the dates change subtly and C1 resyncs.
We’ve reported this in to Phase One, so we hope that they’ll fix this in a future Capture One 20 point release. In the meantime, we’ve written an Automator action to truncate the file modification times on all your .cos files to the nearest second so that everything lines up correctly if your network or file system has mucked things up, and update your .cosessiondb accordingly. This tool has been tested on the current version of CO20.1 on macOS Mojave (Your mileage may vary if you’re running macOS Crapalina). Use this tool at your own risk. We are not responsible for any damage it might do (though it does make a backup of your session file, just in case). if using this tool blows up your machine, destroys your session, or brings down the wrath of the Image Quality Professor upon you, it’s your own damn fault. That said, here’s how it works:
Unzip the .zip, and copy the Automator action onto a convenient place (like your desktop).
Copy your session file into its new location
Drag the session folder onto the ‘Fix Session Dates’ action. (This script assumes you have a single .cosessiondb file in the root of your session).
You’ll get a notification when it’s done.
Open up your session, and get editing!
Grab a copy here.