Fatal Crash Bugs & Scripting API issues as of Beta 4

The latest betas of Resolve 20 has introduced some fatal crash bugs into common workflow, and also caused fundamental issues in the Scripting API that breaks many scripts without all being updated with guards and workarounds.

I have tried to compile here a list of issues I've encountered, but if anyone else would like to double-check or verify these bugs, that would be very helpful.



1. DaVinci crashes when creating XYPaths on the Edit page
Modifying a Fusion-generator property with an XYPath on the Edit page while the Fusion overlay is open, or has been opened before on this item, causes DaVinci to crash. This completely eliminates the ability to use XYPaths in place of regular Paths with macros. It does not appear to crash if this is done in the Fusion page, and going back out to the Edit page after this will work normally without crashing.

Steps to reproduce:

• Drag a simple Text+ generator into the timeline in the Edit page
• Open the Fusion overlay
• Right-click Center > Modify With > XYPath
• DaVinci will freeze and crash

This is quite a fundamental flaw, especially if you have set XYPath as the default in Fusion, as then simply clicking the diamond will cause it to instantly freeze.



2. Undoing a Path created via scripting causes Davinci to crash
This might be a little harder to test, but if those who may have dabbled in scripting can verify that this bug exists, that might be useful.

Basically, any time a script generates a Path on a Fusion item such as a caption when wrapped in an Undo-block, if the user undoes it, it will crash DaVinci. I've made a little test Python script that demonstrates this:

Code: Select all

item = resolve.GetProjectManager().GetCurrentProject().GetCurrentTimeline().GetCurrentVideoItem()
comp = item.GetFusionCompByIndex(1)
tool = comp.FindToolByID("TextPlus")

if tool:
   comp.Lock()
   comp.StartUndo("Test Path Undo")

   tool.Center.ConnectTo(comp.AddTool("Path"))
   for i in range(30):
      tool.Center[i] = {1: i/30, 2: i/30, 3: 0.0}

   comp.EndUndo(True)
   comp.Unlock()


Steps to reproduce:

• Drag a Text+ into the timeline in the Edit page, and place the playhead over it
• Run a script such as the above to animate it
• Undo
• DaVinci will freeze and crash

3. item:GetRightOffset() is now broken on Fusion items
Previously, this call would return the internal frame at the end of the specified timeline item. This is still the case for media items, but for Fusion items, this is now always 0 for some reason. If the item is extended right, it becomes negative, and if shortened left, this value grows above 0. This is entirely of how long the item was when it was first created; a value we cannot read, thus this function has become completely useless. What's more, is that specifically for Adjustment Clips, this value is -216000 (and the GetLeftOffset() value is +216000).

Steps to reproduce:

• Put the playhead over either a Fusion item, Adjustment Clip, or Media Item
• Run this Python code in the console (for Lua, replace dots with colons):
  

  Code: Select all

  print(resolve.GetProjectManager().GetCurrentProject().GetCurrentTimeline().GetCurrentVideoItem().GetRightOffset())

• Extend or contract the items while re-executing the above code, and observe the outputs

The values will for media items work as normal, for Fusion items be really odd and scale unintuitively in any way that's useful, and for Adjustment Clips be the same as Fusion items, except instead of scaling around 0, it's around +/- 216000.

This particular issue was not a bug in Beta 3, only as of Beta 4. Hopefully this change can be reverted.



4. Python scripts executed in Macro buttons can no longer import other scripts
For some reason, in the latest Betas (both 3 and 4), if a button in a custom macro is set up to execute a Python script, this Python script can no longer import other scripts in neighboring folders. It seems like the environment context that lets Python know where the script was executed from has been removed. This is only the case for Macro-button-based script executions. Workflow > Scripts menu works just fine (even on the same script).

Steps to reproduce:

• Place two Python scripts next to each other in the Scripts folder
• Make one import a value or function from the other
• Run this script from the Scripts menu; It will work as normal
• Create a simple Macro with a button that executes this Python script
• Click this button to execute; The console will error that the other script cannot be found
• In addition, the "__file__" value is also None, but I didn't check if this was the case before the Betas too

This prevents the use of utility libraries that many scripts can share.



5. Attempting to import Python packages in button-executed scripts completely freezes the program
This is probably related to the prior bug, as it only happens with Macro button executed scripts. Attempting to import something such as numpy causes Resolve to hang and stop responding. This is again not an issue for (Workflow > Scripts)-executed scripts, but eliminates the use of any big number-crunching automations on Macros.

Steps to reproduce:

• Same as above, make a Macro with a button that executes a Python script
• In this script, import numpy or other package
• Create an instance of this macro and press the button
• DaVinci will freeze and crash

All of these bugs appear consistent between me and those I work with, so it does not seem to be an isolated case. But if anyone else can confirm or validate whether these bugs also occur on other devices, it might be helpful.

For reference, this was all tested on Windows 11 machines, using both DaVinci Resolve 20 Beta 3, and the newest Beta 4. I hope the crash bugs can be fixed, and the weird scripting changes be reverted, as it breaks many useful things and was not the case in Resolve 19. For now, I will have to revert my Resolve to avoid these issues.