Auto reopen on crash

[Skulpture]

In fact it just did it now.... lasted about 3hrs25mins (approx).

Again no crash, just pauses and then beach ball.

I have saved the crash file console output (wont let me attach it here as a ZIP for some reason)

[Skulpture]

Attached it.... 01d33d-izzy-crash-gt.rtf

[particlep]

can you run the patch on an older mac with an older operating system at all to check if it's something connected to mac os?

[Skulpture]

I can try that yes. I might give it a go tomorrow.

[particlep]

i found this

http://lists.apple.com/archives/quartzcomposer-dev/2012/Mar/msg00000.html

in it there''s a reference to the opngl driver monitor.  i have no idea what it is, but it seems to monitor something, that might be useful.  i might just have to make a cup of tea, as i don;t think i'm adding too much now.

[Skulpture]

Thanks for your thoughts though @particlep I appriciate it :-)

On a brighter note - my work macbook pro retina just arrived! Woo!

[vanakaru]

Try to ask help from these guys

http://hintsforums.macworld.com

There are some great enthusiasts who also are good reading clues from the console logs.

It may have something to do how many times a loop is allowed to play by the system(or Isadora?). Original size 2 hours 2x the size almost 4 hours?!

[Skulpture]

Thanks will do @vanakaru

[Skulpture]

I have created a post on the macworld forum; but waiting validation, etc.

I have also seen that it's happening on similar software such as max/msp+jitter:

http://cycling74.com/forums/topic.php?id=28251

And processing:

http://processing.org/discourse/alpha/board_Proce55ing_software_bugs_action_display_num_1106328253.html

This is a huge issue, can't understand how or why Apple have done this? 

[nick]

Its an assumption at the moment that those other issues are the same as yours - one is from 7 years ago, so may not be a live issue any more.

Can you post your patch - there might be something unusual in it that you may not have noticed ?

Try running your patch with Activity Monitor running (found in the Utilities folder) to monitor its memory use as it runs  - it may provide a clue.

[mark]

Dear Graham,

OK -- I've looked over the crash report. It seems like there are dozens of movies that are attempting to be loaded in the background. For sure this shouldn't happen, but it could be a result of your randomization routine. What I think might be happening goes like this:

1) Movie 1 is playing

2) You request movie 5 (i.e., send a 5 to the 'movie' input)

3) Background preload of movie 5 starts; movie 1 continues to play

4) Before the background preload of movie 5 completes, you request a different clip -- e.g., movie 6 -- by sending a 6 into the 'movie' input

5) Movie 5 goes off to the nether world, consuming memory and resources

6) Movie 6 plays, movie 1 gets properly "thrown away"

Repeat this process enough, and eventually, you run out of memory.

Is this possible Graham? That the random numbers are coming so rapidly, that the a new movie would be chosen before the old one is preloaded?

One simple test: put a Multi Blocker before the 'movie' input -- set the value to 2 seconds. (I know that may be too long... but just as a test.) If you do this, does the patch run without crashing for a substantially longer time?

Also, you should really try this patch with 1.3.0f26 if you haven't already. I may have addressed some bugs in this area that will get it to run better. But try the test above first if at all possible, so we can zero in on the problem.

Best Wishes,

Mark

[Skulpture]

Hi Mark,

First off all thanks for looking into this, and thanks to everyone else above for chiming in and helping.

The routine you described is not how I've patched i'm afraid; but it still helps me out and has given me an idea of how to improve the patch drastically.

Each movie player has its own projector and when video one is picked; its turns on movie player 1, when video two is picked it turn on video two. I have used to toggle on/off for visibility on each of the movie players but am starting to think this is not the best way to go about it.

After each video isadora jumps to a secondly scene (jump connected to video end) this plays another video and then goes back to the first scene awaiting a new video to be picked.

I will try and attach a screen shot today. I am going to explore this all day today.

I did also update to 1.3.0f26 yesterday and did see a bit of a difference yes.

Again; thanks to everyone.

[Skulpture]

I think i've solved the problems.... re-designed the patch.

[particlep]

yay !

[vanakaru]

I would be very curious what did you do at the first and then after. I had the installation this summer needing computer restart every 3-4 hours. I thought it was the hardware failure but maybe it was not.

I had different movie clips triggered (some times rapidly) by user without any effects - just plain play. And the whole thing just hung after 3-4 hours.

[Skulpture]

@vanakaru I am going to do a full write up about it on my blog I think.

I originally had 6 movie players and 6 projectors. All 6 movie players initialised with videos 1, 2, 3, 4, 5, 6 but all turned off. When a user picked a video it turned on one of the movie players and it started playing.

Now a trigger value sends the number of the video directly into the movie player and it starts. I also upgraded to 1.3.0f26 and changed the movie player to CI and CI Projectors.

If a user does not pick a video for 90 seconds then automatically it jumps to a scene to play a demo video. Every 15 mins it plays a promo video. So its always active and is never inactive for more than 90 seconds. Constantly going.

The system has been going since 8:45 this morning and it is currently 1:50PM in the UK. So its still going strong. I *think* I can still see the RAM being taken up very slowly by this memory leak from Quicktime via the activity window but I doubt it is going to crash my system for another few hours. I am still unsure about this Quicktime thing and as Nick rightly pointed out I was openly presuming this.

So instead of 6 videos being opened in the background, now none are only deployed when triggered; if this makes sense?

In terms of videos being triggered rapidly by your patch Vanakaru; I imagine it relates back to Marks post above;

1. You request movie 5 (i.e., send a 5 to the 'movie' input)
2. Before the background preload of movie 5 completes, you request a different clip -- e.g., movie 6 -- by sending a 6 into the 'movie' input
3. Movie 5 goes off to the nether world, consuming memory and resources

So in theory if you trigger 5 clips in quick fire rapid style, even though a video has not played fully and you are on to the next one, it is still processing in the background threads and 'inner workings' and after a period of time, will slow your machine down. Resulting in a hang up/lock up or crash.

Hope this helps for now.

Graham

[particlep]

@Skulpture

it's good to read that you're getting somewhere with the hang time senario. 

after reading it i drifted off into memories of dvd control in show control mode and a thought occurred to me:- what if you actually only worked with two or even just one video file ?

it would require a radical re think to how you programmed the thing, but in theory if it were to be only one video, you'd simply be locating and playing within one video.

[mark]

Well, let me just add that even if you select 1000 movies per second, Isadora should be smart enough not to crash. I thought I'd handled this problem but I'll revisit it as soon as I can.

Best Wishes,

Mark

[vanakaru]

@Skulpture

Look at the macosxhints forum. There is a possible clue for us to think about:

Looking at the crash log you provided, I see that the IsadoraCore process is not taking up much memory (see "Task Size") so it is unlikely to be an issue with a memory leak. But I see that it is running a huge number of JavaScript threads. I suspect something going astray there. (Again, this is something for the developer to solve, not you)

[Skulpture]

Javascript? Hmmmm.

I've replied anyway with some of my replies/investigations.