Issue with Binder bloat and sync errors when using 4K research videos?

Hi everyone,
I’m currently in the deep research phase of a new historical fiction project, and I’ve been trying to keep all my visual references directly in the Scrivener Research folder for easy access. However, I’m running into a bit of a performance issue where my project .scriv file has ballooned to over 3GB, and now my Dropbox sync is consistently hanging or throwing “conflicted copy” errors.

I’ve been using a capcut macbook version to trim down long archival footage into smaller, 30-second reference clips so I don’t have to keep the raw files in the Binder, but even these “lightweight” exports seem to be taxing Scrivener’s internal search index. Whenever I try to use the “Quick Search” (Cmd-G), the whole app beachballs for a few seconds while it presumably scans the metadata of those video containers.

Has anyone found a better way to handle high-fidelity video research without actually importing the files into the Binder? I’ve considered using Document References to link to external files on my hard drive, but I’m worried about breaking those links if I ever move the project to a different machine. If any of you are using a capcut macbook version workflow to create your own writing references, how are you balancing the need for high-res visual detail with Scrivener’s preference for being a text-heavy database? I’d love to know if there’s a specific codec or “alias” strategy that keeps the project snappy while still keeping my research just a click away!

The Research Files as Aliases function is designed for exactly this issue. However, as you suspected, moving the project to a new computer will break the aliases.

Hookmark claims to create robust links, but I haven’t personally tested it.

DevonThink’s links are portable, provided the database containing the destination is present on the computer. I haven’t tested using it to store video, though.

For this much material, you might also consider using an online repository that generates standard URLs for the stored files. Those will work as long as the repository remains accessible.

2 Likes

There is, if it still works, one fundamental exception to the risk of aliases breaking. I haven’t tested it in years, but in the past, if you used 100% Mac technology to make the transfer between volumes (for example, plugging the drive into your main computer any tools on the Mac to copy—as opposed to using Dropbox to copy everything over), and the aliases were moved together with their targets in one single operation, then it would reconnect them to the new entities on the other volume. It’s a bit like Scrivener itself in fact, when dragging items between projects. If you drag the whole cluster of linked-together items, either with Bookmarks or hyperlinks in the text, Scrivener can scan the links and rebuild them in their new context in the target project. But if you only drag bits and pieces incrementally, they will break.

It’s worth testing with a small project and a sample alias, but I can think of no reason why that shouldn’t work, so long as the Mac itself still works that way. Scrivener stores the link you create as a real alias in the project folder, and when you copy the project folder along with the media, to the OS it would appear as any other alias+target copy.

Worst case, so long as you don’t have hundreds of them I suppose, little breaks here and there can be fixed with the Documents ▸ Change Alias Source... menu command.

1 Like