How To Safely Upgrade To DaVinci Resolve Public Beta Software

The first thing to understand: Beta is beta. Whether you’re on a private beta program (perhaps even under a Non-Disclosure Agreement) or using publicly available, freely downloadable Public Beta software. You, as an informed end-user, must take responsibility for using software that the developer is telling you is not fully tested. This takes us to Rule #1.

Rule #1: The software is Beta, ergo you are a Beta Tester

Private Beta or Public Beta – it’s a difference without a distinction (except many Private Beta programs put you under an NDA and it can become a breach of contract for you to even admit you’re in the Beta program). If you’re using software with the word BETA in it then you are a beta tester! One more time for effect:

If you’re using software with the word BETA in it then you are a beta tester!

Why, you may ask yourself, would a responsible software company release Beta (or unstable) software to the public? There are two reasons that pop to the top of my mind:

• End-user pressure to get early access to much desired new features after they’ve been announced: In Resolve 15 two features that come to mind are DCP creation and generating final Dolby Vision packages directly in Resolve. Both are good examples of killer features that a small group of power users may be hounding the developer to get early access. By releasing a Public Beta, the developer ends the constant stream of emails and beta testing requests – and can focus squarely on collecting bug reports and refining feature enhancements.
• The software is used in far too many configurations than they can hope to test: If they keep to a private Beta and then release the ‘final’ software, the multitudes of configurations guarantee some large bugs will be missed. Instead, they go the Public Beta route to find those bugs much earlier in the development cycle.

A fanciful example: Perhaps Dmitri’s problem with the Wacom tablet only happens when you’re using the Wacom in left-handed mode and have the preference to turn the Wacom ‘upside-down’? It’s likely this type of bug is missed in Private Betas. It’s far more likely this bug is revealed in a much larger, uncontrolled Public Beta cycle.

The entire purpose of a Public Beta cycle is to get early (and plentiful) feedback about driver conflicts, weird peripheral interactions, broken buttons & dialogs, and busted workflows. So knowing this – knowing you are taking on the role of a Beta tester – what precisely does Blackmagic expect of you?

Rule #2: you are accepting responsibility as a beta tester

Whaaaa?

Did I just say, “YOU are accepting responsibility”? And, “What does Blackmagic expect of YOU?”

YOU have responsibility?

Indeed, I did and you do.

You see – from a developers point of view, they’re giving you early access. This access allows you to start using their new features and workflows months before they normally release the final, Golden Master. And if the developer has clearly labelled the software ‘Beta’ (or as is frequently used these days, ‘Public Beta’) then they have given you fair warning of this early access, and your responsibility when using it.

Here’s the implicit contract you’re signing when you install Public Beta software:

• You understand the software is in a ‘pre-release state’
• You understand the software has undergone internal testing (and possibly a Private Beta cycle)
• BUT, you understand that the software may glitch, crash, freeze, break peripherals, crash your computer – or otherwise act in ways you consider unacceptable
• As a result of this pre-release state you will will take reasonable precautions such as:
  • Protect your work by using backups
  • In the case of Resolve: Backup not just your computer, but your databases and all individual projects you may want to open in the Beta software
  • Ensure you can restore your computer to a pre-beta condition

If you’re working in DaVinci Resolve then here are some additional items you must consider yourself implicitly agreeing to:

• You agree to never upgrade a DaVinci Resolve database schema without first backing up the database (there’s even a dialog box commanding you to do so)
• You agree to document hard crashes & freezes by generating a Crash Log and uploading it to Blackmagic’s DaVinci Resolve 15 Beta forum.

Is this all new to you? Were you unaware of the implications of being a beta tester? Then now is the time to ask yourself one question:

Do you have a problem with being a beta tester, as outlined above?

Do you think my definition of beta tester responsibilities are stupid? Do you think ALL software released to the public should be fully vetted and as bug-free as possible? Then I have only one word of advice for you:

STOP!

