Resolve Collaboration on Jellyfish: Problems Solved.

Hi,
I'm hoping someone is willing to spend some time helping me solve this issue since it is growing more complex and more urgent every day. I'm open to the idea that it is user error and am willing to put in the effort to figure it out.

Unfortunately, I can't confirm one way or another that this issue is only present with DR17beta. Our team decided to adopt the beta since some of the features save a lot of time every day. We are running DR17.0b build 18

You can see our network configuration in the attached image.
This works great (except for some audio delay) on a regular project.

Problems arise in a collaboration workflow.
Whenever a user is "kicked out" of a session, they see this dialog box:

resolvecollab.png (66.34 KiB) Viewed 8372 times

The user is then unable to enter the project, even after reboots of the workstation or client machines. A reboot of the resolve PostgreSQL server makes it possible for the user to come back into the project however shortly.

[*]Any single user can always use a project with collaboration enabled.
[*]User 3 is recognized by Resolve as being on a Mac, while she is working on a PC.
[*]Users 1 and 2 can often work together without problems. Sometimes any of two is kicked out of a session.
[*]Users 2 and 3 can sometimes work together without problems. However, recently the crashes and lockouts have become worse in this configuration.
[*]Users 1 and 3 can never work together.
[*]On a single occasion, the three have been together in a project. However, user 1 was not able to "see" user 3 in the project chat and binns.

All help will be greatly appreciated.

To clarify: users are running Resolve on machines in the office, on the LAN, and having an image of the screen shared to their home machines via Remote Desktop, so the actual VPN and firewall part is not visible to/from Resolve itself? Is that right?

And when you say "kicked out" do you mean literally Resolve says something like "You are being kicked out" or Resolve crashes, or the VPN/Remote Desktop goes down?

To clarify: users are running Resolve on machines in the office, on the LAN, and having an image of the screen shared to their home machines via Remote Desktop, so the actual VPN and firewall part is not visible to/from Resolve itself? Is that right?

That's correct the workstations themselves function on a local network without a firewall or VPN.
And the clients at home only display the workstations from the office. (and send keyboard/mouse commands).

And when you say "kicked out" do you mean literally Resolve says something like "You are being kicked out" or Resolve crashes or the VPN/Remote Desktop goes down?

When a user is "kicked out" the "cannot Enable Collaboration" dialog is shown. The user remains inside the project. However, the chat-icon and the User-icons disappear. And all the Binns and Timelines disappear. The project becomes completely empty. But only to that user, the other users can continue their work.
Resolve does not crash to desktop at this time and the RDP/VPN connections work the same.

Is there any meaning to the dotted line from PC2 to PC3 in your diagram?

And is it meant that the SAN is not connected through the Switch? (Or is there something like all three machines are connected to it via Thunderbolt or something?)

I don't have the experience with Collaboration to home in on a particular problem. Just getting clarification so that hopefully someone else can chime in.

Is there any meaning to the dotted line from PC2 to PC3 in your diagram?

You've caught me. That's a drawing error on my side. PC2 and PC3 are not directly connected to each other. My apologies.

We use a Jellyfish Mobile SAN.
The Resolve Database is hosted on there as well.
All the workstations are connected to the device twice (as per instructions of Lumaforge)
SAN port 1 connects to a switch so that all workstations enter the SAN on the same subnet (1Gbps).
used for the database connection.

SAN port 2 is a 10Gbps connection to PC1
SAN port 3 is a 10Gbps connection to PC2
SAN port 4 is a 10Gbps connection to PC3
these are used for media access.

Thank you for your questions. I know more information is probably the shortest way to an answer.

So your diagram really has a line from the Switch to the Jellyfish. And the Jellyfish does double-duty: 1) storage, and 2) Postgres server.

That double-connection part is a little scary -- and it seems you are also nervous about it since you mentioned that the instructions tell you to do this. Does it work with just the three PCs connected via the switch and not directly? (I assume it would be lower-performance, due to sharing the bandwidth, but I think your network is high-speed enough to be usable.) I don't know if configurations on the PC and Jellyfish side have to change for shared-network-only access. I would assume that the Jellyfish is capable of this kind of mode, since that's how most networks would be configured, but maybe not.

if you go in the office and connect the keyboard/mouse/monitor directly to the machine, do you see the issue?

it looks like a database server issue....

Hi Wayne,

