Also, are you using the Shotgun event plugin? There’s a known leak there, so we might need to set up a machine limit to make sure it’s always used on the same machines.
It’s also going to be fixed in Deadline 7.0. That’s hopefully due out before 2015, and you can beta test now if you want to give that a whirl.
The problem here is that Draft checks out a license when it is imported, and Deadline’s internal Python environment (like what’s used in regular render plugins and event plugins) is only cleared out on exit. The incompatibility here wasn’t considered when we wrote out everything. Hindsight is always a bit clearer.
Now, I’ve never tried this before, but this could be really interesting. Read here: blog.bfitz.us/?p=2052
That whole thing distills down to so:
del sys.modules["Draft"]
del Draft
Might work? Otherwise we can make a little machine group. It’s far from ideal, but should help workaround the problem until we can get a Draft build to you that will fix this.
Note: Draft 1.2 (for Deadline 7) only checks out the licence while actually encoding or decoding video, so that will help too… but will require the new Draft & Deadline.
The del lines don’t seem to help the license being returned. Looks like I may need to add a default group to my custom event to limit the license to certain boxes for now.
Unfortunately, that seems to be the case. Python’s had this kind of limitation awhile now (some people showed me recently).
Be on the lookout for an updated Draft. Version 1.2 should have this whole thing sorted out. I’m told that’s happening in Deadline 7, so I can get you on the beta if you like.
In Deadline 7.0, it will only check out a license while encoding or decoding video, and should give the license back once the video streams are closed.
Thank you so much for this hint, Edwin! It worked in my case where I combine two separate draft scripts in one via execfile to get two versions of one input encoded.
I got the license error because draft is imported in each of the two separate scripts (they shall also work on their own). It seems like the second import caused the license error then.
Another option that might be better for your case is to modify the scripts so that they can either be run stand-alone or imported as a function. To do so, (1) put the existing code in a function that takes parameters appropriate for the functionality, (2) create a main function that does any appropriate parameter setup then calls the function created in step 1, then (3) put in a conditional that calls main if the script is being called as a stand-alone script. Example:
[code]import Draft
import os
import sys
from DraftParamParser import *
def my_script_function( params ):
# code that does what the script is supposed to do
# Parse the command line arguments
params = ParseCommandLine( expectedTypes, sys.argv )
my_script_function( params )
if name == “main”: main()[/code]Then, in the script that calls the two scripts, you just need to import both files and call the methods that you created with the appropriate parameters:
[code]import Draft
import sys
from DraftParamParser import *