I’m testing out region rendering using Deadline 7, Maya 2016, and vray using Windows 8.1. The tile job submits fine, but the assembly job errors with “The command line is too long” (I still get a dialog saying “Done submitting 2 jobs.”). Windows has a command line limit of 8000-something characters and the submission command is over 9000. It seems to be because of the number of render elements being used (each element gets its own text file and assembly job).
Is there any way to make this work with an arbitrary number of render elements? If not, any recommendations for replacing the assembly job with a custom one that would work while leaving the gui as-is?
There isn’t an easy way to resubmit tiles, and it requires you to hand-roll the config file.
I feel like we may have fixed this particular problem within Deadline 7’s lifecycle. I’m trying to chase the devs about it to make sure, but what version of 7.x are you on?
The company I work for is Saatchi & Saatchi LA (I used my personal email to register). There are two current things holding us back from upgrading right now; we’re in a busier time for production and are holding a lot of systemic upgrades until the end of the year and I noticed we’ve modified a lot of Deadline’s scripts in place instead of using callbacks. So upgrading would cause a huge impact right now. I’m trying to address #2 right now by trying to make sense of our changes and refactor them into callbacks, if possible.
The issue is all in the deadline submit mel script when it shells out to submit the assembly job, so I feel like this specific thing could be addressed without upgrading everything (although, I’d like to move to a newer version as quickly as possible). Your support had sent us a newer version of that script for an unrelated issue, but when looking at it briefly it didn’t look like it had addressed this issue. So I was just curious if a) that’s an issue that’s known about and is fixed in version $x b) that issue is not something that is planned to be addressed or c) it can be worked around by changing this thing.
There have been a few assembly issues in the past, and one workaround was to change where the Slave put it’s Data folder.
As far as fixing this, I’ll have to see if it’s within our ability to do so… I know the SMTD gets around the long paths usually by writing the DeadlineCommand instructions to a file and executing them. I’ll go bounce the idea off the integration guys.
Thw plan to fix this is to move the massive call to DeadlineCommand for the assembly job into what’s called an args file is a go. This has been around awhile because it is how the SMTD is able to submit thousands of assets in a single job.
Now, I’m not sure when we’ll be able to get this done, but if you’re willing to try it for yourself, the docs have an example here:
Thanks for the quick response. I wasn’t sure how detailed to get =) From what I’m seeing it was already writing each job to a job file, but with so many layers the list of files exceeded the length. Writing an args file, like you said, should address this. I might also just split job the job files and call the submit command a couple times (but not once per file, that’d be too slow).
Glad you’re planning to address this. I’m not sure when I’ll be able to get to this–I’d prefer to use your solution if it works to keep the maintenance burden off us. We’ll see who can fix it first =)
