[code]Shot_0100_r00_v00.nk: The directory is not empty.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive)
at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive)
at FranticX.IO.Directory2.Delete(String path, Boolean recursive, Int32 attempts, TimeSpan retryDelay)
at Deadline.Storage.JobStorage.CreateNewTasks(Job job, Task[] tasks)
at Deadline.Controllers.DeadlineController.ChangeJobFrames(Job job, String newFramesList, Int32 newChunkSize, Boolean reorderFrames)
at Deadline.Applications.Commands.JobModifyTasks.InnerExecute() (System.Exception)
[/code]
Thanks for reporting this. Does it happen all the time, or is it a bit random?
We used to enforce that you could only modify the frame range of a Suspended job, and I’m wondering if we should go back to that. At the very least though, it shouldn’t corrupt the job.
We’ve logged this as a bug.
Cheers,
Unable to reproduce here.
It was a fast rendering Nuke Job.
By the way, setting the nuke plugin to 10 frames per task as default is probably a better default since the Nuke EXE evidently has to be restarted between tasks. 30s startup + 30s render task is not very efficient.
We can definitely default it to 10. Note that if you enable Batch Mode when submitting the job, Nuke will stay running between tasks.
Cheers,
Is there any reason not to run it in Batch Mode?
No reason not to. We like to make it optional though for two reasons:
- It’s brand new, so if there is a bug in batch mode, you can simply disable it. We will probably enable it by default once it has been put through its paces during the beta.
- For debugging rendering problems, it’s nice to have the option to try a command line render to make sure Deadline isn’t doing something different in batch mode.
Cheers,