Command Line Render Hangs (stat U+) On Mac

[user_deleted]

i do a lot of scripted (cshell) making of quicktimes using command-line shake. recently i've been going through our stock library making reference quicktimes.

it used to be that occasionally shake would hang-crash - just sit there saying it was rendering a frame. this would persist indefinitely (i tested it by letting it sit overnight). a status check shows something like this (this is an actual ps capture):

[g5node01:~] admin% ps
PID TT STAT TIME COMMAND
374 p1 Ss 0:00.02 -csh
378 p1 S+ 0:00.04 tcsh ./stock_elements_log
394 p1 U+ 3:09.53 /Applications/Shake3.50/shake.app/Contents/MacOS/shake -exec //Network/Servers/vault4//shake_scripts//fireworks_01.shk -t
404 std Ss 0:00.04 -csh

the window running the script just looks like this:

info: frame 150 rendered in 2.95s
info: rendering frame 151
info: frame 151 rendered in 2.91s
info: rendering frame 152
info: frame 152 rendered in 3.07s
info: rendering frame 153

indefinitely stuck on frame 153.

this situation is permanent. killing the process doesn't work. shake never gets unhooked. the only solution so far has been to reboot the machine.

unfortunately this is now happening very regularly - in fact, it's gotten so bad i often can't get through a shot without attempting it a few times. needless to say this is ridiculous.

this only happens with a command line render. never using the gui. and it only seems to happen with large files (10bit hd-rez or 10bit 2k cineons). anything 8bit so far hasn't been a problem and standard def rez files breeze through no matter how long the shot is. this leads me to believe it's something to do with how long it takes each frame to process - the amount of data per frame.

however, i've been unable to find anything out about this. even web documentation about the "U+" stat is very scant, with the one main conversation i uncovered basically coming to the same conclusion - reboot.

a co-worker suggested it's the result of recent os updates by apple. he believes his mac has been sluggish for no apparent reason at times - and definitely moreso in the past few months.

anyone else run into this? i've got four g5s in my render farm all doing this. any help is appreciated!

-christopher

[joojaa]

size leads me to supect memory! Try doinga full memory scan to trest if some of the bits are damaged (NOTE a quick scan will noet do butrather a abit by bit write scan), unfortunately i dont knwo any good menscanners for mac... But there must be some.

Just a tought, sometimes it takes 1 bit to be damaged for the computer to behawe veryy wierdly. (and its far more common than poeple thing with about all sold chips 2% being damaged on purchase, but nevver noticed)

[user_deleted]

i understand your point about memory, but i don't feel that's the case here. it's very random. and that really wouldn't explain why this never happens using the gui - only with the command line.

we just upgraded all the computers to gig-e and rerouted through another switch. then thing were back to normal. i created a number of quicktimes without a problem, then just today once again had one crash again.

this is a very bizarre and frustrating problem - but if im back to just having it happen every 10 renders or so, that at least i can live with.

one of the shots giving me a problem i wasn't ever able to render via the command line script - but it worked the first time via the gui. i've never had one that was unable to rendered at all. usually just re-running the job did the trick, or re-running it again.

i had thought it might be a network glitch, especially since we were pulling 10bit 2k frames over a 100mb line, but i tested one machine with gig-e and it also crashed, and now this most recent crash as well. so it's not simply the network speed, though of course there could be switch issues or just network hiccups.

ah well, i'll keep looking...

[user_deleted]

I am having the same issue (targas to cineons). I don't think it is memory relatated as I am running a dual G5 with 8 gigs (tested and passed) of ram and have had this problem with both network rendering and rendering to local drives.

I also seem to get the problem more when I am using the multiLayer node.

When shake hangs up it also leaves a process that is un-quitable and blocks off a chunk of memory.

As far as Apple upgrades goes, I am running 10.3.9 as our network fails miserably with 10.4. So with no Apple upgrades, same issues.

My only solution thus far is to render my source images into SGI's and then exprot the QT's. It sucks and is both time and drivespace consuming but it seems to work.

Any different solutions found?

[user_deleted]

Corrupted image or video file ?

[user_deleted]

Nope, totally random. It might render 100 frames or 10000.

[user_deleted]

well s-macd, sorry to hear you're having the same problem, but im glad to hear im not the only one! the problem went back to being very occasional again for me, so i wasn't as incentivised to find a cure.

