Blackmagic Forum

I'm new to the project server and the collaboration features. But I am interested, so I bought a 2nd license of Studio for a 2nd machine. I've installed [non-Studio] Resolve on a 3rd machine on the local net to act as the Project Server. I fire it up, make a new PostgresQL database, activate sharing, and create access key.

But when I try to use that Access Key from one of the other two machines on the network (that have Studio 15.2.2.007) I get:

Error: Failed to connect to the database. Please check log file for more details.

The machines can ping each other. So the network seems to be working and not firewalled or something. I don't know where in the log to find any meaningful information. So I'm at a bit of a loss.

Anyone have experience with this? Thanks!

Edit: I'm on all-Windows environment. The machines are on the same subnet: 192.168.0

Pay attention to open the the right port in you firewall. I don’t remember the number but it is specified in the manual.

GregAusina wrote:Pay attention to open the the right port in you firewall. I don’t remember the number but it is specified in the manual.

I don't see it anywhere in the manual. I just looked again through chapter 147 "Managing Databases and Project Servers" and don't see anything about opening ports. Do you know where it is?

The default port for a PostgreSQL server is 5432 (TCP). That's not something that is specific to Davinci Resolve so perhaps it's not in the manual.

Kevin Good wrote:I'm new to the project server and the collaboration features. But I am interested, so I bought a 2nd license of Studio for a 2nd machine. I've installed [non-Studio] Resolve on a 3rd machine on the local net to act as the Project Server. I fire it up, make a new PostgresQL database, activate sharing, and create access key.

But when I try to use that Access Key from one of the other two machines on the network (that have Studio 15.2.2.007) I get:

Error: Failed to connect to the database. Please check log file for more details.

Just finished building out a collaborative setup at my office -- first reaction to your problem makes me think it's a pg_hba.conf issue:

viewtopic.php?f=21&t=60954


On most network setups I've tested you have to manually add the IP and subnet of clients that are going to connect to the database, and if they are on different subnets you need to alter the key generated by Resolve's Project Server too (doesn't sound like that matters in your situation).

I doubt it's firewall related but some ports you might try opening up related to postgresql (credit to Chip Murphy over on LGG):

-1500
-4000
-8000
-29001
-56789


Most of this stuff is not in the manual, which is too bad but I guess it's relatively niche and can't easily be generalized.


Edit: oh just noticed you said you installed non-studio on the Project Server machine -- I'm not sure that mixing versions is supported. You do not need a license on the Project Server machine but I'm pretty sure you do need to be running Studio on all machines.

Jed Mitchell wrote:first reaction to your problem makes me think it's a pg_hba.conf issue

Thankfully with recent versions of Resolve, if you use the included PostgreSQL setup and use project server to create the access key you should no longer need to make manual changes to pg_hba.conf.

roger.magnusson wrote:Thankfully with recent versions of Resolve, if you use the included PostgreSQL setup and use project server to create the access key you should no longer need to make manual changes to pg_hba.conf.

Yes, that's the theory -- in practice I've never seen it behave automatically when hosted from an independent server, either in 14.3 or any flavor of 15. Point-to-point shared databases with a simple router between two desktop OS workstations have functioned out of the box for me but never a dedicated server. Since modifying the hba file is such an easy fix I'd still give it a try when you see that error in the logs.

Oh, the other thing is to see if the access key is pointing at 127.0.0.1 or at the correct server IP address -- it's just a plain text file so easy to poke inside and see what was generated. This isn't usually an issue unless you're running multiple subnets but worth a look.

Thank you Jed! I opened the firewall for the postgresql.exe, and I added the link to the config file and it seems to be working. Searching around the forum before I asked the question I had actually read that thread you linked to. But people were saying that was already a resolved issue in the newer release, so I didn't think it applied and I was continuing my hunt.

I got it working. And for the record the Project Server doesn't have to be a Studio install (that, it does specifically say in the manual. Either version will work.) Since I don't have a license for that machine I figured non-studio is better because then there's a chance someone still could work (independently) on something from the 'server' machine.

Thanks again all! Frustrating stuff. Glad to have it... Resolve-d.

Kevin Good wrote:And for the record the Project Server doesn't have to be a Studio install (that, it does specifically say in the manual. Either version will work.)

Oh, that's good to know -- our servers are tucked away in a rack so I've never even bothered to launch Resolve on them, just the Project Server. Thanks for pointing that out and glad the .conf fix helped.

Kevin Good wrote:I'm new to the project server and the collaboration features. But I am interested, so I bought a 2nd license of Studio for a 2nd machine.

I am slightly confused why you purchased a 2nd license, as you can license 2 machines with a single Studio activation license?

The server does not have to have Resolve on the machine at all. All that's required is the PostgreSQL server, it's a free third party software. Resolve just installs the PostgreSQL as an option.

hi, how to connect to a db NOT on the 5432 port ?
using 127.0.0.1:9999 doesn't work
5432 seems to be hard locked

Jed Mitchell wrote: if they are on different subnets you need to alter the key generated by Resolve's Project Server too (doesn't sound like that matters in your situation).

