Hi~I’m having this problem for weeks…pls help!
after I click ‘submit’ button,the submitting process keeps running but never finish(sanity check passed),the bar is always yellow,and the log info stops updating…I have checked the network configuration,surely I can acsses to the repository folder through my workstation,I even shut down the firewall both on my workstation and the repository server,then use a simple scene to test,also failed.other people don’t have this issue,only me,why?
below is the last part of the log file,hope someone can tell me what’s going on…
[??? ?? 10:17:39] : >Job Submission Started…
[??? ?? 10:17:39] : >BatchName: []
[??? ?? 10:17:39] : >Checking For Missing External Files…
[??? ?? 10:17:39] : +State Sets Dialog Closed.
[??? ?? 10:17:39] : +Closed Material Editor…
[??? ?? 10:17:39] : +Cleared Material Editor…
[??? ?? 10:17:39] : >Purifying the Render Elements Names…
[??? ?? 10:17:39] : >Updating Render Elements Paths…
[??? ?? 10:17:39] : +Updated Render Elements Paths.
[??? ?? 10:17:39] : >Submitting 3dsmax Render Job to Local Repository…
[??? ?? 10:17:39] : >Saving Scene For Submission to [C:\Users\3d-yaohao\AppData\Local\Thinkbox\Deadline7\temp\2018_10_29_?????10_17_39\test.max]
[??? ?? 10:17:40] : >Initiating Regular Job Submission…
[??? ?? 10:17:40] : >Submitting All Frames In One Job…
[??? ?? 10:17:40] : >Region Mode: none | Assembler Mode: DRAFT
[??? ?? 10:17:40] : Command Line Arguments: [-outputfiles
C:\Users\3d-yaohao\AppData\Local\Thinkbox\Deadline7\temp\2018_10_29?????10_17_39\submitOutput.txt
C:\Users\3d-yaohao\AppData\Local\Thinkbox\Deadline7\temp\2018_10_29?????10_17_39\submitExitCode.txt
C:\Users\3d-yaohao\AppData\Local\Thinkbox\Deadline7\temp\2018_10_29?????10_17_39\max_submit_info.job
C:\Users\3d-yaohao\AppData\Local\Thinkbox\Deadline7\temp\2018_10_29?????10_17_39\max_job_info.job
C:\Users\3d-yaohao\AppData\Local\Thinkbox\Deadline7\temp\2018_10_29?????_10_17_39\test.max
]
It appears that SMTD is doing its job right, and waiting (and waiting…) for the deadlineCommandBG call to return with a valid result. The default timeout value for Job Submission Timeout (under SMTD > Options tab > Submission Timeouts rollout) is 3600 seconds - a whole hour! You could reduce it to a more reasonable value like 120 seconds so SMTD would give up after about 2 minutes waiting.
Now we have to figure out why deadlineCommandBG is not returning after being called. It is supposed to write to two result files - one with an exit code, and one with an error code. SMTD is sitting around, waiting for those files to appear, and if it is hanging, then the files are never written to disk.
It would be useful to navigate to the latest submission folder (using SMTD > Tools menu > Explore Temporary Submission Folder… ) and locate the JOB files and the MAX scene file. In the above log, that would be the “C:\Users\3d-yaohao\AppData\Local\Thinkbox\Deadline7\temp\2018_10_29???_10_17_39”, or one like it. You could then try to open a console window in that folder and call the command line
to see what it will report. The DeadlineCommandBG version is just a version of the same application that writes its output to text files, but the actual results (and problems) should be the same).
If you get a valid error message, please post it here.
Also check if any submitOutput.txt and submitExitCode.txt files exist in that folder from the SMTD attempt…
Also we have to see what those ??? in the file name are doing to the file system. I assume they are non-Latin UniCode characters - it is possible they are causing the confusion, but it is unclear if they are the problem, or just show up like that in this forum. Attaching the actual log file would have been better.
I mean, it is possible that deadlineCommandBG writes its files, and the MAXScript function checking for their existence does not see them as the files it is expecting? We will have to investigate. If you could send a screenshot of the folder in question as seen in the File Explorer, it would also be very helpful.
The “?” character is normally a wildcard character in file names, as you probably know. It replaces a single occurrence of any character. It is thus not supported as part of a file name on Windows.
I will make a point to filter for it when creating file names in SMTD, as it appears the date and time format can produce these stand-in characters and cause the command line call to hang…
Thanks for confirming my suspicion, and sorry for the inconvenience!