Databases went missing...Again....project lost

Don't worry, Marc, life is a very unforgiving teacher.

Oh, I've found that out the hard way more than once. The reality is that there's often no shortcuts: you have to be willing to dive in and actually do the work to get the job done. I'm seldom happy when we realize that, but I also understand, "the sooner we start, the sooner we'll finish."

Wanted to jump back in here to emphasize a point.

For whatever it's worth, I did read/search the resolve manual on databases and found it very lacking. Theres some basics on how to set up a database but very little other information. Specifically this was not adequate to resolve the problem, which is why i posted up here.

Heres what i found in the manual.....

Reconnecting Databases You Previously Disconnected
Unlike the Project Manager in DaVinci Resolve, the DaVinci Resolve Project Server application shows
you every single DaVinci Resolve database on your computer, whether it’s connected to Resolve or
not. For this reason, it’s a good way to find the names of databases that have been disconnected,
either deliberately or accidentally, in order to reconnect them.
To reconnect any database on your workstation:
1 Open the DaVinci Resolve Project Server application.
2 Find the database you want to reconnect in the Databases list at the left.
3 Open DaVinci Resolve.
4 When the Project Manager window appears, open the Databases sidebar, and then drag the
database you want to reconnect from the DaVinci Resolve Project Server window to the Database
list of the Project Manager. That database is reconnected and appears in the Database list.

ok......where are the databases located in the OS so that I can recconect them? Specifically what folder do i need to select? what the heck is the Project server window?

There's some other stuff there that makes me shake my head but thats really lacking a a ton of necessary detail to fix the issue.

for comparison heres Avid's training center site

https://www.avid.com/tutorials

3 rows down in the middle is a video called part 1 setting up your project. It goes into the OS and explains how avid works. The information provided by BM pales in comparison to what avid provides.

I don't come around here often but if the database issues is throwing off multiple users then thats something BM might want to address. Especially in light of how their competition is handling its tutorials.

But I agree the UI isn't helpful either. I get the feeling that the database structure was designed by an IT engineer and not from a post production workflow.

You aren't using a project server so that paragraph doesn't apply to you. You are using a disk database which is different again from using a SQL database. The disk database is just a hierarchy of folders as I've mentioned earlier in this thread and the top-level folder is what you point the project manager to in order to connect to an existing database. There is no other OS-level location of the database.

FWIW, I don't think the developers of Resolve ever intended that the database be portable as a means to collaborate between two or more machines which is why they created the portable DRP and archive containers, but again, your workflow between two specific machines should work. I still get the sense that somewhere in you workflow you are doing something wrong which is leading to the missing database results you originally reported but I can't understand what that could be.

Saying "I won't read the manual" is no excuse. You have to, or else you'll drive right off the road -- particularly with complex software or hardware.

To me the interesting thing here is the “drive right off the road” analogy. If you know how to drive a car you can get into any car and, without reading the manual, not drive right off the road. Manual vs automatic is the one exception - but that’s two standard camps as opposed to a company going their own way, ignoring long-established convention.

When cars were first made there wasn’t any such convention and even steering wheels weren’t standard. That lack of convention made driving each car very complex. That complexity is gone now - thanks to convention. Software - and microwaves, and, and… can learn a lot from this. BMD is behind on this right now but can catch up if they choose to.

I don't think that's a good analogy. Many basic things are actually standardised on computers. If I know how to get around on Windows, I can explore a Mac quite intuitively and vice versa.

But specific software is very different, there is not much of standardisation between NLEs or grading systems. You will not easily find your way around Baselight if you are familiar with DR or the other way around. Heck, sometimes even the name of the same functionality is different.

Some things are very different. Some are very much the same.

The feature we’re talking about here is a good example of one that’s very much the same - but is gratuitously different in Resolve. It’s those kinds of features of which I speak.

Some things are very different. Some are very much the same.

The feature we’re talking about here is a good example of one that’s very much the same - but is gratuitously different in Resolve. It’s those kinds of features of which I speak.

This. I realize some people throw those two things together to argue pro status quo.

Some things are very different. Some are very much the same.

The feature we’re talking about here is a good example of one that’s very much the same - but is gratuitously different in Resolve. It’s those kinds of features of which I speak.

There are quite large differences between all editing apps in the way they deal with projects and the terminology used. Avid, Premiere and FCPX all use different schemes. It would certainly be nice if every editing software worked the same way but it has not happened in my lifetime and I've been doing this since cutting film. It's quicker and easier to adapt one's skill to the software than waiting for the software to adapt to one's desires.

The Resolve database system probably won't change, but it can certainly be improved so the new user finds it a bit easier to understand.
A better analogy would be a large aircraft cockpit rather than a car.