Haha
I mentioned it since if someone would tell me they've come up with it themselves I would role my eyes to them. However, the double connection in itself has worked like this from the beginning. Also we made sure to build the network to the instructions with and double check the port assignments. As described here
https://support.lumaforge.com/how-to-set-up-your-network-for-davinci-resolve-collaboration

Every physical port on the Jellyfish gets a different subnet.
In order to connect to the same Resolve database, the workstations need to be on the same subnet. Therefore each workstation connects to a switch using a regular (1Gb/s) connection. That switch enters one physical port on the In resolve, we enter the address of the database and everything is great.

Then to access the media files we connect using a 10Gb/s connection to a dedicated port for that machine on the Jellyfish. The SAN

if you go in the office and connect the keyboard/mouse/monitor directly to the machine, do you see the issue?

it looks like a database server issue....

Thank Walter.
We're going in on Thursday. I have a couple of test planned.
1. Try and exclude RDP
2. Try to exclude VPN connection into the office
3. Hosting a database on one of the workstations and see if the problems continue.
4. if not, build a fresh DB on the Jellyfish

Any other things I should look at?

if you go in the office and connect the keyboard/mouse/monitor directly to the machine, do you see the issue?

it looks like a database server issue....

Thank Walter.
We're going in on Thursday. I have a couple of test planned.
1. Try and exclude RDP
2. Try to exclude VPN connection into the office
3. Hosting a database on one of the workstations and see if the problems continue.
4. if not, build a fresh DB on the Jellyfish

Any other things I should look at?

it is recommended that the resolve database is on a separate machine like a mini mac....

it is recommended that the resolve database is on a separate machine like a mini mac....

Which would also fix the two-connection issue, since as I understand it you are only connecting via the switch because you're also running Postgres on the Jellyfish. Run it on a separate machine -- even one of the PCs, but better a fourth PC -- and there's no potential loop or dual identities with the Jellyfish.

