"could not create temporary GWorld for open() error" with WindowsXP64

Jun 14, 2010 at 7:00pm

"could not create temporary GWorld for open() error" with WindowsXP64

The title says it all…. well sort of. I’m running a copy of Max 5.1.4 on WindowsXP and am finding that when I allow my patch to run for multiple days I start to see these error messages popping up, “could not create temporary GWorld for open() error” with regards to my jit.qt.movie objects. I also notice that once these begin to appear, my video performance in Jitter starts to suffer, with videos freezing and “catching” when other videos are loading. I will admit fully that I haven’t worked on a windows computer in years, so my personal confidence in finding the appropriate solution isn’t fully there.

My patch runs without issue on mac osx in both tiger and leopard for extended periods of time on machines with far less memory, cpu, harddrive space etc… I really ran into no issues switching to PC, except this one error message.

I’ve never had this type of error before and I’m wondering what causes it and what I can do to make it no longer appear. Anyone have insight? My other computer specs are listed below. I could always run a script that closes max/jitter at night when no one is around, but I’d really rather just be able to have it run without issue.

nico

WindowsXP 64
4 GB of memory
CPU – Intel Xeon CPU W3530
Video Card – Quadro FX 3800

#50892
Jun 14, 2010 at 7:26pm

is your jit.window in the sreen resolution ?

#182569
Jun 14, 2010 at 7:36pm

I’m not sure what you mean, sorry, my jit.window has a resolution of 853 x 480, my monitor currently has a resolution of 1280 x 1024, but this is just a testing monitor. The final display monitor will have a 1360 x 768 res.

#182570
Jun 14, 2010 at 8:14pm

try @pos 0 0 argument…if it’s not the case. Your window has to be in the sreen size.
That can be one cause of the problem

#182571
Jun 14, 2010 at 8:25pm

Thanks, I normally dont throw in the @pos argument until I’m finishing up testing, but I’ve put it in there now and we’ll see what happens.

Still not clear about what you mean when you speak of the “screen size” do you mean the @size argument for the jit.window object? Otherwise, I’m obviously not too bright today, could you explain what you mean a bit further when you was, “your window has to be in the screen size”.

#182572
Jun 14, 2010 at 8:54pm

If your main screen is 1650 x 1080 and you put your window at @pos 2000 1200,
it can’t work.

#182573
Jun 15, 2010 at 4:01pm

Yup, not an issue since my window is @pos 0 -50 for the moment. I’ll see if the @pos argument helps with this error, though it will be a few days before it’ll start to occur (if history is any indication). Thanks for the help and I really hope this solves everything for me!

#182574
Jun 30, 2010 at 7:46am

And James – did this resolve the issue??

I have the same error on os x 10.6.4 and max 5.1.4

I have been doing similar stuff literally for years, and now run into this error – could it have something to do with sending different jit.windows to different dvi outputs in the new version?

Although I have the same problem just running on a macbookpro as on a desktop machine using multiple video cards: after a few hours it not only gives this error, but crashes soon after I try to intervene.

#182575
Jun 30, 2010 at 8:09am

I just made a quick patch which illustrates the problem.
causes crash after about 5 mins.

what to do – what not to do……???

– Pasted Max Patch, click to expand. –
#182576
Jun 30, 2010 at 10:32am

like Joost Rekveld (haha, I know his name from somewhere) also overcame the problem by first rendering to video – and then moving through my sequence by setting time (position) in the movie instead of reading (vast quantities of) images into the jit.qt.movie object one by one…

#182577

You must be logged in to reply to this topic.