I like that one, Peter.
If you know how to fly Movie Maker (aka Cessna), you wouldn't dare to fly DaVinci Resolve (aka Boeing 747), would you? Even if some around here may claim that DR compares with the 737 Max…
I wonder how many pages the manual has.

I guess we can agree to disagree.

That's fine with me.

For whatever it's worth, I did read/search the resolve manual on databases and found it very lacking. Theres some basics on how to set up a database but very little other information. Specifically this was not adequate to resolve the problem, which is why i posted up here.

...

I don't come around here often but if the database issues is throwing off multiple users then thats something BM might want to address.

For anyone following along at home, appears BMD posted a couple of new videos to their Youtube channel today:

What BM may have failed to address is that first rule when using Resolve is do not move project database between two or more computers. If you need to work on a project on another computer, export the project and import it to the other.

Database structure, indexes, fields etc. are DVR version dependent. Both the underlying database engine (Postgres version) and Resolve version.

This means you need to have identical DVR versions installed in all machines potentially using the database.

Complaining about non optimal UI, that should adopt to user habits or expectations and at the same time complaining about changing (improving?) UI is odd. If the UI needs improvements it needs to change right. Also it's not always better to have UI 100% suitable to do one thing, for example if other part of the software uses different paradigms or ways to do things. Take Wordperfect vs. MS Word. Everyone would take the graphical UI Word version over Wordperfect... Except those who learnt the keyboard shortcuts and workings of Wordperfect and were a lot more productive that Word users were.

User interface should be consistent and not do anything unexpected.

I'm not saying the project management UI is how it should be, but if you understand how it's planned to work, it's already usable and problem free.

/rant

This is a great start! They are short and informative, exactly as it should be!

These two only cover the already obvious though and not the issues people often run into, so I hope they already have more troubleshooting vids in the pipeline.

For example, sometimes it is not possible to create a backup because you can't access Resolve anymore and need a clean reinstall. I received detailed instructions from support via Email, a short 1 minute video could be done for that (and save some support tickets).
The second video shows a way to prevent needing to create a backup manually, so that's great.


And an idea for the UI:
Why use "!" next to the databases to access a hidden menu? This is confusing. The worldwide standard sign is three vertical dots to indicate there are further options hidden.

Also, "Restore" a project library is accessible on the top layer UI, "Reconnect" though is hidden several layers below.

User interface should be consistent and not do anything unexpected.

So if it's suboptimal it should remain suboptimal?!

Resolve now is a mainstream tool. It's not the niche, Boing 747 product it used to be 15 years ago anymore. It almost feels like some veterans want newcomers to put in the work to deserve using Resolve. It doesn't have to be that way and shouldn't going forward, since BMD chose to target a new generation of content creators.

Keep the project library structure but make it easy and intuitive to use and get rid of the small traps it contains. I don't understand how anyone can think that's not better than the status quo?

For example, sometimes it is not possible to create a backup because you can't access Resolve anymore and need a clean reinstall. I received detailed instructions from support via Email

No idea what those detailed instructions were, but here's an easy way: locate the database on disk using the OS. Drag (copy) the folder to a new location, preferably a new disk. That's it. You now have an identical copy, which you connect (as needed), NOT restore.

A database backup (accomplished in Resolve) is [just] a compressed version. If you unzip it outside Resolve it I believe it will "become" a database. But I generally avoid the whole thing, and the potential for compression errors, simply by making actual 1:1 copies.

When you don't understand how something works, it seems unintuitive (at least that's the word used throughout this thread). Once you understand how something works, you forget that it wasn't intuitive in the first place. It's hard to look at the UI with fresh eyes once you know how it works.

I have no problems with the database paradigm used by Resolve. The UI is 'OK' (not great because it isn't as discoverable as it could be I suppose), but there's no doubt that without reading the documentation (or watching the training videos), it is difficult to comprehend the intended (as designed) workflow for project management.

For anyone following along at home, appears BMD posted a couple of new videos to their Youtube channel today:

Thanks Andy, had no idea BM had a youtube channel. But see thats head scratching to me. Avid has tutorials on their website, but BM chooses to use social media for information. And when googling "resolve database" I dont even see the BM channel, i just get youtubers. If you want to duplicate your content on youtube have at it, but to not have it on the tutorial page i just don't get.


As for the UI discussion, I think there are some easy and specific ways to make databases more user friendly. The first thing is to make sure theres a simple workflow to move projects/databases between multiple machines, without having to export a DRP.

I think there are some easy and specific ways to make databases more user friendly. The first thing is to make sure theres a simple workflow to move projects/databases between multiple machines, without having to export a DRP.

That "simple workflow" already exists. It's been explained here several times, the short version, the long version, you name it. If there's any doubt, here it is again, assuming the database is on the external disk and you've moved that disk to a new system and Resolve sees it:

-- go to Project Libraries (aka the Database Manager)

-- select Add Project Library at the bottom of the screen

-- select "connect"

-- fill in the name of the database or whatever you want to call it

-- browse to the database on the external disk

-- connect.

That's it. Or you can find this in the manual:

To connect to an existing local project library:

1 Click the button at the upper-left hand corner of the Projects window to open the Project
Libraries sidebar.
2 Click the Add Project Library button at the bottom of the sidebar.
3 Click on the Connect tab. The Add Project Library window should look like the
following screenshot:
4 In the remaining fields, do the following:
a) Type a name for the new project library into the Name field.
b) Click within the Location field and use the Filesystem navigation dialog to choose the location
of the existing project library you wish to connect to.
5 Click Connect, and the new local project library will appear in the local project library section of
the Project Libraries sidebar.