(Unless the NAS part of Jellyfish recommends dual connections. But at least that's at the OS level -- i.e. storage -- rather than potentially confusing Postgres.

[Dwaine Maggart]

After extensively troubleshooting that error message recently, on a very simple 2 Windows PC in the same location on a local network, I can guarantee that what's causing the issue, is something blocking TCP port 50059 access between the systems. In this instance, it was Windows Defender firewall blocking access.

Your situation is much more complicated.

But it basically boils down to this.

For collaboration to work, there are 2 communication channels involved.

The first is that the Resolve clients need to communicate with the database server, and that happens normally over TCP port 5432. If all the clients can see the collab database, then we know that channel is working.

The second is the clients need to communicate with each other. This normally happens over TCP port 50059.

If any one Resolve client connects to a collab project, it does not matter if the port 50059 access is working or not. But if one or more clients are already connected to a collab project, and another client tries to load the project, and a few seconds later gets the error message at the top of this thread, that means the port 50059 communication to the other system(s) has failed for some reason.

The way Resolve knows how to communicate between all the clients, is that it stores the client IP addresses in the collab database. So if the clients happen to be on different subnets, and you have a router/switch managing that, it's important that the router/switch not do any sort of NAT between the database server and the clients, else the database server client IP addresses will be of the router/switch doing the NAT, rather than the actual client IP address. That will cause collab not to work.

When Resolve loads a collab project, it opens TCP port 50059 to listen for other clients. Thus for troubleshooting port 50059 issues, you need to make sure the client you are trouble shooting has a collab project loaded.

In your case where some clients have the collab project loaded, and the client you are trying to use gets the error at the top, you need to test the port 50059 acccess. If you are on a Windows machine, you can do this test from a PowerShell window opened in Admin mode. This is the command syntax:

Test-NetConnection -ComputerName COMPUTER_NAME -Port PORT_NUMBER

Replace COMPUTER_NAME with the name or IP address of the remote computer you are testing 50059 access to. And PORT_NUMBER with the port you want to test:

Test-NetConnection -ComputerName 192.168.1.151 -Port 50059

If access to TCP port 50059 fails, you'll get a yellow error message telling you this. In the case of a TCP connect failure, it will also do a ping, and present the results of that in the status message. If the ping also fails, you've got a more serious network issue. If the ping works but TCP fails, you need to sort out why.

This is what a successful test looks like:

test_netconnection_success.PNG (7.41 KiB) Viewed 8287 times

This is what a failed TCP connect test looks like:

test_netconnection_fail.PNG (10.53 KiB) Viewed 8287 times

Again, if the machine you are running this test against does NOT have a collab project loaded, the TCP connect will fail.

I hope this might give you enough info to troubleshoot further.

Hi Dwaine,
Thank you very much for this information! This is exactly what I need.

Could you please clarify what computer you mean when you say:
"the name or IP address of the remote computer you are testing 50059 access to."
Is that the address of the machine with the database?

I just want to be sure since the word "remote" is used a lot in my workflow.
Thanks

The 50059 is used to communicate between the PCs that are collaborating. The database is accessed by port 5432. Your VPN and Remote Desktop don't matter.

Alright, we are making progress.

1. We tested the 50059 ports on against all workstations.
When a workstation has a collaboration project opened their 50059 port is working.

2. We've added explicit inbound/outbound exceptions on port 50059 on all workstations.
(no changes but can't hurt)

3. We've tested port 50059 on the Jellyfish (SAN) (where the Resolve DB is hosted)
50059 closed on the Jellyfish. But this machine is not really participating, only hosting the database.

4. I've build a quick test database and hosted it on workstation#1.
The collaboration project worked like it is supposed to.

5. We've created a new database on the Jellyfish to rule out a DB error.
We were back to some of the old behaviour. Not so much the error message, but problems with name and chat behaviour.

That leaves me with the conclusion that the Jellyfish is a part of the problem here.
We are now looking to open up port 50059 on the Jellyfish (through support).
If the problems continue even then, I'm convinced we need to spin up a different machine to host the DB.
I'll update the thread if we come closer to the solution.

Again, thank you all for helping me out here!

Per Peter's description, it makes sense. The Jellyfish knows each PC by two different addresses: the official address on the LAN, and the Jellyfish-only address of each direct-connect. Since Postgres is running on the Jellyfish, it sees both of these addresses and somehow picks one to record as the PCs address. The PCs read this and communicate with each other via port 50059.

Currently, if the address that Postgres records is the LAN address, things work. If the address it records is the Jellyfish-only address, it breaks because the other PCs try to contact the unfortunate PC via the Jellyfish, which doesn't listen to port 50059.

If you enable port 50059 on the Jellyfish, you may or may not fix the problem. The Jellyfish should never be set up to route traffic through it. If I heard you were trying to do this and I was with IT, I'd shut this whole thing down for shenanigans. You simply don't introduce unofficial routers onto a network.

If enabling 50059 works, then you've taken advantage of a misconfigured Jellyfish and a naive IT department in order to set up an unofficial router. But there's a chance that the Jellyfish is properly configured to not route traffic through it, in which case port 50059 will make no difference and it still won't work.

You really need to move Postgres off of the Jellyfish and onto another machine.You've proved that works. I know hosting it on one of the PCs doesn't feel like the best solution. But as a quick workaround while you get another PC, it works. And if the PCs are powerful enough you might not even notice.

[Dwaine Maggart]

You might contact LumaForge support to see if they can assist you with the Jellyfish setup.

Thanks guy's
As both of you mentioned, I believe the problem lies with the Jellyfish and we have contacted Lumaforge support.
I thought to include the summery here in the thread for future reference.
And I will add to the thread if a more concrete cause had been found. Again, for future reference.

For now, we've set up a new database on one of the workstations and will import all the relevant projects there.

Again, thanks for all your help!

Thanks guy's
As both of you mentioned, I believe the problem lies with the Jellyfish and we have contacted Lumaforge support.

It's possible that you can do some fancy work in Windows to have the OS not let any user applications know about the secondary IP address (your connection to the Jellyfish) and to not do anything except share the drive through that secondary connection. If Windows and BMD software and everything else on the PCs only communicates and knows about the real LAN address, it will all work because only that address will be recorded by BMD in Postgres so the PCs will only attempt to communicate appropriately across the LAN.

Otherwise, this is working properly and as expected: each PC has two addresses and if the wrong one gets entered into Postgres (by BMD) that machine will be kicked from the collaboration because the PCs don't communicate with the outside world via the Jellyfish.

Hi Wayne,

I appreciate your insight.
Lumaforge sold us this unit specifically with this use case in mind.
If it works but only with extra settings, they should know about it so that they may change their support documents.
But it's good to know it's not a Resolve thing.

Hi Wayne,
But it's good to know it's not a Resolve thing.

Lumaforge will say that it's a Resolve thing. They will say that Resolve is picking the wrong IP address to record in the database, that they should know which one is the "public" IP address and save that, not the secondary Jellyfish-only IP address.

And if push comes to shove, that's probably technically true. It would add considerable complication for BMD to try to handle this non-standard use case, though. But maybe in Windows you can hide the secondary IP address from everyone except the remote disk drivers, in which case Resolve would work as normal. Here's hoping that's the case.

Just a quick update for people who are running into similar problems.

Lumaforge support has solved the problem by SSH-ing into our Jellyfish and filtering the database traffic.

At the same time, my colleague noticed that subnetmask of one of the workstations was setup wrong.
This is probably what caused the issue in the first place.

Things are working like they should.

If access to TCP port 50059 fails, you'll get a yellow error message telling you this. In the case of a TCP connect failure, it will also do a ping, and present the results of that in the status message. If the ping also fails, you've got a more serious network issue. If the ping works but TCP fails, you need to sort out why.

We are facing this error when we try to work on the same project by sharing a database between two systems.

Cannot enable Collaboration

Photo from Krishna.jpg (15.21 KiB) Viewed 5210 times

Collaboration works fine when we first open the Davinci Resolve Shared Project on the Server System and then succeedingly turn on the same project in the Client System.
But when Davinci Resolve Shared Project is first opened in the Server system and then we open the same project on the Client system, we get this error.

As mentioned by you, we checked the access to TCP port 50059 and it failed as shown in below Attachment.

Access to TCP port 50059

Picture1.jpg (67.13 KiB) Viewed 5210 times

What Should we do to further Solve this issue?

[Dwaine Maggart]

Please provide a full description of your setup. Including all the computers involved, what operating systems they are running and what Resolve versions they are using.

It sounds like you may be using the system that's hosting the shared database server also as a Resolve client system. Is that the case? So 2 total systems? And one running the Resolve Project Server app? If so, what version of Project Server app? And what version of Resolve? Both systems Windows 10?

You've tried disabling firewalls on both systems?

Please provide a full description of your setup. Including all the computers involved, what operating systems they are running and what Resolve versions they are using.

It sounds like you may be using the system that's hosting the shared database server also as a Resolve client system. Is that the case? So 2 total systems? And one running the Resolve Project Server app? If so, what version of Project Server app? And what version of Resolve? Both systems Windows 10?

You've tried disabling firewalls on both systems?

Thank You For the Reply.

Yes, we are using the system that's hosting the shared database server also as a Resolve Client System for some Databases.
Total two Systems are involved that share the same Davinci Resolve Studio Key.

Description of both Systems is as follows :

Server System
Davinci Resolve Version : 18.0.1
Project Server Version : 18.0.1
Operating System : Windows 10 Pro 21H2
Processor: AMD Ryzen 9 5900X
RAM: 32 GB 4000Mhz
Motherboard: MSI X70 Tomahok Wifi
Graphic Card: RTX 3060Ti
SSD: 1TB Nvme Pro M.2 Samsung

Client System
Davinci Resolve Version : 18.0.1
Project Server Version : 18.0.1
Operating System : Windows 10 Pro 21H2
Processor: Intel i7 1200k
RAM: 16 GB 3400Mhz
Motherboard: Gigabyte Z690 UD AX
Graphic Card: RTX 3060
SSD: 1TB WD Green NVME M.2

We just tried to disable firewall and do the same procedure where we were getting the error of 'Cannot Enable Collaboration', and Resolve Studio is working fine for now.
Can you Explain why it is working fine with the firewall off?

I don't think keeping firewall off is the solution we should abide by..

Is that the only solution or is there some other solution that you can help us with so we can work on both systems whenever we want irrespective of which one is opened first.

Or we should Continue with the Procedure of opening Resolve first on the Server System, and then on the Client System with the firewall on?

It would be great if you can explain what's happening here in this situation.

[Dwaine Maggart]

It sounds like one or both firewalls are blocking TCP port 50059.

You need to make a rule to allow that through.

What type of firewalls are you using? If you are using the Windows Defender Firewall, I would have expected the Resolve and/or Project Server installer to properly configure the firewall settings to work.

If you have some other firewall, you'd likely need to do that yourself.

You might turn off one firewall at a time, and see if one or the other is causing the issue, or if both are. If it's just one of them, concentrate on that one.

It sounds like one or both firewalls are blocking TCP port 50059.

You need to make a rule to allow that through.

What type of firewalls are you using? If you are using the Windows Defender Firewall, I would have expected the Resolve and/or Project Server installer to properly configure the firewall settings to work.

If you have some other firewall, you'd likely need to do that yourself.

You might turn off one firewall at a time, and see if one or the other is causing the issue, or if both are. If it's just one of them, concentrate on that one.

We tried turning off the firewalls, and the mentioned error did not appear after doing so.
Then we turned on the firewall and also we made a new inbound rule in the Server System allowing 50059 port.

We waited for a few days to see if it works fine or the error arises again.
Currently the Resolve is working fine on both the systems irrespective of opening sequence in both systems.

I have a small suggestion - it would be great if we can get more control over customization of our workspace panels in resolve, if you could convey this to the UI Team.

Thank You Dwaine for the Support.

[quote="Dwaine Maggart"][/quote]

Hi Dwaine,

We are working with two systems on a shared SQL database that share the same Davinci Resolve Studio Key.
We have been working on a 1Hr 15 Minutes timeline in a project for around 5 months. It had been running fine until we started using fusion more frequently for doing VFx. As a result, the project speed has been deteriorated (from past 15-20 days). The whole project has been slowed down, especially the main timeline (takes around 20 seconds to open) and the software has started freezing and crashing more frequently on both the systems.

In the Client System Davinci resolve is freezing and crashing twice or thrice in every 10 minutes.
In the Server System the Davinci Resolve is Crashing after every minute of opening the main timeline in that project (except, if we straight away open the fairlight page).

To Explain what we have on the timeline:

Around 900 Clips, with Color Correction and Color Grading.
In Sound, we have installed and used some sound plugins and Davinci Resolve Audio Fx.

We have tried the following solutions in order to get the project function fast as it did before:-
1.) Creating New Project in same database.
2.) Creating a new Database and moving the same project into it.
3.) Rendering in place the Fusion Clips.
4.) Deleting all the Cache files and the temporary files from the system because C Drive got almost full in the Server System.
5.) Removing some of the inserted plugins from audio clips.
(The number of clips have been same throughout the whole process in the main timeline)