Don’t install any software labelled Beta. Ever.

Your expectations and inclinations are perfectly valid. But this means you need to wait for the first update AFTER the golden master .0 release. In other words, consider the official, Resolve 15.0 to be the final release candidate and wait until Resolve v15.1 is shipping. At that point, you’ll have software as stable as Blackmagic thinks they can get it (for now). And you’ll be in a position to get the most benefit from the software.

Yes, you might have to wait 6 months. But think of it this way: That’s 6 months you’re happily working away in the stable version of Resolve 14.x and letting others suffer through the rest of what I’m about to write 🙂

BUT – Are you willing to suffer the slings and arrows of Beta Testing?

Do you want to enjoy the benefits of new software features, new tools, and new workflows months before everyone else? Are you willing to take some time out of your life to assist the software developers by documenting your bugs and sharing your feedback?

Keep reading. This Insight will guide you to the proper path – and keep you from destroying valuable work.

Now that you’ve decided to accept the responsibilities outline above, let’s walk through my workflow for using Beta software. Here are just a few observations, so you understand my approach:

• Some of my steps are overkill: After 20 years of beta testing software, I’ve experienced it all. From catastrophic crashes requiring full Operating System re-installs to minor annoyances, these steps have proven to be the most reliable method to ensure one thing: If the Beta software has a problem then it’s likely not the fault of how I’ve gone about installing the software.
• Some of my steps are DaVinci Resolve-specific: Since Resolve relies on a database architecture, there’s an extra step or two that I don’t have to worry about with software from other developers.
• This workflow is designed to work for any Beta software: If you skip over the Resolve-specific steps then this workflow should apply to just about any beta software you’re inclined to test.

With my disclaimers out of the way, let’s take a look at my multi-step workflow for delving into Beta software. And here’s the quick summary of my workflow:

1. Back up the computer
2. Export projects and databases I’m going to upgrade
3. Update drivers and operating system
4. Uninstall Resolve
5. Uninstall Desktop Video app (if you have Decklink or Ultrastudio hardware)
6. Reboot
7. Install Desktop Video app (if necessary)
8. Reboot
9. Install Resolve Public Beta
10. Reboot
11. Launch Public Beta
12. Create a fresh database
13. Import Projects
14. Have Fun
15. Create Bug Reports

Holy smokes that’s a lot of steps! Yup. And below is my rationale for each step, plus some pointers and refinements.

Step 1: Have a backup plan

If you don’t have a backup plan then now is the time to devise it and execute it. This is non-negotiable. If you don’t have a plan to completely back up (and then restore) your computer to a pre-beta testing state then you’re setting yourself up for failure. What I’m about to detail is the rough outline, not a step-by-step of how to create a backup routine for a production computer (on Mixing Light we have a Mailbag Podcast that covers how to back up your computer and databases).

Basically, there are two variations on this theme when it comes to testing beta software:

• Use backup software: And you’ll want to back up your entire OS – not just your User folder. Remember, software like Resolve installs OS-level components. You need to reinstall the OS-level components from the back-up if you want to roll back to a pre-testing state. That means, back up the entire boot drive.
• Have a secondary computer (or boot drive) for testing Beta software: In this workflow you commit to never upgrading your primary money-making computer. If you can do it, dual boot is a great way of going; rather than having two computers, you have two hard drives but only one has the beta software on it. Rolling back to the previous version is a simple re-boot into the original hard drive.

Step 2: The Pre-Installation Routine

A. Decide what you’re going to do with existing projects and databases

• Are you going to upgrade active or recent projects? If so, then before upgrading you need to export those projects. And then NEVER upgrade the original project! You will only ever import that exported version of the project, always leaving the original intact and untouched.
• Are you going to upgrade an existing Database, with existing projects? If so, then export that database and NEVER upgrade the original database. You will only ever import that exported database, always leaving the original intact and untouched.