Th section which follows in the manual is for "Backing Up and Restoring Project Libraries", with similar step-by-step instructions.

All this isn't explicit enough?

thanks john,

actually its not, And im not really looking to rehash previous discussions. But your really not re-connecting as much your creating a duplicate database on your other device, and then linking to it. Which creates multiple project libraries and directory trees.

Which is what created the mess I already have. Further more your providing instructions specifically about backing up and restoring project libraries/databases on one machine, not moving them somewhere else.

Thats a complete mess of a workflow, and if thats BM's solution to moving media and projects around then its not working as designed. There are multiple problems here but just to pick out one specifically

-- select Add Project Library at the bottom of the screen

-- select "connect"

-- fill in the name of the database or whatever you want to call it

-- browse to the database on the external disk

The database already exists, why do i have to name it? why cant i just connect the database thats already there. Remove that middle step. Let's go from "connect" to "browse" to "select database" without having to name anything. Seems pretty simple. The name and the database are already listed, it is already there. The workflow BM is providing just creates duplicates.If the database is there, why are we having to rename a database that already exists just to reload media and project files?

I gathered from most of the users that the best option was to export a DRP file to your External hard drive. Is this what BM intended as a workflow? because thats not in the manual. Sounds to me like other editors have found a different workflow outside of what BM intended.

Actually, it *is". If you disconnect previous versions, as advised earlier by more than one participant here, you won't have duplicate databases and can use the one and only "real" name. If you don't want to disconnect old database entries and re-connect the current existing database, then leave the database alone and import .drps, preferably into a database which resides separately on each system. But even in that case, you may have problems with duplicate project names, because Resolve can't second guess your intentions. *You* have to organize these transfers in a way that keeps old and new separate. The same would occur if you were transferring Premiere-type project files which already existed on the target system with the same name.

But, in any event, there's no point repeating all this ad infinitum.

The first thing is to make sure theres a simple workflow to move projects/databases between multiple machines, without having to export a DRP.

No, that is exactly what shouldn't be done, database schema, indexes etc. change almost in every version for one reason or another. Database wasn't designed to be "portable". Or more portable than it already is.

It's like you want to move your whole cellar from your home to your summer cabin when you only need to take the snorkel and fins.

The first thing is to make sure theres a simple workflow to move projects/databases between multiple machines, without having to export a DRP.

No, that is exactly what shouldn't be done, database schema, indexes etc. change almost in every version for one reason or another. Database wasn't designed to be "portable". Or more portable than it already is.

It's like you want to move your whole cellar from your home to your summer cabin when you only need to take the snorkel and fins.

So if a database isn't designed to be portable, how else can you move a project around without exporting a drp? Also each machine will require its own individual database so you are now going to have duplicate databases in your project manager, and will have to figure out which one to use depending on which machine your on. Additionally if your database disappears, you lose your project as well. Your database contains the project so it has to be able to be accessible in multiple places.

Actually, it *is". If you disconnect previous versions, as advised earlier by more than one participant here, you won't have duplicate databases and can use the one and only "real" name. If you don't want to disconnect old database entries and re-connect the current existing database, then leave the database alone and import .drps, preferably into a database which resides separately on each system. But even in that case, you may have problems with duplicate project names, because Resolve can't second guess your intentions. *You* have to organize these transfers in a way that keeps old and new separate. The same would occur if you were transferring Premiere-type project files which already existed on the target system with the same name.

But, in any event, there's no point repeating all this ad infinitum.

Not trying to pick on anyone but just specify the issues here...

-why would i want to disconnect a database to move it to another machine? I want to work on the same project in 2 places

-you do get duplicate databases, ive shown that. Additionally in the youtube video, in order to reconnect the database, the engineer duplicates the project library in order to restore it. She does this specifically by having to create a new name. The same project now exists in 2 places.

-again why do i want separate databases on each system, how about one that i can take wherever i go. Separate databases for the same project is confusing as all hell. so your saying the workflow is to create a database name it Client 1_desktop. Create project, do work. Export DRP file. Connect drive to laptop. Create Client 1_Laptop, import DRP file. I now have 2 databases in my project manager, one for the desktop one for the laptop. Cmon man that's just dumb. If thats how resolve works then so be it but thats an insane workflow.

