Roku Developer Program

[tim_beynart]

OK that makes sense. Our implementation is similar, but we do not get the raw VMAP XML from Adobe, we get a JSON translation. Which we then translate into the RAF-friendly ad pods format.

[acreskey]

I did notice this log output from RAF when the ad pods are not returned:

RAF 2.0108; empty response: 

Roku_Ads_util_getStringFromUrl: requesting URL: http://pubads.g.doubleclick.net/gampad/ads?slotname=/82114269/rrafcs/bf/dev&sz=1920x1080&tfcd=0&url=http://roku.com&unviewed_position_start=1&output=vast&impl=s&env=vp&gdfp_req=1&ad_rule=0&description_url=http%3A%2F%2Fapps.roku.com&vad_type=linear&nofb=0&sdkv=roku&min_ad_duration=0&max_ad_duration=60000&rdid=971ccf63-9e60-53c3-b2ad-5403bb5f299a&is_lat=0&idtype=rida&correlator=1499806025110&scor=1499806025110&pod=POD_NUM&ppos=POD_POSITION&cust_params=genre%3DROKU_ADS_CONTENT_GENRE%26ua%3DRoku%252FDVP-7.70%2520%2528047.70E04093A%2529%26ai%3Ddev

Although I do actually get a response when I manually request that URL.

[acreskey]

It looks like it's timing... if I call adPods = adInterface.getAds() after a small time delay, the correct ad pods are found.
Interesting!

[RokuNB]

"acreskey" wrote:
The VMAP is returned from the Auditude stitching server, so we are expecting it to be account for the extra frames. But the issue we're seeing is not that the Ad UI is rendered at a different time, it's that while we see two ad breaks in the VMAP, only one ad pod is generally found, and it's always rendered as a pre-roll.

That is a really strange thing if happening - mid-roll with a properly set offset (e.g. <vmap:AdBreak timeOffset="00:05:35.368" ...>) somehow turning into a pre-roll. I'd like to know more on this if indeed is happening. (Like capture the VMAP that does that - and btw for test purposes you can do raf.setAdUrl() to a local file, say in tmp:/ or pkg:/ - then you can print formatJson(raf.getAds()) )

[acreskey]

Thank you RokuNB for the debugging technique.

So what was happening was that Auditude provided me with a URL for the VMAP that wasn't actually ready. If I requested that VMAP immediately (i.e. the next line of code), it would most often fail.
So basically I was providing RAF with an invalid ad URL.

Because the default RAF ad prefs are set to backfill ads,  RAF was making its own ad request against the Roku default ad service (hence the "preroll" ad pod).

So I've disabled the backfill of ads and I have to poll the VMAP URL until it's valid.

Thanks for the help.

TL;DR: RAF did not actually have any issues in determining ad pods from a valid VMAP. If you provide an invalid URL the default behaviour is to backfill with Roku ad service ads.

[tim_beynart]

Good catch, it took me quite a while to figure out that RAF backfills ads by default. This caused quite a bit of head scratching and some conspiracy theories.
IMHO backfill should be opt-in, not opt-out.
For anyone else reading this thread, include the following line to turn off backfill ads:

'disable roku's backfill ads
adIface.setAdPrefs(false,0)

[RokuNB]

"acreskey" wrote:
So what was happening was that Auditude provided me with a URL for the VMAP that wasn't actually ready. If I requested that VMAP immediately (i.e. the next line of code), it would most often fail. So basically I was providing RAF with an invalid ad URL.

Because the default RAF ad prefs are set to backfill ads,  RAF was making its own ad request against the Roku default ad service (hence the "preroll" ad pod). So I've disabled the backfill of ads and I have to poll the VMAP URL until it's valid. Thanks for the help.

TL;DR: RAF did not actually have any issues in determining ad pods from a valid VMAP. If you provide an invalid URL the default behaviour is to backfill with Roku ad service ads.

Wow, i can only try to imagine how confusing that is. And thanks for explaining what the cause was. Indeed turn off backfill (at least for development) and... why is Auditude providing non-ready VMAP? What's the logic behind?! There must be some way that can be tuned up...

[Tyler_Smith]

We had this same issue.
With Auditude, you must always make a request to your m3u8 BEFORE the VMAP in order for the VMAP to return.