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 > On 18 dec 2015, at 21:04, Deke Kincaid <dekekinc...@gmail.com> 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 <subscripti...@badgerfx.com > <mailto:subscripti...@badgerfx.com>> 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:charles.bedw...@encorepost.com>charles.bedw...@encorepost.com >> <mailto:charles.bedw...@encorepost.com>> 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 >>> Nuke-users@support.thefoundry.co.uk >>> <mailto:Nuke-users@support.thefoundry.co.uk>, >>> http://forums.thefoundry.co.uk/ <http://forums.thefoundry.co.uk/> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk >> <mailto:Nuke-users@support.thefoundry.co.uk>, >> http://forums.thefoundry.co.uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk > <mailto:Nuke-users@support.thefoundry.co.uk>, http://forums.thefoundry.co.uk/ > <http://forums.thefoundry.co.uk/> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