-This is not how premiere works. Ive never had a problem opening, saving and working on a premiere project the way i have with resolve.

Again, everything is contained on an external drive. Why the need to duplicate, reconnect, add a library, create multiple separate databases to work on the same project? or even just the need to have this conversation just to figure out how to work in two different places? I don't get it....

This is not how premiere works.

Thank god for that.

That ill agree with.

-This is not how premiere works. Ive never had a problem opening, saving and working on a premiere project the way i have with resolve.

Nothing's stopping you from going back to Premiere. To me, you have to accept certain design aspects of Resolve and stop trying to force it to fit your idea of workability. There's a bit of a "square peg / round hole" thing here: the more you stop fighting Resolve's way of doing things, the more you'll learn and the more actual work can be done.

You could start by going through all the basic (free) Resolve tutorials on Blackmagic's training page, which go through this in great detail. There's also numerous tutorials on making the switch on YouTube; here's 2 of them:

Thanks marc, I appreciate the insight but im not trying to force anything. I'm trying to understand how to best utilize resolve in a portable manner. Whats fascinating is that no one really has a great workflow to doing so...most of the conversation points to the manual for backing up restoring databases but theres very little in terms of project management between 2 devices. Theres some workflow ideas that are helpful but nothing that I think is really efficient or user friendly.

So just to be clear for future reference, and correct me if im wrong but this is what the community has presented here.

PROBLEM
Using an external hard drive to work on multiple devices is challenging because of resolves inability to read databases on different machines. Databases contain the project/media/and links to backup files so if a database cant be read it needs to be added or reconnected, in order for an editor to regain access to their work. Additonally if a database is accidentally deleted or damaged, all the work is lost despite having project backup files. There are 2 workflows that have been presented here.

solution
1)Always export a DRP file at the end of each session. This serves as a total and complete "backup" should a database become unrecoverable.

2) create databases on different machines, and use the DRP file to move back and forth between machines. This is time consuming and can lead to confusion as to which database to use or will have the most updated project.

Note that If a database goes missing reconnecting a database creates a duplicate database, and duplicate directory tree in the OS. This makes project management a nightmare.


Neither of these solutions are ideal. In fact I think their pretty crappy compared to other NLE's. The majority of the community has suggested reading the manual, watching you tube videos etc....and i truly appreciate the attempts to help. But none of these specifically solve the problem of databases disappearing when using an external drive to work on multiple machines.

Steve's post on Jan 26th at 10:16 was great and very helpful. But it still dosen't solve the problem of understanding why databases loose all projects and media ( go missing) and why the user has to add library, or reconnect databases in order to access the same material on both machines.

[quote] I still get the sense that somewhere in you workflow you are doing something wrong which is leading to the missing database results you originally reported but I can't understand what that could be./quote]

that sir, is the missing ingredient in all this.....Save project, quite resolve, eject drive, plug drive into laptop, open resolve. Same database was missing all projects and media. Yes I was able to recover it but only by duplicating the database. Which i now understand would have been better to "add library".

I still cant understand why resolve is set up this way. Seems like its way overly complex with very little benefits. The point that bryantocara made about power bins is legit but the rest just doesn't really apply for editing. At least for my work. What it did make me think about was saving stills, power bins and other presets in a color grading session. And since thats where resolve got started I'm willing to bet thats where the database workflow originated from. I can certainly see the benefits of a database in color grading, but I don't think it applies well into editing sessions.

I really do appreciate the help of everyone to dig into this and help to teach a newbie how this works. I think Ive done enough damage for the last week so unless someone has anything to add I cant imagine anything else that was missed.

Oh @Shrinivas Ramani - If you all are looking to create more content for the youtube channel, i vote for a quick tutorial on moving projects from one machine to another using an external drive!!


Thanks again to everyone!

To me, you have to accept certain design aspects of Resolve and stop trying to force it to fit your idea of workability. There's a bit of a "square peg / round hole" thing here: the more you stop fighting Resolve's way of doing things, the more you'll learn and the more actual work can be done.

I disagree on this. Bringing up our issues with the software and explaining how we'd like it to work on the official Resolve forum where BMD actively reads the forum is the best way to bring these issues and possible solutions to their attention. That is the best way to help improve the software. If you don't ask, you'll never receive.

I'm also not a fan of the database system and would much rather work with project files like every other editor I've used. Databases seem like they have their place in regards to real-time collaboration and things like this, but it should be optional. I'm not doing anything like this and I would prefer to not be forced into the database system. Just let us manage our own project files and open them up in Resolve and give the option to create a database for collaborative purposes. Every other editor can manage project files, I'm sure Resolve can too.

Databases contain the project/media/and links to backup files…

