OpenMovie()/CloseMovie() memory leak?

I've just cracked playing a movie onto a textured cube (based on someone else's code of course) but I've noticed that AvailVidMem() returns a progressively lower figure each time the movie is restarted (in order to loop).

I thought CloseMovie(), then OpenMovie() would cure this but it didn't.

Check out the example with your own avi or mpg (gifs work fine with no memory loss).
I can't see any way around this since there is no movie equivalent of FreeEntity() .

The danger is that if a movie is left to run (say, simulating a TV screen) then eventually the user's system will lock up.

Graphics3D 800,600,32,2
SetBuffer BackBuffer()

font=LoadFont("arial",20) : SetFont font
camera=CreateCamera() : light=CreateLight()
cube = CreateCube() : MoveEntity cube,0,0,3 : ScaleEntity cube,1,0.5,1
movietex = CreateTexture(256,128) : EntityTexture cube,movietex
movie$ = "sample.avi" : hmovie = OpenMovie(movie$) ; any AVI or MPG
framePeriod = 1000/30 : frametimer = CreateTimer(framePeriod)

While Not KeyHit(1)
	WaitTimer frametimer
	If t>5
		t=0
		If Not MoviePlaying(hmovie)
			CloseMovie(hmovie)
			hmovie = OpenMovie(movie$)
			frame = 0
		Else
			SetBuffer	TextureBuffer(movietex)
			DrawMovie(hmovie)
			frame = frame + 1 : Color 255,255,255	:	Text 0,0,"Frame "+frame
			SetBuffer BackBuffer()
		EndIf
	EndIf
	t=t+1
	TurnEntity cube,0,.4,0
	UpdateWorld() : RenderWorld()
	Text 0,0,"AvailVidMem() "+AvailVidMem()
	Flip()
Wend
End

doubt this will make any difference to the memory issue, but you might wanna replace DrawMovie(hmovie) with DrawMovie hmovie,0,0,256,128 when testing that code.

maybe they have a system in place for flushing the oldest data from memory when you have used up all the available buffer and try to load a new movie, dunno. Deffinatly doesn't seem to flush it immediatly on close tho.

Thanks Rroff, I already do DrawMovie hmovie,0,0,256,128 etc in my main code.

It might be that only Blitz Support can answer his one.

Hell, Blitz Support? Any ideas?

heh

I was testing it and getting a black cube with the frame counter on it and was like "eh?"

I played with a bunch of stuff but I can't see any way myself to clear the memory without having access to the blitz code itself, tho I thought of several possible work arounds, but they aren't 2 second coding jobs.

I think it's time to bounce this over to the bugs forum.

Since we are taking about Movies, I hope Mark will also add exact Frame Access and Pause / seek, cause I tried to use MCIsendstring as a replacement, but MCI is definitively driving me crazy. Everything works nicely - sometimes, depending on the color of my neighbours socks and the weather.

John,

I had this same problem a while back - did not find a solution I'm afraid.

Can also confirm your suspicions are true - the system did die a death after a (substantial) amount of continuous play.
The program in question was used at an exhibition, 3 days of 9 hours each - the memory would run out around lunchtime each day, so I restarted the app. about every three hours to be safe.
After the show tracked the leak down to the movie section - had a menu system where a random movie was called in as a background to the options screen.

Sorry to be no help - but can at least confirm your findings.

Funky Frank

Thanks Frank. At least it's good you've confirmed this. As I say, I've bounced this over to the bugs forum.

jfk, I've also used MCIsendstring quite extensively, but not with Blitz3D. I'm puzzled how you could do this. Any chance of sharing?

It's in the code archives.
The sucker simply refuses to actually go to a frame when I tell it to SEEK and Update etc :) - well sometimes. and sometimes not...

(Note: you can only access the frames (eg using copyrect) when you are in fullscreen mode, on the frontbuffer)

"The sucker simply refuses to actually go to a frame"
Yeah that sounds like MCIsendstring!

Oh god, we really need an update to the movie and sound systems in Blitz.

Mark????