Why would a job thats set to enforce sequential rendering start at the end?
Which beta version are you guys on? I can’t reproduce this with beta 6.
Also, does this happen for every job with Sequential Rendering enabled?
it was 6.1.0.52622
It doesnt happen for every job, it actually only happened on this one. Its weird though, cause i never seen behavior like that before,… normally it renders sequentially even without that setting.
But this was a sim job, so i just implemented that setting to be turned on for it, then submitted about 20 test files, and one of them started with the last frame, then did the rest in proper order.
Was maybe the last task added first to the database, and the slave picked it up when there was no other task added yet?
That shouldn’t be possible. We have a flag in the job called IsSubmitted. This is only set to True after the following has happened:
- The job has been created in the database
- The tasks have been created in the database
- The job’s auxiliary files (if any) have been copied to the repository
Since that shouldn’t be the cause, I did some digging, and I think I found the problem. For sequential jobs, we keep track of the previous task to make sure we grab the next task in order. However, we weren’t checking if the previous task was from a different job. So I ran 2 sequential jobs in a row on the same slave, and I was able to reproduce this! The fix was simply to check if the previous task was from a different job, and if it was, start the task ID counter at 0.
So this will be fixed in beta 7.
Thanks!
- Ryan
Cool! I couldnt find anything in the slave log that would give any indication of what went wrong, but if it helps the previous task the slave worked on was from another job, frames 1021-1024 (a nuke job). Then it picked up frame 1020 of this job
cheers,
laszlo
Had another case of this. It seems to happen if i submit multiple sequential jobs at the same time.
The first picked up the frame 1018 (task 3), the other 3 picked up the first task (task 0) properly.
The slave that picked up frame 1018 was rendering another job’s frame 1016 before that:
2013-10-03 11:13:32: 0: Plugin rendering frame(s): 1013-1016
Which was task 3 of that job.
Ah, yup, it doesn’t actually matter if the previous job was sequential or not, so it falls under the same case as above, and will be fixed in beta 7.