Roku Developer Program

[destruk]

"everyone here seems to already know how to do this." - everyone in this thread has tried to do it, or done it. It isn't as common a thing to do as say, creating a poster selection screen.

For your image url, it needs to be url:"file://tmp:/filename.jpg"
ie "file://pkg:/images/splashsd.jpg" - but tmp instead of pkg
What you would probably do is use your AsyncGetToFile so your channel continues to run and do it's regular work while the file downloads. And wait for the "download successful" event to know as soon as it's done downloading the file, and then draw it to your canvas or roscreen. If you try to draw the image before it has finished downloading then I don't think it will draw as the file will not have been closed. An important point is to set the RequireAllImages to draw to False as suggested above.
If you have a bunch of images, it might make more sense to start the download to tmp as soon as the slideshow section is selected - set it to download them 5 at a time, asynchronously, wait for the transfer succeeded event for one, and ask the user to wait if it's not finished in time with a dialog/busy box display.

You'll need to set a port to receive events from the transfer object -
UT=CreateObject("roUrlTransfer")
port=CreateObject("roMessagePort")
UT.SetPort(port)
UT.SetUrl("http://server.com/file.wav")
UT.AsyncGetToFile("tmp:/file.wav")

In your message loop,
if msg(type)="rourlevent"
If msg.getint()=1 'completed download
...
End If
End If

http://sdkdocs.roku.com/display/sdkdoc/roUrlEvent

I'm sure someone can clean this code up, but you get the idea? By using the roUrlevent to test when the file has downloaded, there shouldn't be a reason to check the actual directory for the file. Tmp works like a cache system - the oldest files get pushed out to make room for new files (as I understand it)
If you want to check all the files though and file operations, check out the ifFileSystem interface - http://sdkdocs.roku.com/display/sdkdoc/ifFileSystem
You will not be able to determine how much room is left in local fle systems - so space free for tmp will be useless. And you can't write to external file systems so that info is also rather useless.

[squirreltown]

Thank You destruk, I really appreciate your (and everyones) efforts and time. I dont know how anyone could get a channel built without this board.
I will apply what you've said and I'm sure I'll have another question.
I think its a good point about the file being called before its downloaded into temp which is certainly a possibility - I'm wondering if that could make this process cause more problems than its worth? - Do i need some repeating request in the loop in case that happens? Obviously, not being ready for the load image command would make it just sit there with the loading... screen which would be worse than what i have now. I thought about downloading multiple images but unless it can go on in the background and not impair the slideshow I'm probably second guessing the user enough with this scheme.

Thanks

[destruk]

The wait loop for the message port will already be looping to check for received messages. The builtin roku screensaver component downloads the first image and buffers the next four. When the user presses forward on the remote, or the time to change the image arrives it downloads the next image past the one that has been buffered. (I'm not saying this is the best way - just an example of what it does as default behavior). If you prefer to enable blocking in your code while the image downloads, you can use a GetToFile request instead of ASyncGetToFile - with result=http.GetToFile("tmp:/detail.jpg") -- if the delay is the big issue, use a higher compression format for the image, or toss up a busy notice while it downloads with or without a progress bar (progress bars are on the developer blog) or text percentage. It might also be considered to have two slideshows - one for the main images and one for the closeup images.

[squirreltown]

Thanks for explaining the loop thing. I really am at the nitpicking stage, but every little thing makes it seem slicker for the user. I have a "loading.." graphic on the canvas which gets covered by the image so it appears like feedback there. The time to show the image is 3-4 seconds from the button press so its not horrible but if I can cut it in half or eliminate it i want to. I think im at my limit compression-wise but I will revisit that - the TV screen kills detail any way.
Once the image is loaded, like if you procede a few slides and then come back - pressing the button appears to do nothing, but only for about 1.5 seconds - and then shows the complete canvas with image - it doesn't go through the showing blank canvas immediately/then image process. I like that way better and the only way to do that is to get the image into RAM first.
Really like the second slideshow idea though, can they run concurrently and use some function to switch between them? I may get to that, but I cant see far enough ahead on how to do that right now, plus it seems like syncing the two slideshows might be an issue.

Thanks again.

[squirreltown]

OK I got it working! Thank you to theEndless, destruk and RokuMarkn, without you I'd still be seeing that annoying "loading.." graphic on the canvas.
It works as imagined, there is a 1 second-ish wait after hitting the close-up button and then the canvas shows complete with image. Much better. I did have to use the actual filename instead of a generic one when saving to tmp:/ because of the cache not overwriting the file. Now only two last questions:

1) Do i need to worry about filling up tmp:/ and having that cause a crash? (please say no)

2) The only side-effect is that when the main image displays, the closeup image starts downloading, and if you hit the info button right away during those few seconds, the info dialog wont show until (I presume) the closeup image has downloaded. Am I misunderstanding the function of the Async command? I'm guessing this is not a big problem in practice but again, I'm at the nitpicking stage.

Thanks All.