roTextureManager skipping some images

I had the same problem. There was a time when I would use the roTextureManager to download about 50 images when the channel started. There were often a random handful of images that failed to download for no apparent reason. I received a texture request event with a state of 4 (failed). I'd retry the failed downloads, which were successful the next time around. I don't believe I had any memory issues or networking issues at my end. However, the images were coming from servers 5,000 miles away, so maybe were taking too long and exceeding some timeout value used by roTextureManager.

I ended up writing my own texture manager that used roUrlTransfer, and haven't had any problems with downloading those same images that way.

The HTTP services may be the same as any other net-aware component but storage and memory management is different. The best way to learn the texturemanager is to observe its behavior with telnet and r2d2_bitmaps. I have used it quite extensively over the last year, and the only problems I encountered were mostly related to my misunderstanding of it. It is not well documented. Can't say that I ever have experienced what you describe. Have to wait a few seconds on very rare occasions for that last bitmap to pop in, but it always comes. Resending usually was the the result of a bad url or connection error. But then I have not tried it with a server 5000 miles away or multiple servers in the same batch of requests. There may be timeout issues. I notice that when I use it with roSystemLog there are a number of connection errors that are observed but I still get the bitmap in the end. So far I think its a great component for what I need it for. And I have really put the pedal to the metal as it applies to consistently requesting, cancelling or unloading. Could never have produced the same quality dynamic grids without it.

"NewManLiving" wrote:
The HTTP services may be the same as any other net-aware component but storage and memory management is different. The best way to learn the texturemanager is to observe its behavior with telnet and r2d2_bitmaps. I have used it quite extensively over the last year, and the only problems I encountered were mostly related to my misunderstanding of it. It is not well documented. Can't say that I ever have experienced what you describe. Have to wait a few seconds on very rare occasions for that last bitmap to pop in, but it always comes. Resending usually was the the result of a bad url or connection error. But then I have not tried it with a server 5000 miles away or multiple servers in the same batch of requests. There may be timeout issues. I notice that when I use it with roSystemLog there are a number of connection errors that are observed but I still get the bitmap in the end. So far I think its a great component for what I need it for. And I have really put the pedal to the metal as it applies to consistently requesting, cancelling or unloading. Could never have produced the same quality dynamic grids without it.

I have tried to observe its behaviour through telnet and r2d2_bitmaps. It downloads images to some memory in file format which does not seem to be neither of both "tmp:/" and bitmaps memory that is examined by r2d2_bitmaps. Only bitmaps that take r2d2_bitmaps memory are which we set a bitmap handle for using msg.GetBitmap() of roTextureRequestEvent. The images that I am downloading with it take around 15mb of bitmaps memory so they must take quite less file memory that roTextureManager is using, 1 to 2mb probably. So it mist not be out of memory or file storage issue. I will try to check today whether it is an Http issue or not because that is the onky possibility left. But it should not be so too as in that case roUrlTransfer should not work either.

"belltown" wrote:
However, the images were coming from servers 5,000 miles away, so maybe were taking too long and exceeding some timeout value used by roTextureManager.

I have tried on 2 locations and for me strangly more images were loading 5000 miles away from the server and less were loading near the server :).

I ended up writing my own texture manager that used roUrlTransfer, and haven't had any problems with downloading those same images that way.

So requesting for images again did not resolved the issue?

"scorpiontahir02" wrote:

"belltown" wrote:
However, the images were coming from servers 5,000 miles away, so maybe were taking too long and exceeding some timeout value used by roTextureManager.

I have tried on 2 locations and for me strangly more images were loading 5000 miles away from the server a d less were loading near the server :).

I ended up writing my own texture manager that used roUrlTransfer, and haven't had any problems with downloading those same images that way.

So requesting for images again did not resolved the issue?

When I requested the images again, they did load. I don't really think it's the distance that matters, just how slow that particular server is at serving up images. In that particular channel (when using roTextureManager), I'd wait until all texture requests had completed then retry the ones that had failed. I just didn't like the holes it left on the initial screen in the time it took before the retried images were downloaded. I didn't have to worry about that when using my own texture manager. However, the main reason I decided to write my own texture manager was because roTextureManager wasn't supported on the legacy Rokus, and I wanted that channel to work on all Roku devices. That was just before they announced that they'd no longer support the legacy Roku devices through channel updates, etc. So that exercise turned out to be a waste of time, and I'll probably go back to using roTextureManager in future projects.

Ok, re-requesting images once failed resolved this, although this should not happen in the first place. I just checked the msg.GetState() = Failed and re-requested image, did not have enough time to log error with roSystemLog to reach underlying cause of it.

I had the same problem with my custom grid. Are u invalidating the roTextureRequest before the roTextureRequestEvent is received? If so, try to maintain it until the response is received. I'm not sure abt this, but might solve the issue.

"sonnykr" wrote:
I had the same problem with my custom grid. Are u invalidating the roTextureRequest before the roTextureRequestEvent is received? If so, try to maintain it until the response is received. I'm not sure abt this, but might solve the issue.

No I have only one roTextureManager instance that is created at the start and used throughout the application and is never invalidated until application exits. Moreover if that would have been the case then requesting the images for the 2nd time should not work eother but is working.

"scorpiontahir02" wrote:

"sonnykr" wrote:
I had the same problem with my custom grid. Are u invalidating the roTextureRequest before the roTextureRequestEvent is received? If so, try to maintain it until the response is received. I'm not sure abt this, but might solve the issue.

No I have only one roTextureManager instance that is created at the start and used throughout the application and is never invalidated until application exits. Moreover if that would have been the case then requesting the images for the 2nd time should not work eother but is working.

I agree. You should have only one instance of roTextureManager for the entire app. There is no point in invalidating it. But, what Im talking abt is keeping the roTextureRequest instance alive until its corresponding roTextureRequestEvent is returned.

What he means is your texturerequest must persist until completed. If you are using asynchronous services it is important that you keep your texturerequest in scope until it actually completes with a return code. Creating a texture request locally in a function and then returning from the function after sending the request will of course invalidate any local variable created in the function as well as your request.