Any hints on how to connect multiple machines with davinci to a non-local postgresql server ?
All functions good, but when the second user connects, it gets an error after ~10-20 seconds (I believe it is trying to communicate with the other user):

"Unable to load the project in collaboration mode as Resolve was unable to establish a connection to communicate with other users.
Please ensure that the machines are not connected using a VPN and that davinci is not being blocked by the system firewall."

Is Resolve limited only to local, same subnet collaboration? Thank you very much !
(Postgresql 11.5 on Ubuntu 18.04, ports 5432 and 56789 open, pg_hba.conf and postgresql.conf modified to accept all connections, 2x Resolve Studio licenses, connect from iMac and PC)

mirceabanu wrote:All functions good, but when the second user connects, it gets an error after ~10-20 seconds (I believe it is trying to communicate with the other user):

Yeah that bit I put in bold from your quote is the important part, from what I can tell.

I have (for now at least) "solved" our issues -- it had to do with subnet priority on the different workstations, because our machines all run on several connections for different purposes:

1.) 10GbE for direct (unswitched) access to shared storage
2.) 1GbE for (switched) communication with the server (Resolve, FlexLM, etc), renderfarm, intranet
3.) WiFi for internet (completely separate gateway)

It's not well documented so I'll just lay out my best understanding of the current Resolve 16 Project Server architecture:

**Reading database for project access**

Machine1 ==>> Project Server <<== Machine2

For simple access to the project, the machines can be on whatever subnet they want. So:

Machine1: WiFi, connected to server via router on 192.168.1.0/24
Machine2: Ethernet, connected to server via switch on 172.16.85.0/24

Machine1: server has the static address 192.168.1.50
Machine2: server has the static address 172.16.85.50

Both server addresses are valid: access keys just need to use the correct one for each workstation.

**Communicating user activity/bin locks/status**

........>> Project Server <<..........
........^^.....................^^...........
........^^.....................^^...........
Machine1 <<=====>> Machine2

For the second part of the equation, machine-to-machine communication, the Project Server doesn't negotiate communication at all (as far as I can tell), the two machines need to resolve an IP address for each other, tell each other what they are doing, then report that back to the Project Server independently for committing writes to the database (which might be why Live Save is so slow in collaboration?).

So let's say Machine1 is parked at 192.168.1.101 and Machine2 is 172.16.85.102 and... WAIT!

They're on different subnets! So even though they can both see the server, they can't see each other!

What I realized was that each workstation was prioritizing a different NIC in our setup. So when one pair of machines was in the same project it might be fine because they were both prioritizing the 1GbE network, but if one machine was favoring the WiFi we'd get that generic error message.

As of Resolve 16 that shouldn't be an issue anymore -- on page 2941 of the manual there's a passage alluding to the new Project Server ability to negotiate different subnets. So if Resolve 16 can collaborate across multiple subnets, why are we still getting an error? Well... I'm sure there are complications with machines running on multiple subnets, but it might also be a slightly "unfinished" feature.

My solution was fixing the NIC priorities to be the same everywhere, keeping everyone on a single subnet for Resolve traffic. Since then we haven't see the error message.

Plenty of other collaboration bugs and crashes though... and really, there is like half of one page devoted to this whole topic in the manual, and a single error message to cover all possible issues. I think this is one place where the documentation & logging could stand to be a bit more verbose!

So people like me can stop trying to guess about it on the forums...

~~

This may not be quite the solution to your problem, but hopefully it helps with your search -- I think if you can't get all the collaborating machines onto a subnet together (doesn't matter which one) you're going to have issues, regardless of what the manual says.

mirceabanu wrote:"Unable to load the project in collaboration mode as Resolve was unable to establish a connection to communicate with other users.
Please ensure that the machines are not connected using a VPN and that davinci is not being blocked by the system firewall."

I have the same issue, trying to get this working across WAN/fiber-internet. Would love to hear if anyone has a solution. I have opened for port 5432 and connect fine to server, but when trying to start collaboration mode I get the quoted message also, and it won't work.

Hey gang-- thanks for the prior advice. I am trying to get Project Server working on a new system, and having trouble.

Machine 1) Windows, running postgresql database, as well as Resolve Studio 17 beta.
Machine 2) Windows, Client for running Resolve Studio 17 beta

If ONE of the machines connects to the database and opens the project, everything works fine. If the 2nd machine connects, then Machine 1 gives this error "Cannot Enable Collaboration":


I've confirmed both are on the same subnet. I've tried disabling Windows Firewall. I've tried changing NIC priority as per Jed Mitchell's suggestion. I tried disabling IPv6.

Clearly the machines can talk to each other, because machine 2 can work off of the machine 1 database just fine. But both can't work together at the same time.

Thanks for any suggestions/insight!

Send Resolve logs and System Information NFO files from both systems.

Dwaine Maggart wrote:Send Resolve logs and System Information NFO files from both systems.

Hi Dwaine,

I've posted that you cannot enable collaboration between 17b6 and 17.1b6 here.
Could you please comment if this in intentional (i.e. implementations are incompatible) or just a glitch in the Beta?

Answered in your other thread.