Adtech demo video preroll ads work but live adtech URLS break the ova.swf script.

[kalemanzi]

Good day. I am a developer for a website and we have adtech adverts on our site. For a current campaign, we urgently need to play video preroll advert. Since we already owned the licensed version of JWplayer and use it on the website, we purchased the OVA plugin to run these ads. After much frustration, I came to the conclusion there is something wrong with how the ova.swf parses the generated ad tech XML file. The demo works fine but it fails when we use the campaigns provided URL.

We are trying to get the system to work on for instance this video on  http://www.wavescape.co.za/video/the-latest-clips/tripping-trick-bike-madness.html but it does not load the preroll advert, even though there are some calls going out to the adtech server.

Here is an example where we are implementing the adtech url provided by the client:  http://www.wavescape.co.za/test/dist/samples/notworking.html This has the same issue.

Identical setup, just pointing to the other xml file with a demo ad tech url  http://www.wavescape.co.za/test/dist/samples/working.html
It works perfectly.

view source if you need to see whats going on with embed code.

client provided url:  http://adserver.adtech.de/?adrawdata/3.0/567.1/2958480/0/1725/noperf=1;cc=2;header=yes;alias=myalias;cookie=yes;adct=204;key=key1+key2;grp=[group];misc=[TIMESTAMP]

Demo adtech URL:  http://adserver.adtech.de/?adrawdata/3.0/990.1/2366662/0/1725/noperf=1;cc=2;header=yes;alias=myalias;cookie=yes;adct=204;key=key1+key2;grp=[group];misc=__random-number

both resulting generated xml files validate

I have spoken to another developer who works in as3 and he encountered the same problem. He ended up developing his own player in as3 and this url that does not work with jwplayer still works with his player which leads me to the conclusion that there really is something wrong with the ova.swf file.

I am not an action script developer, and do not have the whole thing setup to debug. running this through a debugging setup should allow this problem to be traced and pin pointed.

Unfortunately we are sitting with a situation where we paid for jwplayer and OVA to serve ads, and the program does not what it needs to do and if the ad sales people are not happy with us, then my client will loose the deal. My problem is also that I suggested jwplayer and OVA as the platform because we already used it in our current setup and it seemed like the right thing to do! Thanks whoever can help, much appreciated. fixing this will definitely enhance OVA.

we have also registered for priority support, but can´t figure out who to contact or where to go. We have submitted a request at the contact page, but there is no response since almost 8 hours ago.

[paul]

Hi,

Sorry for the frustration. Looking at this now...

Paul.

[paul]

You are right. There is a parsing issue on this VAST response:

This is coming out of the parsing:

tag structure is non-compliant - ignoring response

I'm trying to find out what's changed in the AdTech VAST response and sort it quickly for you....

[paul]

Right, found the issue.

The VAST response that you are getting on that AdTag doesn't seem to be VAST 1.1 compliant.

Here are the tags in question:

<Video><VideoLength>80</VideoLength>

A valid 1.1 response has:

<Video><Duration>00:00:16</Duration>

"Duration" is used instead of "VideoLength"

I can add in support for the "VideoLength" tag to fix your issue, but I'm wondering why you are getting a non-VAST compliant response from AdTech in the first place - that seems very strange to me as the VAST responses that I have in the demos etc. have compliant structures (e.g. <Duration> is used)...

[kalemanzi]

That is what freaked me out as well. Could you please add support for it then, because getting hold of adtech is going to be a mission. We are working with 365 digital who is a client of adtech and like I explained, their dev went as far as writing his own player.

[kalemanzi]

I got the same issue with v4 and v5 + OVA btw.

[paul]

Sure - it will be the same for all versions since they use the same parser - I'm adding support for that tag now...

I can see that tag <VideoLength> in the public comment version of the VAST spec, so perhaps they implemented based on that version.

[paul]

Oh, actually, this is a slightly bigger problem...

This VAST response doesn't have an <inline> tagset either... gosh, it's a very old form of the spec.

I'll have to work around that as well.

[paul]

Fixed.

Have now added support for the pre V1.0 public comment VAST template structure - no inline/wrapper.