If our friend Dmitri had followed this first, simple rule then he wouldn’t have had a problem rolling back to his previous, working version of Resolve. Instead, he’s stuck using software that broke an essential peripheral – and is annoying the heck out him (and probably slowing him down).

B. Double check the Minimum Requirements for your drivers and Operating System, then update as necessary

Open the Read Me for your fancy new Beta software and look for System Requirements. They’re usually at the top or the bottom of the Read Me. Make sure every ‘requirement’ for that software meets your computer’s capability. Update accordingly. It’s shocking how few people on the forums ever double-check system requirements.

And it’s even more shocking how many people are in denial that their systems don’t meet the stated minimums. And then moan about it. If your computer doesn’t meet the minimum specs, then no one can help when the software doesn’t work. Complaining is futile. Just make plans for upgrading your hardware – or move on.

Step 3: Pat’s (Annoying) Installation Routine

I’ll point out a few overkill steps in this section – and why I do them anyway. But by now you need to make sure your computer is backed up and your essential drivers and OS is updated. Now we get to the really annoying part. Just remember – I do this to ensure HOW I’m installing the software doesn’t create problems on its own.

A. Uninstall your existing Resolve build, using Resolve’s uninstaller:

Technically, this step is overkill. As Robbie reminded me today, DaVinci Resolve installers have always uninstalled existing software – before installing the new software. BUT – a few years ago I found some bugs from a bad installer that left behind old components, which caused crashes. So… my advice… don’t trust the installer – it’s in Beta too. For the best experience, do an uninstall using the existing uninstaller, then install using the Beta’s installer.

• On Mac: The uninstaller is located in the same folder as DaVinci Resolve in Applications > DaVinci Resolve
• On PC: Go to Windows > Apps and Features, select DaVinci Resolve and choose uninstall
• On Linux: If you need me to tell you, then stop right here.

I always uninstall the Blackmagic Control Surface app, as well.

B. Uninstall Blackmagic’s Desktop Video app (if you’re using Decklink or Ultrastudio gear)

This one is easy to overlook. But if you have Decklink or Ultrastudio gear, this is a good time to get the most recent version. Sometimes Beta versions of this software is released. If you’re about to beta test DaVinci Resolve then ignore the Beta version of the Desktop Video app and use the most stable release instead. You only want to beta test one bit of software at a time.

C. Restart your computer

If you’re not using the Desktop Video App for Decklink or Ultrastudio then this step is optional. Personally, I like to do a restart after the Resolve uninstall, anyway. Sometimes, low level files get ‘stuck’ in RAM and don’t get overwritten by the software installer – and this can cause problems that the developers can’t re-create. I know it’s a pain… but I consider the restart a small price to pay.

D. Install the Blackmagic Desktop Video app & restart

I’ve always found DaVinci Resolve (both Public Betas and stable releases) works most reliably if I install Resolve AFTER the Desktop Video app is installed and the computer rebooted. So I install the Desktop Video app first, then restart, then I install DaVinci Resolve. It might be voodoo – but I’m sharing my workflow. And if you don’t own Decklink or Ultrastudio gear… skip this step.

E. Install the Public Beta software

Tip 1: Only install the components you need

In Resolve 15 Public Beta, not only can you install the SQL database items, Resolve 15 Public Beta, and the Blackmagic Control Surface App there’s now an option for a Fairlight Hardware Accelerator app.

If you don’t own a Blackmagic control surface and you don’t have any Fairlight hardware accelerators, skip those installs. Stick to beta testing the core app. Otherwise, you may be inadvertently testing how well those additional installs works on a computer that doesn’t have those devices attached. And while that may be useful to Blackmagic – why give yourself more points of failure?

Once Resolve seems to be running well for you, you can consider installing those components in future updates.

Tip 2: Do NOT run two versions of Resolve side-by-side

Even if Rohit or Peter (the Lead Software Developer and Product Manager) tell you it’s okay to run Resolve 14 alongside Resolve 15 Public Beta… ignore their advice. Don’t do it!