They do not contain the media.

2) create databases on different machines, and use the DRP file to move back and forth between machines. This is time consuming and can lead to confusion as to which database to use or will have the most updated project.

It's not more time consuming that any other method to move a project, those files are small. And then, whichever mechanism is used to transfer a project between two machines, you'll have to set a convention for identifying the most recent version. It can easily be done by a proper naming scheme. BUT you'd still have the problem that you can't work on the same project version at the same time.

So, I think BM is on a good way to facilitate cooperation with the cloud based solution. It just needs to get bomb-proof, which may take some more effort.

So if a database isn't designed to be portable, how else can you move a project around without exporting a drp? Also each machine will require its own individual database so you are now going to have duplicate databases in your project manager, and will have to figure out which one to use depending on which machine your on. Additionally if your database disappears, you lose your project as well. Your database contains the project so it has to be able to be accessible in multiple places.

Using the project server tool (or other database solution) and accessing your database over the network solves all of these problems, which shows how Resolve was built for the post houses as a color tool. Not really a great workflow for a solo act mobile editor, by any means.

I disagree on this. Bringing up our issues with the software and explaining how we'd like it to work on the official Resolve forum where BMD actively reads the forum is the best way to bring these issues and possible solutions to their attention. That is the best way to help improve the software. If you don't ask, you'll never receive.

If you want to ask, put your request on the DaVinci Resolve Suggestion Forum:

viewforum.php?f=33

Bear in mind that the database is pretty much the backbone of how the entire system works. I've told students before: "you think that Resolve is a color correction program that also does editing, sound mixing, and Fusion visual effects, but the reality is that it's all a database. It's the database that sits on top of everything else and enables it to work. If the database ever gets corrupted -- like if files are moved in the OS or things are damaged -- the whole thing goes south very quickly." So a lot of what Blackmagic (and the earlier designers) did was to try to shield the database from any potential from harm. It would take a massive amount of work to dismantle this and go with a different system, since it kind of goes to the core of how everything works.

I've given you ways to make this work for you, including Exporting a copy of the current DRP, which literally takes less than 5 seconds (under 2 seconds for small sessions). Try that and see if that handles your situation of sharing project. Blackmagic's Cloud Server could be another excellent solution.

The old-timers here know very well what works for them but often - at least in my experience - they don’t know why things that aren’t working aren’t working. They don’t say that but that’s the way it looks to me. Being a former software dev I like to dig into these things and figure them out.

In the past I’ve had databases on removable drives along with the media and it’s worked fine moving the drive from one system to another.

Of course one needs to tell Resolve on each machine where to find the database and the versions of Resolve on each machine need to match - but that’s often true with an Adobe project and still might be true with a drp. I’ll try it again tomorrow and see if it still works - I suspect it does - and report my results here.

Cheers!
Joe

1)Always export a DRP file at the end of each session. This serves as a total and complete "backup" should a database become unrecoverable.

Yes, standard workflow practice, effectively the same as any other app. Eg In Premiere you 'Save' at the end of the session, to overwrite your old project file with the latest data, in Resolve you 'Export' at the end of the session, to overwrite your old project file with the latest data.

2) create databases on different machines, and use the DRP file to move back and forth between machines. This is time consuming and can lead to confusion as to which database to use or will have the most updated project.

How is this 'time consuming'? If you were working in Premiere and take the project file from one machine to work on it on another, is that time consuming? Whats the difference? And as to the confusion... what do you mean 'which database to use?' You use the database on the system you are working on. As to which one has 'the most updated project'... didn't we already establish that, as a mobile editor, you are using a (DRP) project file?

Note that If a database goes missing reconnecting a database creates a duplicate database, and duplicate directory tree in the OS. This makes project management a nightmare.

a) Why is you database 'going missing'? Are we talking user error as a result of poorly understood and/or implemented workflow practices? Or is there a genuine bug here? If the latter, it seems like we are yet to identify exactly when and how thats triggered. b) No, as discussed, "reconnecting" a database does not duplicate it and/or duplicate your directory tree.

Which i now understand would have been better to "add library".

You say you 'now understand' this... but you're still seem to be arguing the above based on your previously flawed understanding.

Speaking for myself, I've often moved projects (via DRP files) back and forth between Mac and PC systems daily without any trouble. I never lost a thing, there was never any confusion. It seemed really straightforward ... in fact it was absolutely magical as the path mapping feature meant I didn't have to do the nightmare relink dance that plagued me when doing the same thing with Premiere projects. So, for the life of me, I can't really understand why you're finding any of it quite so difficult.

Even so, as I've said before, if BMD decided to add a 'single project mode' option to the system (ie a mode that hides the Project Manager) that would be fine with me (assuming I didn't have to use it myself!) In 'single project mode', a user would only ever see and use DRP files... the import and export would still happen, the database backend would still be there, the user would just be oblivious to it.

