We just updated to Deadline Version: 7.1.0.35 R (2a6ca6695)
We are having issues with vray dbr jobs.
I have attached a screen grab of one of the issues we are seeing.
the list that vray uses doesnt seem to always match the list that deadline is displaying.
the other issue, which may be the same is that machines are actively refusing connections.
is there any updating that needs done on the slaves that a reboot wouldn’t handle? perhaps we have some machines that didnt fully automatically update?
new info from the artists:
Getting better results now thanks to Alex’s suggestion. I guess you have to reserve, update, then check all, then update again to get them to actually register under the list of machines.
– this seems overly complex.
Hi Troy,
The VRay native DBR slave list is redundant when you are reserving via Deadline’s ‘DBR’ UI. ie: ONLY those slaves which are checked (enabled) in the Deadline VRay DBR slave list will be used in the DBR session as the local user’s vray_dr.cfg file has now been modified. The VRay native slave list is actually looking at old information, so if you close it and re-open it, it would show the matching information that is in displayed in the Deadline UI. Unfortunately, VRay provides no maxscript function to update/modify any of the DR dialog settings, so we are unable to auto refresh them. I’ll poke Vlado and see if this can be added as a feature request on his side.
“Refusing connections” is typically an issue of port block / firewall block. Here are some notes which should help to debug the issue at your end:
docs.thinkboxsoftware.com/produc … r.html#faq
docs.thinkboxsoftware.com/produc … figuration
The local workstation vray logs also provide loads of information normally on what is going on here:
“%temp%\vraylog.txt”
Generally, I recommend to users to get VRay DR fully working in their studio, across all machines, iron out any edge case issues, all firewall/anti-virus turned off, then build the security backup to it’s normal state and then, finally, introduce Deadline, due to the number of false positives that are possible with each studio having a slightly different setup.
thanks for the info.
we were concerned because this worked fine, then we updated to 7.1 and no longer behaved the same.
If i get any additional info I will pass it along.
thanks for the help!
below is what our artists have found they need to do to keep from messing things up for each other.
So I’m not sure if everyone followed the previous thread where we were discussing issues with DRing in the new deadline version, but as an update, I believe I’ve found a small workaround for one of the issues that keeps arising.
When you first check out machines, you’ll need to press the check all button, and then hit update servers.
Now, the new step is, after you’re done DRing, before you release your machines, you need to uncheck all, and then hit update servers once more.
The issue is, if you simply hit release, it will free up the machines in deadline, but vray for some reason still thinks the DR nodes are connected to your machine, and thus, when the next person tries to DR using those machines, they will get the “actively refused” error.
So far I’ve had success using this method, but it requires everyone to do this in order to make sure all the DR nodes are responsive.
Thanks for the feedback Troy. Most useful to hear how your artists want it to work compared to the ideas (little voices) in my head!
So, I think there is 2 things we can do here to improve the experience for you:
-
Ensure ‘new’ slaves are checked ON by default in the list view. Saving an artist having to make another ‘click’ to get the default behaviour. (I already have this working here)
-
Store the local artists “DR Slaves” machine list as the Deadline DBR UI is opened and then restore this list, when the Deadline DBR UI is closed, which will mean we put back the machine’s settings as they were, before the Deadline DBR in-app submission UI was opened.
Let me know what you think of these ideas! (I think from reading your description that will answer your query)
Cheers,
Mike
Hi,
Please see attached updated VRay DBR & Corona DR in-app submitters and plugin files, which resolve a number of issues raised recently, including the 2 x issues which I discussed in my last reply with you. Extract the zip file to the correct paths in your existing repo, overwriting the same named files. (Ensure you do a simple file backup beforehand!)
patch.zip (23.5 KB)
Let us know if it helps?
we have deployed the new scripts, so far no one is complaining about it.
If i receive any feedback I will be sure to share it here.
thanks so much for sending this over!
Here is the feedback from the artists about the latest submission script tweaks.
FYI, the DR seems a bit screwy still. I had a job earlier and when I released the machines, it didn’t actually release them from the vray dialogue window, only deadline, so when I checked out 5 more machines it showed that I had 10.
Looks like you still need to manually uncheck the machines, then update servers, THEN you can release.
is this a training issue i should just tell them to get used to it or is it a code issue with the submission script?
Hi,
Yeah, I think this is a slight misunderstanding, combined with a limitation of the current VRay functionality available.
I should have mentioned in my last post, that there is currently no way to update the VRay DR settings dialog (which contains the machines list), whilst it is open via maxscript. If the artist closes the Deadline UI and then closes and re-opens the VRay DBR dialog, it will be up to date and contain the restored settings + any machines listed prior to the Deadline DBR UI being opened.
Also, un-checking the Deadline Slaves in the Deadline Slave List won’t stop the V-Ray Spawner process from running on the remote render nodes, but rather exclude them from the next DBR session that is started. This behaviour is then consistent with the built-in VRay settings dialog when you un-check (disable) a machine in their list.
To remove slaves, the Deadline UI should be closed or the job completed/failed/suspended in the Deadline Monitor. I don’t think we would want to introduce selective deleting of slaves in the slave list, as that might get quite confusing.
I’ll update our v7.2 (not yet in beta) docs to explain this new behaviour/functionality for other users.