[Solved] roTextureRequestEvent getBitmap() fails

Hey All,

Im using roTextureManager to download some images, but when I do msg.GetBitmap(), the console freezes and Roku restarts. Or, some times, it succeeds, and returns a bitmap with 0 width and height. Has anybody encountered this problem, with roTextureManager before?

Thanks

if the pic is bigger than 2048 in any direction and you are not requesting a size less than or equal to that it will fail. Otherwise sounds like you could be out of memory.

My images are around 300X500

and the memory usage is:

Available memory 56921472 used 13078528 max 70000000

“sonnykr” wrote:
My images are around 300X500

and the memory usage is:

Available memory 56921472 used 13078528 max 70000000

OK but thats the amount before it gets to the crashing point. Roku3 yes?
Does it crash on the same image?
Different image but always #X in the list?

Can you share the code that’s causing this? Are you verifying that roTextureRequestEvent.GetState() indicates the bitmap is ready (3)?

In my experience with my grids which constantly request, cancel or unload textures in response to the user scrolling I have found that a return code of 3 does not always guarantee a valid bitmap handle. I always wondered why the example checks the validity of the bitmap after a return code of 3 - now I know. Does it eventually return valid. Yes so far it has. why there is such an infrequent anomalie I can only speculate as it pertains to my use of the texture manager. However I do not resend them as they do come in valid eventually.

“TheEndless” wrote:
Can you share the code that’s causing this? Are you verifying that roTextureRequestEvent.GetState() indicates the bitmap is ready (3)?

My Code looks some thing like this:

if (msg <> invalid and type(msg) = "roTextureRequestEvent")
            
		' read the response received
		state   = msg.GetState()
		id      = msg.GetId()
		uri     = msg.GetURI()
		
		' check if the image was downloaded successfully
		if (state = 3)
			DebugLog("AsyncTextureManager", "Image downloaded successfully. URL : " + uri)
			if (type(msg.GetBitmap()) = "roBitmap" or type(msg.GetBitmap()) = "bitmap")
				receivedBitmap = msg.GetBitmap()
				' execute the successCallback
				successCallback(receivedBitmap, context)				
		   else			
				DebugLog("AsyncTextureManager", "Bitmap download Failed")			
		   end if				
		end if              
end if

and

receivedBitmap = msg.GetBitmap()

is where it breaks.

Interesting.. you’re calling GetBitmap() three times in that code, and it doesn’t blow up until the last one. I wouldn’t expect it to, but have you tried only calling it once to see if it helps?

         receivedBitmap = msg.GetBitmap()
         if (type(receivedBitmap) = "roBitmap" or type(receivedBitmap) = "bitmap")
            ' execute the successCallback
            successCallback(receivedBitmap, context)            
         else         
            DebugLog("AsyncTextureManager", "Bitmap download Failed")         
         end if  

That was it! That solved the issue. Thank you TheEndless :slightly_smiling_face:

“sonnykr” wrote:
That was it! That solved the issue. Thank you TheEndless :slightly_smiling_face:
I’m glad that worked, but I can’t think of any legitimate reason that it should have. Makes no sense that multiple calls to roTextureRequestEvent.GetBitmap() would cause a catastrophic failure like that. It must be doing something more behind the scenes than just returning the bitmap.

That’s true, I never expected calling GetBitmap() multiple times would cause a crash. May be this should be added to the documentation. Especially since it causes Roku to restart.

“sonnykr” wrote:
That’s true, I never expected calling GetBitmap() multiple times would cause a crash. May be this should be added to the documentation. Especially since it causes Roku to restart.

Issue confirmed. Thanks for the bug report.

“RokuKC” wrote:

“sonnykr” wrote:
That’s true, I never expected calling GetBitmap() multiple times would cause a crash. May be this should be added to the documentation. Especially since it causes Roku to restart.

Issue confirmed. Thanks for the bug report.

Oh cool. Thanks RokuKC!

“TheEndless” wrote:
Interesting.. you’re calling GetBitmap() three times in that code, and it doesn’t blow up until the last one. I wouldn’t expect it to …
In practice it was getting called only 2x - because of the short-circuiting of the OR - so it was bombing on the 2nd call to getBitmap(). It would be disconcerting if it was err-ing on the 3rd call but now is just a regular bug, phew :sunglasses:

Also, i don’t think there is type()=“bitmap” ever, is there? I trust when getBitmap() <> invalid, it’s always roBitmap.