Roku Developer Program

[24i]

Hi,

We are having a problem with displaying DFP ads where the ad is not displayed in fullscreen but covers only a portion of the left corner of the screen. Photo for clarification: http://i.imgur.com/gYf9WuY.jpg

We are using this sample url:
https://pubads.g.doubleclick.net/gampad ... orrelator=

The issue occurs on these devices:
- Roku Express
- Roku Stick 3500 
- Roku Stick 3600X
- Roku 3
Which all have the max ui resolution of "1280x720" according to this page:
https://github.com/rokudev/docs/blob/ma ... es.md#giga

So it appears (again) that the issue is caused due to the ui_resolutions setting. We have our channels configured with 'fhd' and it only appears to fully work with the 'hd' setting. We think that this is a bug within the RAF.

Anyone else having this problem? 

Thanks,
24i

[NB_]

I just plugged your URL in couple of test apps (SDK1 and RSG), set ui_resolutions=fhd and there was no problem playing pre/mid/post-rolls - they showed full screen. And i verified the UI was in 1080 too.

So, something else must be funky in your app. What kind of app is that? If SDK1, is it canvas or roScreen; if RSG - do you use the old way or the newly published native integration? And so on, spill the beans. Feel invited to provide a minimal example that demonstrates the issue.

[24i]

Hi RokuNB,

Thanks for your quick response. It is concerning an RSG app. Here is an example app containing the issue described above:

https://github.com/tim1256/RAF4RSG-sample

We forked the RAF4RSG example app supplied by Roku and edited the manifests ui_resolutions to use 'fhd' instead of 'hd' and added the following ad url: https://pubads.g.doubleclick.net/gampad/ads?sz=640x480&iu=/124319096/external/ad_rule_samples&ciu_sz...

Hope this helps

[NB_]

Thanks 24i -
that is a great way to reproduce the issue, by simply plugging the URL in that sample - appreciate it!

Yes, i can see the issue - when the app is manifested as FHD but playing in HD UI - the video is shrunken as shown on the image. We'll look into it.

Until this is fixed - i doubt you will like that - but a workaround for the time being is to design the app for

• ui_resolutions=hd or


• ui_resolutions=hd,fhd

(i think any ui_resolutions that contains "hd" - or no ui_resolutions manifested, which implies "sd,hd")

[NB_]

There is a 3rd possible workaround i can think of, if really really insisting on designing the channel for FHD only:

• Do not supply the 3rd, optional parameter `view` in showAds()

When present, it indicates to RAF to use the native-RSG implementation which currently exhibits the issue.

If no 3rd param however, RAF would suspend roSgScreen temporarily - then use the legacy (SDK1) ads implementation, which does not have the issue - and then resume RSG. NB: when using the RAF's non-native-RSG implementation, the getAds()/showAds() calls have to be done "the old way" - from the main thread, not from a RSG task.

That's a temporary band-aid to be sure. The issue will be resolved in a following version of RAF. 

[squirreltown]

"RokuNB" wrote:
 If no 3rd param however, RAF would suspend roSgScreen temporarily - then use the legacy (SDK1) ads implementation, which does not have the issue - and then resume RSG.

So it must create a roScreen to do this, yes? 

[NB_]

"squirreltown" wrote:
So it must create a roScreen to do this, yes? 

It may create temporarily a roScreen, or roImageCanvas, or something else from SDK1, yes.

[24i]

"RokuNB" wrote:
There is a 3rd possible workaround i can think of, if really really insisting on designing the channel for FHD only:

• Do not supply the 3rd, optional parameter `view` in showAds()

When present, it indicates to RAF to use the native-RSG implementation which currently exhibits the issue.

If no 3rd param however, RAF would suspend roSgScreen temporarily - then use the legacy (SDK1) ads implementation, which does not have the issue - and then resume RSG. NB: when using the RAF's non-native-RSG implementation, the getAds()/showAds() calls have to be done "the old way" - from the main thread, not from a RSG task.

That's a temporary band-aid to be sure. The issue will be resolved in a following version of RAF. 

Is there any ETA on the new version of RAF? As all the 'workarounds' are not do-able for us unfortunately.

[NB_]

"24i" wrote:
Is there any ETA on the new version of RAF? As all the 'workarounds' are not do-able for us unfortunately.

A fix for this is under testing. It should be available "soon" but i cannot provide an ETA.

[NB_]

RAF 2.1 has been released, it addresses this issue.
It has a minimum firmware requirement of 7.6, meaning the library won't update on devices with fw 7.5 and earlier.
Note that 7.6 is mid-rollout right now, so you may have to wait for a complete rollout to reach your devices.