The one that got away: A Windows Phone bug that can not be solved

Submitted by Robert MacLean on Fri, 03/06/2015 - 07:34

Clipboard01A project I was recently working on ran up against an interesting bug and, unfortunately, it was a bug we had to ship the app with in the end. My main reason for sharing this is in the hope that should you find this same bug that you know you are not alone and maybe it gives you some ideas what you can do. Not only did we find this bug, but we have been able to confirm this happens to a number of other apps in the store.

The Issue

The app itself is an audio streaming app, except it is not real streaming, it is actually HTTP progressive downloading and playing the file as it downloads. The problem we had is that when it finished playing one file, it would not load the next file. Part of the pain for us is that this is a pretty hard scenario to identify as it has these requirements for the bug to raise it’s ugly head:

  1. It is related to network only. If the file was on disk already it would work every time.
  2. It only happens when on battery. Plug the phone in or the emulator (which is always “plugged-in”) and it won’t show the issue.
  3. The screen must be locked & off. Any interaction with the device causes the problem not to appear.
  4. If it is playing a file, it will finish that file fine. The issue only happens when we skip to the next file
  5. It will not raise any errors or exceptions – it just silently does not play the next file.
  6. This is using background audio, so it is not that the app is being suspended.

We tried everything as a team and could not solve it, so we escalated to Windows phone support. This was the first time I dealt with premier Windows phone dev support, and while they cost a lot, they know their stuff and could help out to confirm out understanding and give us some ideas to work around the problem.

Root Cause

The cause is this: when the phone is on battery and there is no interaction, the phone lowers the signal strength of the antennas. This is to save battery, but it also means that your HTTP connections could be too slow to work properly and so the audio won’t play.


This does not seem to happen with the Windows Phone 8.0 Silverlight apps, which have a different way of handling background audio, however moving from Universal apps to that maybe too costly (it was for us). The other option is to use real streaming and it is less impacted by this and also you can do a lot of smart server side stuff to ensure it keeps running.


This happened on Windows phone 8.1 and it looks like it still happens on Windows 10 for phone. The official response is “by design”, although I think it is more a unexpected side effect of a number of design decisions; but it could change. If you think it should change, please vote on the user voice item for this so that the product team can see enough people care about resolving it.