In the past I’ve had databases on removable drives along with the media and it’s worked fine moving the drive from one system to another.

It still works, as long as that drive is not formatted exFAT and mounted before you start DR.
Just connect. I still prefer the .drp approach, which never failed us with dozens of students over the years.

2) create databases on different machines, and use the DRP file to move back and forth between machines. This is time consuming and can lead to confusion as to which database to use or will have the most updated project.

drp files are a lot smaller than the whole database file. As a bonus you can keep the database with the computers own internal "disk" which is often many times faster than an external one. Although the db updates are not data heavy so it might not matter at all.

Answer to the question which database to use is easy: Whatever is installed on the computer running Resolve. Version control is up to you to decide.

So if it's another version it's not working?

It's the database that sits on top of everything else and enables it to work. If the database ever gets corrupted -- like if files are moved in the OS or things are damaged -- the whole thing goes south very quickly."

Well that sounds like a really terrible structure doesn't it

During this debate I noticed one thing: everyone defending the status quo has several thousands of posts on this forum.

This, from a new user, sums it up for me and would be the ideal state imo:

Databases seem like they have their place in regards to real-time collaboration and things like this, but it should be optional. I'm not doing anything like this and I would prefer to not be forced into the database system. Just let us manage our own project files and open them up in Resolve and give the option to create a database for collaborative purposes. Every other editor can manage project files, I'm sure Resolve can too.

I'm not 'defending' databases, I explain how to use them.
For feature requests, there's a subforum above this one.

@ Uli

They do not contain the media.

Technically thats correct, but they do contain the links to the media. I was speaking of the project manager and how projects and media should appear in the project manager when selecting a database.

@Andy -

Yes, standard workflow practice, effectively the same as any other app. Eg In Premiere you 'Save' at the end of the session, to overwrite your old project file with the latest data, in Resolve you 'Export' at the end of the session, to overwrite your old project file with the latest data.

We may just have different workflows in premiere. I have to disagree in that exporting a drp file is not standard. In premier I save the file, I'm done and ready to pick up anywhere I want. Also in premiere there's an autosave folder that backs me up, as well as cloud saves. In Resolve there's project saves, and now a DRP export. That's an extra step that's not part of my premiere workflow. Exporting a separate DRP file seems unnecessary if there are project saves. There are additional steps in resolve that need to be taken to ensure your work is properly saved and backed up.

How is this 'time consuming'? If you were working in Premiere and take the project file from one machine to work on it on another, is that time consuming? Whats the difference? And as to the confusion... what do you mean 'which database to use?' You use the database on the system you are working on. As to which one has 'the most updated project'... didn't we already establish that, as a mobile editor, you are using a (DRP) project file?

Again in premiere you save the project and are done. Creating two separate databases, on two different machines with the same project is unnecessary IMO. A Laptop database and a desktop database for the same project? ugh. Theres additional project management work that's involved here. As well as having to keep track of the most updated DRP file

Speaking for myself, I've often moved projects (via DRP files) back and forth between Mac and PC systems daily without any trouble. I never lost a thing, there was never any confusion. It seemed really straightforward ... in fact it was absolutely magical as the path mapping feature meant I didn't have to do the nightmare relink dance that plagued me when doing the same thing with Premiere projects. So, for the life of me, I can't really understand why you're finding any of it quite so difficult.

You shouldn't have to relink anything if all your media stays in the same place. If your relinking media in premiere then its moved or a directory path has changed. And id rather relink media then have to build multiple databases on separate machines, export drp files or restore databases creating duplicates.

But regarding resolve, If everything is contained on an external drive, (media, databases, backups, links etc) why does resolve struggle to maintain links to databases when working on different machines? Why is it not the same no matter where you plug your drive into? I don't think BM has to reinvent the wheel or add a whole bunch of functionality to fix this. Everything should point to the same place no matter where your working.

