RAF and ui_resolutions=fhd problem on some devices

Archived
1

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:

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

2

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.

3

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_szs=300x250&ad_rule=1&impl=s&gdfp_req=1&env=vp&output=vmap&unviewed_position_start=1&cust_params=deployment%3Ddevsite%26sample_ar%3Dpremidpost&cmsid=496&vid=short_onecue&correlator=

Hope this helps

4

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”)

5

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.

6

“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?

7

“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.

8

“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.

9

“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.

10

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.