In beta 5, RVIO jobs that depended on another job would not start until I released the dependency
In beta 7 and 6, the job just hangs as long as it’s assigned to the RVIO pool Ive set up (two machines). When I remove the pool setting, the job starts on a machine that’s not member of the RVIO pool because it can’t run RVIO
When I run the slave ONLY on my machine and submit anb RVIO job, nothing happens. If I then submit a Maya job with LOWER priority than the RVIO job Ive already submitted, the Maya job starts right away
And another thing: Deadline sometimes fails to detect RVIO errors. It thinks the job has completed, when the actual output shows:
0: STDOUT: INFO: output compressor H.264
0: STDOUT: INFO: output codec H.264
0: STDOUT: INFO: video output format is 1920x1080 24-bit H.264 at 24 fps with datarate: 5000000 and keyframe interval: 0
0: STDOUT: ERROR: ICMCompressionSessionCreate() failed with err=-8961 in TwkMovie::MovieQTWriter::createCompressionSession, line 2638
0: STDOUT: ERROR: createCompressionSession() failed with err=-8961 in TwkMovie::MovieQTWriter::write, line 615
0: INFO: Process exit code: 0
Edit: Submitting the same job as a CommandScript works without a hitch, so the problem does not lie with the specific macine being used, or RVIO
When not running pulse, Dependencies are released at random intervals. When running Pulse, they are released at regular intervals. Maybe try running Pulse for a bit just to confirm that the dependencies are released properly: thinkboxsoftware.com/deadline-pulse/
The releasing of dependencies are completely separate from the job type. We use dependencies here all the time (we have dependent jobs that are used to build the Deadline binaries and installers), and we’ve had no problems with them.
By “hang”, do you mean the job never gets picked up, or does it get picked up and the rvio process hangs? If the job never starts, there might be something else preventing the slaves from picking up the job. A quick way to see which slaves can render the job is to show the slave list, and then enable the “Show Slaves That Can Render The Selected Job” filter (see attached image). This will show you which slaves can render the job that is selected in the job list.
Thanks for finding that. We’ll have to update our stdout handlers to catch those errors and fail the job.
That’s an indication that something in the job properties is preventing the job from running on your machine. Can you post the following:
Two screen jobs of the job’s properties window (right-click on the job in the monitor and select Modify Job Properties). I need a screen shot of the General and Machine Limit tabs.
A screen shot of the row for your machine in the monitor’s slave list. Make sure the Pools and Groups columns are visible and expanded to show all the pools and groups for your machine.
HAHA, I found it. You pointed me in the right direction.
The Machine Limit was set to a machine that no longer existed in the repository. Deadline didn’t provide any warning about that, and I simply didn’t catch that little detail in the gui.
The problem with pending jobs not starting is gone as well. We’re currently running beta 7; can’t remember which beta we were running while that problem was occurring.
While, we’re at it, another tiny RVIO bug: The submit gui refuses to load image sequences with more than 5 digits in the frame number. Any frame number above 99 999 is converted to 99 999. Our live action plates use the original Red camera time codes, which often are above 100 000 or even 1 million
Hmm, that’s more than an RVIO issue, because Deadline itself currently doesn’t support frame numbers larger than 99999. We’ll see if we can address this before 5.0 is released.
