If you're just here for the download, it's at the bottom of the post as usual.
What do we have here? On the surface it's an incredibly simple script that can set the timecode for media pool clips. It can set a specific timecode or an offset using timecode or frames. It works on the selected bin and optionally on any sub folders in the bin.


The original timecode can optionally be stored in a metadata field before changing it, allowing us to also
restore the original timecode later.
But the party trick of this script is that it finally comes with my take on how to tackle the issue of scripts crashing if the automated project backup starts while running. It involves wrapping the DaVinci Resolve function in the
script:retry() function. Not all API functions are affected by this issue, but generally the ones that change object properties are.
As far as I can tell, automated backups don't start if a script is running from the console, so that's good but it doesn't help when running scripts from the Scripts menu (as of DaVinci Resolve 18). It does however seem like it would be easy for BMD to provide a mechanism for suspending backups via the API. It would certainly save a lot of work in trying to make scripts more robust.
The script has four new useful reusable components:
- Retry - A way to make DaVinci Resolve scripts resilient to issues that otherwise stop execution:
- When the automated project backup starts
- When the user opens a modal window
- Progress bar - A GUI progress bar that updates using events

- Bin traversal - Gets the entire media pool tree and provides a function for traversing it in branch order
- Log - Write log entries using simple Lua tables that are then shown in a Tree control when the script has completed
Console snippetHere's a bare-bones snippet you can execute directly in the console for setting the timecode of all clips in the current bin. It ignores timelines and compound clips etc. By the way, "current bin" means the one selected in the Bin List, where only bins are listed. And you can only select
one. That's a limitation of the current scripting API.
- Code: Select all
local timecode = "00:00:00:00"
local project = assert(resolve:GetProjectManager():GetCurrentProject(), "Couldn't get current project")
local media_pool = project:GetMediaPool()
local selected_folder = media_pool:GetCurrentFolder()
local initial_page = resolve:GetCurrentPage()
resolve:OpenPage("deliver")
for i, media_pool_item in ipairs(iif(selected_folder, selected_folder, media_pool:GetRootFolder()):GetClipList()) do
if #media_pool_item:GetClipProperty("Format") > 0 then
assert(media_pool_item:SetClipProperty("Start TC", timecode), string.format("Couldn't set clip property on clip %s", i))
print(string.format("%s - OK", i))
else
print(string.format("%s - Ignored", i))
end
end
resolve:OpenPage(initial_page)
You might be tempted to look at
GetClipProperty("Type") to determine the type of a clip. But this, like a few other properties in Resolve, is translated to the language Resolve is currently set to. So if you're making scripts for other people I would avoid this property unless it's just used for listing.
While running the script we switch to the Deliver page for two reasons:
- Performance while updating clip properties is much increased if we're not showing the Media Pool
- DaVinci Resolve 18 has a bug where Start TC can't be set if the source viewer is currently showing the first frame of the clip. It works in the GUI but not via the API. It's a sneaky bug because it fails silently, SetClipProperty() still returns true. Since the Deliver page doesn't have a source viewer it works fine there.
Known issuesThe full script linked below uses the same workaround of switching to the Deliver page while updating clip properties.
The bin traversal functionality and the ability to get the full path of each bin requires us to know the contents of the whole tree beforehand. Bin folders in DaVinci Resolve 18 doesn't have a
GetParent() function so there's really no
efficient way of finding the path to a folder.
Performance is reasonably good though. If you have like 10.000 clips in a project you'll have to wait a few seconds before you can click the Start button in the GUI. This is more noticeable when a project has just been loaded the first time. Also, Linux seems to excel here, I think LuaJIT is just faster on Linux overall.
If you know that project backups take a very long time on your system, you can increase the timeout threshold before it fails by changing
script.default_timeout. It's set to
30 seconds by default.
Speaking of performance, I'm interested in feedback if you've tried this script on a project hosted in the Blackmagic Cloud.
One last thing, folders and clips returned from the API don't adhere to the sort order selected by the user. In fact, clips seem to return in random order at times. So I've just tried to make the best of it and provided a way of sorting clip lists by custom code as well.
DownloadSet Timecode for Media Pool Clips.luaFollow the instructions for putting a script in the Scripts folder
here.