I get things like this all the time. Try:

-opening the nuke script that studio generates and see if it opens.

-don't try and write h264 from Nuke/Studio. It often fails (badly) with hung 
processes or 1kb files.



On 22 Feb 2016, at 5:44 pm, Ryan O'Phelan 
<[email protected]<mailto:[email protected]>> wrote:


CAUTION EXTERNAL EMAIL






Hi guys,
I'm using NS 9.0v8 on Windows 7.
I'm rendering an h264 (multipass) half-size edit right now. It's simply an h264 
previs chopped up in to 20 shots, with audio. It's about 90 seconds long. There 
are some burn-ins, and one text node with a very simple expression [expr [value 
frame]-240].

Strangely, when I render, the mouse blinks with an hour glass, and it's taking 
much much longer to render than any other render that I've done in the past.

Any tips?

Thanks,
Ryan

On Tue, Jan 5, 2016 at 11:30 AM, Henrik Cednert 
<[email protected]<mailto:[email protected]>> wrote:
Aaah. Personally I don't use comp containers. I never fancied that workflow and 
had performance issues with it when it came out. Still using the Hiero workflow 
here.

--
Henrik Cednert
cto | td | compositor

Filmlance International
Cell +46 (0)704 71 89 54
www.filmlance.se<http://www.filmlance.se>

On 04 Jan 2016, at 19:07, Ned Wilson 
<[email protected]<mailto:[email protected]>> wrote:

Henrik,

I’ve found that having comp containers in a timeline, especially a lot of them, 
like, more than 50, produces disastrous results. My workaround was to disable 
the comp container track, and to create a new track above it that just contains 
the rendered frames.

I have gone back and forth with Foundry support on this since the Nuke Studio 
beta in 2014. It has been pretty frustrating with a lot of ‘we can’t duplicate 
this on our end’ and ‘send us footage that we can test with’. Disabling 
thumbnails is a decent work-around (thanks, Deke) and I think that combined 
with mine, it should ease your performance issues somewhat.

-n

On Dec 18, 2015, at 1:42 PM, Henrik Cednert 
<[email protected]<mailto:[email protected]>> wrote:

What Deke said! =)

I did use those env var’s when troubleshooting this when we used Hiero, like 
two years back. Didn’t solve all my problems though, but it might have been a 
multilayered issue and that the thumbs only was one part of it. Will try those 
again after christmas and see how it goes.

What puzzles me is how not every single programmer can be assigned to fix these 
fundamental flaws that’s been in the app from day one. And that time instead is 
spent on implementing new stuffs (…that eventually will be abandoned in a half 
working state).

Sorry if I sound pessimistic in this thread. Guess it’s more a huge sadness 
then anything else. I know what nS  could be and the potential that’s there. I 
just don’t understand why it’s not taken to those heights. =( If they don’t fix 
this and the other fundamental flaws in nX/nS10 i’d say it’s pretty much over. 
At least for me. Not that they or any one else cares, but still…

Cheers

--
Henrik Cednert
cto | td | compositor

Filmlance International
www.filmlance.se<http://www.filmlance.se/>

On 18 dec 2015, at 21:04, Deke Kincaid 
<[email protected]<mailto:[email protected]>> wrote:

Another thing you can do to speed things up is disable thumbnail generation.  
They are god awfully slow, especially on quicktimes.  Also for whatever reason 
I think it still runs in the main thread so they have to all generate for all 
your bins before you can do anything.  The caching of the thumbnails is really 
poor.  Again, maybe bad memory but I it feels like it either regenerates them 
every time you open a session(whether they or cached or not) or for some reason 
it has to stat every single file in the main thread which takes equally as long.

HIERO_DISABLE_THUMBNAILS
HIERO_DISABLE_THUMBNAILS_CACHE

Working on a long project in Hiero makes me beat my head against the table.  I 
wish Resolve was scriptable.  The NS timeline is fairly easy to automate but 
really slow to use and really horrible with quicktimes or you have Resolve 
which is super fast and it actually supports modern file formats but is 
completely manual.  Both of them have horrible color management tools as you 
have to resort to the nodegraph in both to do any real color work.  I wish 
there was something in between.


On Thu, Dec 17, 2015 at 1:10 AM, Igor Majdandzic 
<[email protected]<mailto:[email protected]>> wrote:
This reflects pretty much my experience so far. Thanks for this conscience 
rundown.


Am 16.12.2015 um 08:23 schrieb Henrik Cednert:
Yes. We use it, or rather try to use it, for long form and 45-60 min 
episodicals. The quicker you accept that it's not usable for this the better of 
you are. Sadly. They say that nS10 will improve this enormously but today it's 
a disaster. It's been like this for day one and I and others have loudly 
complained but without luck so far. Please send your experience to support so 
they can log it and so that these issues are up voted.

Some people have resorted to work in reels instead of whole timelines. That's 
not something I'll ever do though. Wouldn't fit my working style and would only 
mean. I would have 4 projects open at the same time, which wouldn't help.

A few of my "workarounds":
* only conform the VFX shots. Never conform the whole timeline. If needed for 
review, conform a few shots before and after VFX.

* never copy all cuts to the reference media. We export reference into our 
comps but we only slice up the parts where there's VFX shots. NS chokes with 
many cuts/items. Also play with different formats of your reference. Noticed 
that codec of your reference and also the codec of the audio in it can affect 
performance a lot. Not sure what's the best though. If you find out, let me 
know. =)

