Roku Developer Program

[SolveLLC]

I'm setting a custom buffer screen to display before call an ad pod.  It seems that it takes the device a few seconds to actually call RAF from the network and parse the pod and then display the buffer screen.

Anyway to get the this to work faster?

[destruk]

Would you be able to display the buffer screen and use a timer to start the buffering bar between 0 and say 10% for a fake prebuffer to mask the delay?  I don't think RAF can go any faster than it already does.  Much like the seemingly mandatory 2-second delay before it can grab an email address from the roku billing server and display the dialog screen.  Many times when it's in process users are moving the cursor around on the keyboard screen only to have it interrupted by the slow firmware response.

[SolveLLC]

We don't use a buffer bar.  

There needs to be a way to pre-fetch an asset before displaying it.

[RokuNB]

"SolveLLC" wrote:
I'm setting a custom buffer screen to display before call an ad pod.  It seems that it takes the device a few seconds to actually call RAF from the network and parse the pod and then display the buffer screen. Any way to get the this to work faster?

The question is unclear to me. Can you show MWE (minimal working example) of the code or explain in detail what are you doing?

Typically, in the CSAI, preroll case you'd call `.getAds()` and then `.showAds()`. `.setAdBufferScreen()` applies only to the latter, as the name implies. There is no "buffering" during the former, when VAST/VMAP is fetched and parsed. Plus, you one be doing that in a background thread during content play, so that fn has no UI. If you interrupt main content, call getAds, then call showAds, then resume content - and want to keep it that way, w/o complications - then you can show some splash screen during the `getAds()` call.

PS. i wonder if some new tech in the upcoming RAF 2.4 may help your case. when do you show ads and how do you determine the ad breaks position? Are there mid-rolls? is there 1 or more ads per breaks?

[SolveLLC]

These are mid-rolls.  We stop main playback, call getAds and then showAds and then resume content.

I guess what your saying is to call getAds while the playback is still happening.

"PS. i wonder if some new tech in the upcoming RAF 2.4 may help your case. when do you show ads and how do you determine the ad breaks position? Are there mid-rolls? is there 1 or more ads per breaks?"

These are mid-roll pods with at least 2 ads.  We run a timer that kicks off an ad at X seconds from a stored array.

[destruk]

Nice.

[RokuNB]

"SolveLLC" wrote:
These are mid-roll pods with at least 2 ads.  We run a timer that kicks off an ad at X seconds from a stored array.

"SolveLLC" wrote:
I guess what your saying is to call getAds while the playback is still happening.

Given your current setup, of not having a single VMAP with all ad breaks pre-populating at start, i think yes - i think a better approach would be to call in a background task `raf.getAds()` a few minutes before the ad break, then it can pass the result ads to the thread that controls the content play, so it can do `raf.displayAds()` on that.