Again, if their Beta installer messes up or if the Beta software gets confused because the two versions are side-by-side – you’re going to need to uninstall both and do a completely fresh install to troubleshoot it! Let someone else find this problem.

Focus on beta testing the functionality of the beta software and give up on the ease-of-use to switching to the non-beta software. Beta testing is hard enough without the hassle of doing a full wipe of two versions of the software. Plus, as you switch between versions without rebooting there’s the possibility old code sticks around and causes new problems that, again, can’t be replicated.

So no. Do not run two version of Resolve side-by-side no matter what anyone tells you (even if it’s also Robbie or Dan 🙂 )

F. Restart your computer

Restarting after installing Resolve Public Beta is one of those ‘overkill’ steps. But it’s a habit of mine that seems to minimize problems with the external Decklink cards.

G. Launch the Public Beta Software, create a new database

Seriously, don’t update existing Databases straight upon first launch. Create a brand new one. Once you’ve got a few projects under your belt using a Database created by Resolve Public Beta then you can consider updating an existing Database and see how that works.

As a beta tester you need to understand that you only want to test one thing at a time!

If you update an existing Database then you don’t know if bugs you’re encountering is with the Database update routine, or the software? But if you’re on a database created by the Public Beta software then when you’re getting support from Blackmagic this eliminates a common question mark.

And remember: You only update an imported database! Don’t update an existing database already connected to Resolve, in case you need to downgrade and want to use it in the earlier version. Database updates are irreversible.

You want to make it easy to roll back to the non-beta software. And once rolled back, you want to be sure you’re running on the original database that you know is working.

Also, this routine verifies you had a good database export and if there’s a catastrophe with the export, you still have the original, untouched database

H. Import your .drp’s into the new database

For beta testing purposes, if you want to use an existing project in the beta software then import that project in a fresh, new database created by the beta software.

From here on out – it’s time to start working! Yea!

What happens after you’ve successfully upgraded to the Public Beta and new updates are released? I generally follow the exact same routine outlined in Part 2. But if the new Beta version doesn’t require a database update, I skip those database export / import steps.Remember – the key to successful beta testing is to minimize the variables you’re testing.

But your job isn’t done. Nope. There’s two things left to do!

Enjoy the new software

Seriously. Have fun discovering the new features and workflows. Use this time to crack open the Resolve 15 New Features PDF and look for the little things that might seem useful to the work you do. And then start working.

Report crashes and bugs

Finally – you do have one other responsibility as a beta tester. If the software breaks on you, then report it. If you think the beta software doesn’t work with some of the gear you own or is breaking other software, then report it.

How do you report crashes and bugs in DaVinci Resolve?

Easy. Before reporting your first bug, read this article on How To Report Bugs to Blackmagic. It’s written by the Product Manager for Resolve. If you follow the steps he outlines then you vastly increase your chances of having Blackmagic solve the problem (and maybe get back to you).

The primary way to contact Blackmagic is to use the Resolve 15 Beta Forum for reporting. They have a good track recording of responding to bug reports, assuming you follow the outline in the article on how to report bugs.

Beta testing is hard. Beta testing is annoying. Beta testing can be catastrophic.

But beta testing also gets you using the very newest tools and workflows before everyone else. When the ‘golden master’ is released, you are already expert in its usage. And frankly, I’ve always enjoyed watching software evolve over the short period of most Beta cycles. New features sometimes disappear, others sometime suddenly appear, and usually the software gets faster and more reliable.

But if you decide to run beta software without taking the necessary precautions then it’s all on you when you find yourself trapped in a corner you can’t back out.

If I have one regret these past two weeks – then it’s that I didn’t publish this article two weeks ago to save Dmitri the hassle of discovering that for himself. Sorry, Dmitri!

Do you have Beta Testing tips and tricks to share?

Use the comments below! I’d love to hear how you handle the dangers of running beta software.