Backburner stitching problem

[folkevall]

We've got a probelm with our renderfarm at the moment. We do a lot of big renders that require the 'Split-Scanline' options when submitting a network render. We're getting an error when stitching the jobs in the Second Pass.

I can't say for certain when we started having this problem, but we had no such problems on windows 32bit Max 9 (no sp) backburner 2007 latest version.

We're now on Windows Xp 64bit, Max 9 64bit SP2 still with the same version of backburner and we get this error message when attempting to stitch strips. We have also changed our network file server not too long ago.

The error message "Error loading strip_STP00000_0000. " isn't pointing to a specific strip so it's not like there's a permissions or missing file error. The job will eventually get stitched on one machine, but this isn't consistant it all seems to be random/luck to which server will stitch them.

Obviously waiting over an hour for one pass to stitch is causing us problems. I've searched around and found other people have had this problem but haven't found a solution.

I've tried to not have any numbers in at all, not in the filename/'path to file' or in the output, not even in the camera name. Still got the problem.

Sometimes it actually stitches after a few minutes, next time you send off a render from the same file and same settings and same everything it takes 1 hour or more...

And i'm out of ideas now...

Anyone had this problem rectified?

[glorybound]

slice

I finally got backburner to work, but it didn't assemble the 10 slices. did you find a solution? it also failed on the z-depth channel.

[jacksc02]

why not just use DR and forget BB?

[Neilg]

It might be the big to do with how the strips are named - check what strips backburner is looking for then look at the rendered ones, chances are it'll have doubled up the numbers at the end.

You can just edit the filenames and it should find them.


If it's not that i'm not sure, thats the only error we've had with backburner stitching.

[ShaunDon]

I too have noticed this happening a couple times before -- the majority of our images work fine, but on occasion I've seen every machine error out on the second pass until finally one works it out. Could be a naming issue, that would explain why it's random. Wish I could be of help, but I'd really like to know why this happens.

We use a mix of DR and BB strip renderings for stills, but there's still reason to use strip renderings, especially when we're rendering heavy images or a multitude of still overnight. There's nothing worse than coming in the next morning and seeing a rendering has two hours left to go, but the workstations and servers are needed for day work. If you have to suspend a strip job, you only lose the processing done on the active strips vs. losing the entire image on a DR job.

[jacksc02]

dont forget you can queue up DR jobs on backburner now.......

[ShaunDon]

Totally, and we do. Actually I had a night shot we did last week where the rendering was so intense (12 quadcores working together for over 24 hours) that I ended up DRing the image in six strips so the machines wouldn't have to be engaged for the whole time. It was a night shot with lots of lights and VRayScatter field grass around the site -- took a ton of sampling to get the grass to read as wispy with all the different light sources!

[Noise]

How do you queue a DR job with BB ?

[GLASS-CANVAS]

whenever this has happened to me in the past it's been caused by having a strange character in the camera name, like a space at the beginning or tab space somewhere

[tricky]

Old thread I know, but why start another?

We are trying to get strip rendering working as we are having continued issues with DR stability. All the machines render their strips, but when the job completes, I only see one strip. Any ideas?