beta 18
win7 x64

I don’t know if this is similar to the status bug posted earlier, but the progress bar on jobs goes stays at 0% until the job is complete, then pops to 100%, then blue (complete).

-ctj

Do these jobs have multiple tasks or just a single task? This is currently normal behavior for single task jobs. I can’t reproduce with multi-task jobs though. If it is happening with mulit-task jobs for you, maybe try updating to beta 19 to see if the problem persists.

Thanks!

• Ryan

beta 19 fixed it. Thx!

I’m seeing the ‘Task Progress’ not always updating correctly in RC1.

I was just watching a 248 frame nuke job – there was only 1 task left in the ‘Tasks’ list, but the ‘Task Progress’ progress bar in the main job list was only listing 167/248, it had been stuck on that for 3 mins or so. Changing tabs/jobs etc. didn’t force an update (though in the past a full restart of Monitor has, I didn’t try that in this case).

Only when the last task finished did it jump to 100%. I’ll check out some other jobs tomorrow and see if it is on all jobs, or just the one I happened to be staring at.

cheers,
grant

Strange. The next time you see this happen, can you try restarting the Monitor right away to see if that updates the count properly? If it does update properly, that means it’s a display bug in the Monitor. If it doesn’t, that means it’s a bug when updating the job’s state in the database.

We’ve tried reproducing this here, and we’re not having any luck, and since it sounds like a random thing for you, it will be a bit difficult to track down the cause. However, knowing if the bug is a display thing or a database thing will be a good start.

Thanks!

• Ryan

We have the same issue.

On older builds, jobs would get stuck in ‘queued’ or ‘rendering’ states forever after having the monitor open for a while, independent of whether they have finished in the meantime or not.

With the latest builds, they seem to get marked complete on the last task completion, however during the time that they are rendering, they usually reflect a different state from what the job actually is at (like Grant had it), so it might say 10% done, while its already 90% done.

A monitor restart fixes the issues.

I think we’ve figured this problem out. We were properly updating the job’s task counts in the database, but we made the mistake of only updating the job’s last write time when the job changed states. So the Monitor would only be updated when the job initially started rendering, or when it was marked as complete, but often not between those points.

This explains the behavior you guys are seeing, and also explains why a Monitor restart fixes the problem.

This fix will be included in RC2.

Cheers,

• Ryan