just happened again yesterday on a 989 frame shot. crashed around 450. switched to another comp and it finished just fine. that's the second time it's happen in the last week or so.

there are only two factors i seem to notice with this:

1) it only happens with large files. 98% of the time this happens it's been with 2k cineons. i think it happened once with some hd files (which i only remember because it destroyed my "only with 2k cineons" theory), but i've never seen it with smaller files.

if the problem is file size related it might not be either or, just much rarer with smaller sizes and thus not encountered as often. also, i primarily work with 2k cineons, so i haven't tested smaller sized files as much.

2) it only happens thru a command line render. i've never had this happen when rendering via the gui (shake viewer).

i use five mostly identically configured dual-core g5s. four are used remotely as part of a render-farm and one is one of my desktop units. i used to get weird stall-outs every now and again with qmaster which i now believe is the result of this problem (one machine would stop causing the render to be incomplete).

i use shell scripts to create quicktimes via the g5s since qmaster can't do quicktimes. i run qmaster when simply processing individual frames to individual frames.

s-macd, have you tried rendering via the gui to see if that solves the problem? since you seem to be able to recreate it more consistently than i.

[joojaa]

aah yes the magic word is there Qmaster yes its been reported repeatedly that qmater dont play nball with shake all that well. Your definetly not teh firts one to notice this and thsi is not the first thread.

Skip qmaster and see what gives!

[user_deleted]

joojaa, you really are a magic bullet proponent aren't you?

it's not a memory error and it's not qmaster. notice the thread subject? it says "command line" for a reason.

and in contrast to these repeated reports (which i don't necessarily dispute), i've not had any problems with qmaster. it's got a v-e-r-y clunky interface, but has performed as it should consistently for me.

[deke-kincaid]

there is a really simple answer for this. If you are having all these problems for the last 5 months you should be talking to Shake support. Who goes on for 5 months with an issue like this without talking to support?

[user_deleted]

riiiiight...

[user_deleted]

man - this problem is serious when trying to process 4096x4096 frames. sheesh! can't get more than about 20 frames through a shot.

[deke-kincaid]

stop bitching about crap you haven't payed for.

[user_deleted]

wow. you're an ass. someone get up on the wrong side of the bed?

two things:

1) don't talk when you don't know crap about what you're saying. i work for a vfx post-production house and i can assure you these are licenced copies of shake. i just haven't had good experiences with apple help in general and especially with regards to shake - a product they simply bought and had yet to fully integrate, at least at version 3.5, which is what we're running.

2) if you're going to try and insult someone, at least learn how to spell before you do. the word is paid.

[user_deleted]

Right, and I guess by licenced you mean licensed, don't you?

Please note I'm being ironic with the sentence above (I make mistakes aaaall the time, so what?).
I mean, really, I never got the point on these kind of posts in this forum. And then people will still wonder why it got so abandoned...

[user_deleted]

ha, i wondered if someone would point that out. but no, i use licence because my parents are british and i lived there for two years as an adolescent, so i still sometimes use the old country way of spelling and pronouncing certain words.

you are correct about the siliness of these kinds of posts tho.

[deke-kincaid]

The definicion of moroonic. Somehone who purchassesss a software packeage and has a show stopping probleem for sixx monthsss and bitchees aboot it on a messessge board and can't call support.

[user_deleted]

stop bitching about crap you haven't payed for?

1. I kind of figured shelling out nearly $10000 canadian for TWO seats of shake would give me a right to bitch.
2. Last time I checked I was not bitching about it, I was trying to see if anyone else might have some CONSTRUCTIVE feed back.

Guess I was wrong. All I found was a couple of people who were having the same problem and ONE putz who has taken it upon himself to be that loud mouth at a party whom no one can figure out who invited..

Oh and by the way I'm still having the problem.

[user_deleted]

I seem to have discovered a strange solution / work around that works 50% of the time.

After the render hangs up, open another shell while leaving the hung one open. In the new shell launch the same script from 20 or so frames prior to the hang up and voila the hung shell starts rendering again with the render time at some ungodly number like 15478.33s.

It works with image sequences as the output just about all the time and with quicktimes sometimes.

Can't explain it but it works.

[user_deleted]

fascinating! that is bizarre - pity that won't work for my qmaster renders. but i'll definitely give that a try the next time a script freezes.

so how did you figure that one out?

and once the original script starts running again, can you kill the new one? doesn't the new script render over the frames you already outputted? won't that leave you with partial rendered-over frames?