The workflow of moving a database on an external drive from machine to machine works fine for me (based on tests, I don't usually use this approach). As Andy mentioned, we still haven't identified why it fails for you, George.

One thing I can think of that would mess up Resolve when connecting a drive to different computers is the mount point changing. On Windows this usually means the drive letter changing. On MacOS this shouldn't be a problem. Though renaming the external drive on MacOS would probably cause Resolve to lose the database, er Library, link.

People have said here that drp's and Premiere's project files are essentially equivalent. I think the files are but the way they're used is decidedly not.

Premiere loads from and saves to a project file. Resolve does not load from or save to a drp. It imports from and exports to it. How is this different?

Resolve has its own filesystem - the Library (or database) - which is the only place it loads from and saves to. So to use a drp you import it into the Library and open the resulting project. Resolve then autosaves to and makes backups of that Library project. If you want to stick with drp's you can export the Library project to a new drp - either with a new name or overwriting the old drp.

This results in a complex array of "files:" the original drp, the Library project, the Library project backups (which happen to be drp's but in a different location and perhaps with different naming), and the exported drp.

Let's say you want to edit the drp again. You import the new drp which creates another Library project. So now you've got two Library projects. Should you delete the old one? If you do the backups go with it. Either way, you've got to manage these Library projects even though you don't want to.

So yes, it's possible to use drp's kinda like Premiere uses project files. But it's way more complex and has lots of drawbacks.

I disagree on this. Bringing up our issues with the software and explaining how we'd like it to work on the official Resolve forum where BMD actively reads the forum is the best way to bring these issues and possible solutions to their attention. That is the best way to help improve the software. If you don't ask, you'll never receive.

If you want to ask, put your request on the DaVinci Resolve Suggestion Forum:
viewforum.php?f=33

Bear in mind that the database is pretty much the backbone of how the entire system works. I've told students before: "you think that Resolve is a color correction program that also does editing, sound mixing, and Fusion visual effects, but the reality is that it's all a database. It's the database that sits on top of everything else and enables it to work. If the database ever gets corrupted -- like if files are moved in the OS or things are damaged -- the whole thing goes south very quickly." So a lot of what Blackmagic (and the earlier designers) did was to try to shield the database from any potential from harm. It would take a massive amount of work to dismantle this and go with a different system, since it kind of goes to the core of how everything works.

I've given you ways to make this work for you, including Exporting a copy of the current DRP, which literally takes less than 5 seconds (under 2 seconds for small sessions). Try that and see if that handles your situation of sharing project. Blackmagic's Cloud Server could be another excellent solution.

I'm not the original poster, I just didn't agree with the idea that if you accept the way things work and somehow that will solve the problem. I think if we have problems, we should make them known so hopefully the developers will fix it. I have had to follow the way Resolve does a lot of things, but that doesn't mean I like it and it hasn't magically make it better. Also, I have pitched several of my top priorities in the request forum. While I'm not a fan of the database system I wouldn't say fixing the database is a top priority for me, but when it is then I certainly will pitch it myself.

Why does there need to be a database holding every single project in the same place? Why can't the project file contain the information it needs to be able to use the project? Then there can be global directory locations for other things (like the cache directory) and maybe even local overrides if you want to use different directories for a specific project. If you move any of these directory that Resolve needs, then prompt that Resolve cannot find that location and give the option to browse to a new directory. This is the way other applications work and I like this a lot more.

Being a former software dev I like to dig into these things and figure them out.

I think that is why we tend to be on the same page so often, I'm a software dev too. In fact, a primary reason I started looking for a new editor (and landed on Resolve) is because I wanted to be able to make better promo videos for some music apps I'm developing.

Why does there need to be a database holding every single project in the same place? Why can't the project file contain the information it needs to be able to use the project?

It's true that a project isn't functional outside a database, but you can create and put databases wherever you want, and there's no limit to the number of them. And you can put any project into any database. If you double-click a .drp file, it will automatically install itself into the current database. And you can cut and paste projects between databases. You can even -- forbidden subject! -- copy project folders from one database to another.

And of course the project files *do* contain all the information associated with the project, with the exception of some system settings (found in the database).

If you're really determined to isolate project files, create a database for each project, which is what virtually everyone working on long form material does anyway. DB creation takes about 10 seconds, if you're slow.

Why does there need to be a database holding every single project in the same place?

Because Resolve is either single computer or shared database based system. (I'm not sure if BM defines it as such though)

So you either work on a project on your computer or use a database on a shared location. Or more recently you can work on the same project through cloud.

There are additional steps in resolve that need to be taken to ensure your work is properly saved and backed up.

A project saved as a file is not a backup, it can get corrupt, the drive can break etc. Backup is a copy of the original stored somewhere else than on the same drive where the original is. How easy it is to do is separate issue.

So yes, it's possible to use drp's kinda like Premiere uses project files. But it's way more complex and has lots of drawbacks.

Agree.

It's true that a project isn't functional outside a database, but you can create and put databases wherever you want, and there's no limit to the number of them. And you can put any project into any database.

Sure, I get what you can do. I did a lot of experimenting with the database when I first started using Resolve, so I understand how to use it, I simply don't like it. Why the unnecessary steps for those of us who don't need a database for things like real-time collaboration?

And of course the project files *do* contain all the information associated with the project, with the exception of some system settings (found in the database).

Then why not just let us manage those files ourselves outside of the database? Why can't global settings be stored in a Resolve system file and local settings be stored in the project file instead of in the database?

If you're really determined to isolate project files, create a database for each project, which is what virtually everyone working on long form material does anyway. DB creation takes about 10 seconds, if you're slow.

That would make doing major Resolve updates (when Resolve makes changes to the database) worse as you'd have to backup and restore multiple databases up instead of only one. That doesn't make things easier.

Why does there need to be a database holding every single project in the same place?

Because Resolve is either single computer or shared database based system. (I'm not sure if BM defines it as such though) So you either work on a project on your computer or use a database on a shared location. Or more recently you can work on the same project through cloud.

Right, but for single computer there isn't a need to have the database. I also mentioned previously that a database can be optional for those who need that feature for collaboration.

Well that sounds like a really terrible structure doesn't it. During this debate I noticed one thing: everyone defending the status quo has several thousands of posts on this forum.

I think you're confusing a "database" (the underpinings of Resolve) with the Project Manager, which is just a shell showing you what projects are available in a particular Library. Two different things. The database (the way I look at it) is the actual code itself, and that includes what's in the DRP and what's in the software.

It's true that a project isn't functional outside a database, but you can create and put databases wherever you want, and there's no limit to the number of them. And you can put any project into any database. If you double-click a .drp file, it will automatically install itself into the current database. And you can cut and paste projects between databases. You can even -- forbidden subject! -- copy project folders from one database to another. And of course the project files *do* contain all the information associated with the project, with the exception of some system settings (found in the database). If you're really determined to isolate project files, create a database for each project, which is what virtually everyone working on long form material does anyway. DB creation takes about 10 seconds, if you're slow.

That is pretty much what we do: when big projects come in, they get their own database. If a single client has multiple projects, we have one database (per year) for that client, so it's like "Viacom_2023" or "Netflix_2022" and then the series inside it, perhaps in a folder. And then individual episodes or projects inside that.

If you had a very busy facility with a half-dozen editors and a half-dozen colorists and lots of projects, you'd need to keep the project files somewhere. Sure, you could keep them in the source file folder, but then the problem is you'd have to get all the editors and colorists and assistants to agree where that place is. What if somebody disconnects a drive on which the project is stored? So the answer is, if the Project Manager is part of Resolve, that basically becomes the repository of where everybody knows where the project files are located. It's actually a pretty good system, and -- as I said -- this essential idea goes back at least 20-25 years with the old daVinci 888 and 2K systems before Resolve. It also allows using a Project Server, which feeds multiple users in multiple rooms, which is a very flexible way to work.

I think a lot of the b!tching and complaining comes from people who were exposed to Premiere over the last 10-15 years, and immediately want Resolve to bend towards their way of working. They can't think "outside the box" and understand that there are a lot of different approaches for user interfaces, and a lot different methods to solve problems in post, particularly workflow and project-based situations.

They also forget that a) there's at least six or seven other editing programs that are also wildly different from Premiere (and those won't bend either), b) there's over a million Resolve users who are used to the way it is now, so they're outnumbered, and c) Blackmagic only has so many resources, and they're busy making fixes and adding new features to a lot of different products. Dropping everything to completely redesign the Database Library and Project Manager is an unreasonable request -- you're basically saying, "I demand a heated swimming pool under the building," which would require tearing down the building first. It's a lot easier to live with the swimming pool where it already is.

