This project is read-only.

Multiple 100% quartile beacons being sent by VMAP adverts

Topics: Windows Phone 8
Sep 3, 2013 at 2:22 PM

When we play a VMAP ad roll, we have noticed that on the odd occasion the adverts 100% quartile beacon is being sent twice.

We are using the v1.3 beta 2 version of the framework.

Also is there any indication as to when the stable release will be published?


Sep 3, 2013 at 6:49 PM
Would it be possible to share a vmap file that I could use to try to repro this? The tracking event should fire when either the ad duration (as specified in the VAST doc) is reached or the ad completes on it's own (which ever comes first). I should be impossible for both to happen with the same ad but maybe something unexpected is happening.

At the very latest, we will ship a "non-beta" release timed with the Win8.1 GA. You may see an interim release before then as well but I can't commit to that at this moment.
Sep 4, 2013 at 11:18 AM
Hi Tim,

Thanks for getting back to me.

Our client has said I can send the VAST block but only in a private message, the vast contains information specific to the client. Is there a way I can send this to you privately?


Sep 6, 2013 at 6:05 PM
Hi Josh, CodePlex has a way to DM someone. Just click on my name from this web page and it should take you to page that has a "contact" link. This will allow you to send an email to me. Along with the VAST file, it would be great if you have any advise on how to cause the issue to repro (you mentioned it is inconsistent above).
Oct 14, 2013 at 10:16 AM
Hi Tim,

I found the issue behind this bug.

Within the VpaidVideoAdPlayer there appears to be a race condition. The 100% beacon is sent when the duration reached marker his hit and when the media ended fired. Both of these things can occur at the end of the video. I have pulled the source into our app for the time being and put a fix in, but it is by no means a permanent fix.

Would this be able to be fixed by the next release of the framework?


Oct 14, 2013 at 6:51 PM
Thanks Josh, there is an assumption in the code that calling MediaElement.Stop() will fire MediaElement.CurrentStateChanged before MediaEnded would have a chance to fire. I am not sure this is true 100% of the time and considering you are seeing an issue, I think it is safe to say that this is indeed the problem.

Therefore, I've gone ahead and checked in a fix for this to Git to avoid this possible race condition. If you need the fix now you can pull the latest source and rebuild the vsix or, it will also be available in the next update.

Thanks for reporting this!