None of the above mentioned points worked.
Problem has come to the stage that it has become difficult to work on the main timeline for more than 2 minutes.

What could be the possible reasons for frequent crashing and freezing of the software and what can be the possible solutions for the same?

If you can mention some tips and things we need to take care for avoiding such problems with such projects in future, kindly let us know.

Description of both Systems is as follows :

Server System
Davinci Resolve Version : 18.0.1
Project Server Version : 18.0.1
Operating System : Windows 10 Pro 21H2
Processor: AMD Ryzen 9 5900X
RAM: 32 GB 4000Mhz
Motherboard: MSI X70 Tomahok Wifi
Graphic Card: RTX 3060Ti
SSD: 1TB Nvme Pro M.2 Samsung

Client System
Davinci Resolve Version : 18.0.1
Project Server Version : 18.0.1
Operating System : Windows 10 Pro 21H2
Processor: Intel i7 1200k
RAM: 16 GB 3400Mhz
Motherboard: Gigabyte Z690 UD AX
Graphic Card: RTX 3060
SSD: 1TB WD Green NVME M.2

[Dwaine Maggart]

It would be helpful, as a start, to have a Resolve diagnostics log from each system, generated after a crash. You can do from from the Resolve Help menu, after restarting from the crash.

Also a Windows System Information .NFO file from each system, generated after a crash. Do that by opening the Windows System Information app, and selecting it's File menu, then Save.

Put all the files on a file sharing site and provide a link to the files. Note which files are which.

Hi Dwaine,

Here is the drive link which you asked for, that contains the following information of both systems:

1) System Information
2) Resolve Crash Logs

https://drive.google.com/drive/folders/1B9rRRhve8C1oB_KmYeMhXZFimxgudFEz?usp=sharing

[Dwaine Maggart]

I don't see anything really obvious in the logs to explain the behavior.

Since you say it seems to have started once you started using Fusion more heavily, I would mention that Fusion likes lots of RAM. You'll note that the recommended minimum system requirements when using Fusion is 32 GB. That's a minimum. One of your systems meets that. The other, at 16 GB does not. But in fact, you probably want well more than the minimum if you are using Fusion heavily.

So perhaps a RAM upgrade would help the situation.

Hello, I'm almost having DVR collaboration working but still have issue for distant access (through WG vpn), I explain my case in this post
viewtopic.php?f=21&t=113335#p1006917

any help is welcome.