* save a lot because it crashes a lot.

* also, even though it can take a good 10 minutes to restart it... Do it 
regularly since a restart of it normally tends to give you 30-40 mins of less 
lockups, until it have leaked and filled your memory again.

* if there's something like 'Sudu purge' or other memory purge solution for 
Windows, try that. Monitor your memory and see how it's used. Even with 128 GB 
RAM it will eventually come to a halt but it'll give you a few more minutes at 
least.

Also, have a few spare keyboards handy. Have out of frustration hulk smashed a 
few myself. The marketing of nS doesn't really reflect the reality of it atm. =/


Cheers

--
Henrik Cednert
cto | td | compositor

Filmlance International
Cell +46 (0)704 71 89 54
www.filmlance.se<http://www.filmlance.se/>

On 15 Dec 2015, at 18:45, Charles Bedwell 
<<mailto:[email protected]>[email protected]<mailto:[email protected]>>
 wrote:

Is anyone out there having terrible performance issues with Nuke Studio when in 
the timeline?

I have done a conform on a show roughly 90 minutes in length and am going 
through shots preparing notes, making comps, tagging, setting reference media 
etc and every 1-2 minutes I'm getting about a 30 second lockup. Just now after 
I had left the workstation untouched for an hour I selected a shot and added a 
note and it locked up for a minute while I was typing it out.

I've noticed creating a comp from a clip can take an extended period of time 
(many minutes) while a single core on the PC is at 100% with the other 23 
sitting idle.

Is there anyone successfully using Nuke Studio for long form? I had engineers 
from the Foundry visit a while ago looking at lookups when creating comps but I 
never heard back from them. Disabling shot thumbnails hasn't made any 
difference. There is no way anyone can work like this for any length of time!

Charlie




This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.
_______________________________________________
Nuke-users mailing list
[email protected]<mailto:[email protected]>,
 http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users



_______________________________________________
Nuke-users mailing list
[email protected]<mailto:[email protected]>,
 http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users


_______________________________________________
Nuke-users mailing list
[email protected]<mailto:[email protected]>,
 http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

_______________________________________________
Nuke-users mailing list
[email protected]<mailto:[email protected]>,
 http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

_______________________________________________
Nuke-users mailing list
[email protected]<mailto:[email protected]>,
 http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

_______________________________________________
Nuke-users mailing list
[email protected]<mailto:[email protected]>,
 http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

_______________________________________________
Nuke-users mailing list
[email protected]<mailto:[email protected]>,
 http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users


DO NOT open attachments or click on links from unknown senders or unexpected 
emails






_______________________________________________
Nuke-users mailing list
[email protected]<mailto:[email protected]>,
 http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Reply via email to