Marc
I get that the Resolve DB works beautifully for you at a post facility where you don't have to move projects from one place and machine to another. It doesn't work so beautifully when that's a requirement.

In Resolve's "new world" of smaller creators, there are a great many more users who aren't in post houses than users who are.

I was pretty specific about the problems with trying to be portable by exporting and importing drp's here:
viewtopic.php?f=21&t=174906&view=unread#p920723

If you disagree with what I've written please elaborate. If not...

Sorry, folks, but those smaller creators have to understand one thing: they all profit from the early development of this software by da Vinci Systems from 20 years ago. It has a solid base coming from the time when it was only used in high-end facilities at a cost of 6 figures. Marc's analogy explains it nicely, it's not only about a GUI, but about the very foundation of this software.

Changing that for three different platforms would take so much effort that you'd definitely not get it for free any more, not even for 300 bucks. Plus, it would mean a long period of instability. So, I don't think it's going to happen. Improvements of the GUI to access it? Why not. But changing the foundation?

Live with it, or go for something else. For many current users DR is overkill anyway. Honestly, how many jump on it because "Hollywood is using it too" and you can get it for free?

For my part, I'd be much happier if BM were throwing all resources at ironing out real bugs instead of fixing something that works.
In all the years (starting from version 12.5), we had one single case of a crashed database. We were working all those years with students, starting as complete noobs. While I can't prove it, but I'm under the suspicion that a student tried in that case to do something at system level he shouldn't have done. He had moved the database from the schools machine to his private one and came back whining that his work was lost. After that, we blocked any copying of the database and allowed moving around only with .drp files. No more data loss after that, other than forgetting to export ones work.

Call me arrogant, if you like.

Young Padawan.jpeg (12.89 KiB) Viewed 2686 times