Thread: Nuke 4.7 Stability (or lack thereof...)

Ok, I may be all alone on this one (though I don't know how that could possibly be...) but has anyone else noticed the major downturn in Nuke's stability between 4.6 and 4.7? It's unbelieveable... and predictable. I can be working with any op, any comp, any input format(s), any level of complexity, and it will randomly crash and burn 7 or 8 times an hour like clockwork.

Sometimes it's when I scrub the timeline or zoom in on a viewer. Sometimes it's when I start to increment a value. Sometimes it's when I connect a pipe. Sometimes it's when I adjust a curve. Sometimes it's when I get up to go make a sandwich. But it's like the tide... freakin' inevitable.

The only thing keeping me from junking it until 4.7v2 (or whatever the next release is) is the fact that it autosaves so often that I rarely lose more than a couple digit entries or maybe a node creation. That, and I actually like it despite all this. Luckily, Fusion is still my app of choice, so I'm not dead in the water or anything.

And an interesting bit of poetic justice for anyone who has ever complained about Fusion's stability: It's only crashed on me twice in 2 years of use. Seriously. I notched my belt.


Anyhoo, just wondering if anyone else is even near my boat on this one.

Originally Posted by alkali

Anyhoo, just wondering if anyone else is even near my boat on this one.

I have noticed some instability (although not so drastic as you describe). I think it's related to the graphic card mainly. I say that because I got crashes mainly related to viewport manipulation (dragging, bezier editing). I have a GeForce 8800 and they are not famous for their reliable drivers . What card do you use?


Dragos

I use an old 256 MB Radeon X600 with Catalyst 7.2 drivers, and it's been flawless for everything I've ever done on this machine, both 2D and 3D. I don't think the actual Nuke UI really uses any sort of hardware-based graphics API though, so I don't see how that could be causing problems (it hasn't crashed in the OpenGL viewer... yet). Not only that, but the crashes come from such a mixed bag of situations that I can't, in good conscience, blame it on my system.

Nevertheless, thanks for the suggestion

I'm not doubting the problems your having but you know from the people I talk with it almost seems like some of these problems are windows only. I've had a few people send me 4.7 scripts that they say barf when you do a certain operation in a script and under Linux I just can't reproduce the errors, I'll spend a good 5-10 minutes trying to recreate the problem they say happens and I just can't do it. Granted this sure don't help you none but it is just something I have no explanation for.

Diogo Girondi and me were talking just yesterday about how he is having the grain node give him invalid channel errors with scripts. He said if you changed the parameter in a node above a grain that every so often an error would occur. The basic error text that Nuke displays is roughly the same as if you told a node to use the depth channel for a mask when the incoming image doesn't have a depth channel to begin with. He sent me his script and I spent a good 10 minutes changing every knob for every node above the grain and couldn't get it to happen like he could. He also said you could reproduce this error by disabling a knob above the grain node, this also I could not reproduce myself in the 10 or so minutes i spent going to town on his script.

I don't know what to say other then "Ha ha you use Windows". Nah I only kid, if anyone else is also having issues and can easily reproduce these problems it would be nice to see if they could post example scripts to see who else can reproduce the error. Most of the problems I've seen I kinda get what is going wrong from the error message but I'm kinda curious as to why certain bugs happen for some users and not others.

Incidentally, I actually use Linux for a number of things as well, but I don't have a Nuke license for it... Perhaps I should change that.

Anyway, this seems like a good time to bring up the fact that I too occasionally get completely random error messages from nodes (mainly from shuffle and shuffle copy thus far).

For example, I might pipe in several render passes and copy the channels to new layers and channel sets, and then keep going just fine. But then later downstream, I'll get an error at a random point in time that references one of the shuffle ops waaay upstream. The message basically says there's a problem with the way the node was coded, like "error calling something_or.other(). This is probably due to a coding problem with blank-ity-blank." (it almost sounds apologetic) and the shuffle node will throw the big red ERROR sign.

However, if I go back to the shuffle controls and change one of the IO switches (like reassigning a green input to a blue output) and then immediately switch it back to the way it was, everything goes back to normal, and the viewer spits out the render.

Now, this is waaay too random to keep track of, but it has happened at least 10 times this far. Just thought I'd bring it up...

I get what you mean, errors like that almost always are a _validate not called or channel(f). I could be completely wrong but from my work with Nuke and its NDK when you see them errors you get a general sense of what they mean.

Validate is the function for a Nuke node that does certain things as well as calls validate on the inputs of the node if it has any. So a "_validate not called" error basically means a node somewhere has not called a validate for either one of its Iops, itself, or any number of other things. After validate is called Request is then called on the inputs of the node or any internal Iops, nodes, etc.., you can think of this as the part where the node grabs a bounding box and group of channels from the input or internal nodes etc. The next step in the chain is Engine or PixelEngine which does the actual image manipulation for the node. Now this can get more complicated depending on how the node is coded. Here is an example of what NFXPSColor does inside _validate, this is only a small portion.

void NFXPSColorIop::_validate(bool for_real) {
input(0)->validate (for_real);
input(1)->validate (for_real);
PixelIop::_validate(for_real);
}

As you can see 3 validates are called inside NFXPSColor's _validate, if I didn't call validate on one of my inputs then you would see the same validate not called error that you randomly get as you said. Another area that could be the problem is Invalidate isn't operating properly or being called and thus causing issues.

A channel(f) error is basically telling you Request somehow screwed up and didnt request a channel that a node is trying to work on. Now how Request got messed up I do not know, you usually setup the channels your going to be requesting inside Validate so any error on Request means that somewhere it wasn't setup properly.

My point is errors like that are usually some screwup thats happening in the tree, now why its happening I do not know. It could be the node correctly sets up everything but isn't updating with new information after a node upstream changes or its just not setting things up properly to begin with. Sorry for all the mumbo jumbo but I figured I would at least give you a general idea so you could better understand what the errors are saying to you.

No, that's a huge help in terms of understanding what's going on. Thanks a lot.

Now if only the program would run long term...

Sounds like Fusion 5 all over. I guess all I can say is hang in there. Been there before. They will definitely fix it. They'll have to.
cheers.

I hope you're not comparing Fusion's stability to this mess...

But yeah, I suppose they can't exactly go with a twice-yearly releases anymore when the software doesn't run.

I just upgraded to 4.7v1 and I'm also experiencing some problems as nrgy pointed out. But I'm sure they will fix them really soon.

I don't think the actual Nuke UI really uses any sort of hardware-based graphics API though

For what I know it does use and it pretty picky about it. Nuke always had it's issues with ATI boards. I use nVidia Quadro boards and have never experienced any sort of graphics board related problem.

Incidentally, I actually use Linux for a number of things as well, but I don't have a Nuke license for it... Perhaps I should change that.

As far as I know the license is the same you only need the Linux installer

Get in contact with thei support, let them know what you're experiencing

support <at> thefoundry.co.uk

Originally Posted by Diogo Girondi

For what I know it does use and it pretty picky about it. Nuke always had it's issues with ATI boards. I use nVidia Quadro boards and have never experienced any sort of graphics board related problem.

Well, that might be a valid point, except 4.6 runs like a champ on the same computer. Graphics issues more often relate to driver/software conflicts than actual hardware compatability issues anyway, so I'm pretty positive my graphics hardware isn't a problem (unless they completely overhauled the program's graphics API between 4.6 and 4.7).

If the new version doesn't support the same hardware as the old, then that would be a pretty big black mark on The Foundry's common-sense-o-meter. I really doubt they would inadvertantly implement that big of a change.

Nevertheless, thanks for the reply.

For production work none of the Foundry releases are acceptable, 4.6 was really unstable for me. The D2 4.5 builds are very nice.

Yes 4.7v1 is little bit over the edge with stability. Sometimes I just hit Alt-F and get crash. I hope there will be fix soon, because 4.6 was running relatively smoothly. Running on XP.

Originally Posted by Diogo Girondi

For what I know it does use and it pretty picky about it. Nuke always had it's issues with ATI boards. I use nVidia Quadro boards and have never experienced any sort of graphics board related problem.

Ati makes some of the worst opengl drivers out there. Directx great, but opengl I have had nothing but problems with them with all operating systems and all pro opengl apps. 9 out of 10 times people have a problem with maya, it is because they are either using a ati card or not using the proper driver version for an nvidia one.

This release could be described as randomly useful