Brett Buddin wrote:
> On 2010-06-17 21:49:08 -0400, Greg Ercolano said:
>
>> Yes, this is really annoying, details on that were posted
>> here on the group a few months ago here:
>> http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1906+1906
>>
>> This cropped up because Adobe made a change in CS3 that causes the
>> render process to disconnect itself from the process hierarchy,
>> effectively orphaning the process.
>>
>> Adobe is aware of the problem as of November 2009, and is trying
>> to fix it. I worked directly with the AE devs on that issue.
>>
>> The AE engineers came up with a javascript mod as a temporary
>> workaround to solve the problem; I can try to follow up with
>> those engineers through myself on your behalf; contact me off list.
> Have you received any updates as to when, or if, this might be
> corrected in CS5? It appears that the issue is still around.
No, I haven't. The Javascript mod they offered is the only one
I've seen so far.
> If not, what sort of measures have you implemented to determining that
> renders have actually completed (when you receive false negatives or
> positives from aerender)?
Renders finish OK, the problem only occurs when you try to
stop a render while it's running (eg. requeuing busy frames,
or dumping jobs that have busy frames).
To that, there's really no answer except to 'End' these
jobs instead of 'Dump' them, and not requeue frames that are busy.
There's no technical solution I'm aware of that rush can do;
it really has to be fixed on the Adobe side, due to how the
processes become so completely disconnected that it's fairly
impossible to tell which process is associated with which.
> So far, I've been watching the status
> returned by the aerender process and monitoring the log file it creates
> to determine when the render is complete, but that doesn't seem to be
> completely reliable.
Right, there's no good solution.
The only one I can think of is to somehow use the TCP socket
connections between aerender and AfterFX to determine which
process goes with which, but that's very unreliable too.
The javascript solution Adobe offered sounded like the
right direction to go, where the main program watches
aerender to see if it disappears, and if so, stops the main
application right away.
They said they weren't completely happy with that, and there's
probably a cleaner way to do it, and they were investigating this.
> We're running multiple instances of aerender on a single machine so a
> "killall" against aerendercore, when it hangs, isn't an option.
Right. No clear solutions externally to AE seem possible.
It has to be fixed from within.
--
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|