We have a job that shows as pending, even though all its tasks are completed.
Restarting monitor does not help, and the job shows in this pending state on every machine.
Yeah, it looks like it’s the same problem.
Attached are the job archives for a job thats doing that
This looks sort of odd:
“QueuedChunks” : 22,
“RenderingChunks” : 0,
“Stat” : 1,
SuspendedChunks" : -22
The job is actually complete… Shows 100% done (40/40) queued
job.zip (8.56 KB)
Thanks! This should be helpful.
Cheers,
- Ryan
Hey Lazslo,
Can you post the Job History for that Job? I was able to reproduce those chunk counts with a very specific flow (fix should be in the next beta), and want to confirm whether or not it’s the same bug you’re seeing here. I’m mostly looking for whether or not that Job had been archived/re-imported at some point, which currently causes issues with task counts (note that re-importing won’t show up in Job history, only the initial archiving).
I dont think it was archived, as we cant currently archive properly due to the file names being just simple user firstnames. But ill double check.
The history:
2013/12/03 13:14:58 derek.blume LAPRO1043 (LAPRO1043\ScanlineVfx_user): Suspended Job
2013/12/03 13:15:11 derek.blume LAPRO1043 (LAPRO1043\ScanlineVfx_user): Suspended Job
2013/12/03 14:51:43 derek.blume LAPRO1043 (LAPRO1043\ScanlineVfx_user): Exploring Output Directory ‘\inferno2\projects\burn\scenes\SHR_shr_rsrc\images\render3d\Bridge-TurnTable\v0010_dbl_addTrees02\Filmlook_alexasc_rlin’
2013/12/03 14:52:29 derek.blume LAPRO1043 (LAPRO1043\ScanlineVfx_user): Requeued job
2013/12/03 15:55:27 jon.bird LAPRO2056 (LAPRO2056\ScanlineVfx_user): Priority modified to: ‘55’
Machine Limit modified to: ‘20’
2013/12/03 19:09:30 jon.bird LAPRO2056 (LAPRO2056\ScanlineVfx_user): Priority modified to: ‘55’
Machine Limit modified to: ‘5’
2013/12/04 02:01:32 jon.bird LAPRO2056 (LAPRO2056\ScanlineVfx_user): Priority modified to: ‘50’
2013/12/04 14:27:00 laszlo.sebo VCPRO1014 (VCPRO1014\ScanlineVfx_user): Viewed History Log
We think we finally nailed this one down. The double “Suspended Job” entries in the history log led us down a path where we discovered that both calls would be operating on the same instance of the task collection object and could cause the task state counts to get messed up. After we fixed this, we couldn’t reproduce the problem anymore. This fix will be included in beta 13, so hopefully that solves this problem once and for all.
This would be great! 
(sidenote: i think the reason for the suspend doubletap is that sometimes it takes a very long time for all the tasks to actually suspend. So they click, and it might take a 2-3 minutes for all tasks to get suspended. Some artists are impatient and think that cranking the handle makes it faster)