Freezing Preview Screen : Locks WP8

Jul 13, 2013 at 8:38 PM
First - Thank you for such great efforts on this port. It's (mostly) working great. On a lumia 505 with WP7.8 I get 100% scans, with 100's of tests.

On a Lumia 920 with WP8, The Preview screen is locking about 50% of the time. If the camera is stable, it seems to easily find the QRCode, decode it, and send it to the app. If the camera is moving, then the frame will freeze, and just show the same frame over and over. It doesn't throw an exception, it just kind of freezes. It also doesn't kill the app, again it just freezes. The back button here is disabled. I get a vibrate on the back button touch, but the screen stays. If I press the start button, then back, the app is gone. #sketchy!

So I thought - let's attach a debugger, and see what's happening. Here is the weird part. With my 920, and the debugger attached, I get a 100% scan rate. I'm talking 100's of test scans, over and over, it's 100%.

BUT .. without a debugger attached .. i go back to a 50% freeze. I tried it with both release and debug mode to try and narrow down the cause. I also played with the options of AutoRotate and TryHarder both true and false combinations, with no apparent differences.

Thanks in Advance for any ideas you might have, to help us get to the bottom of this.

Jul 13, 2013 at 9:11 PM
Hi scottate

did you try the newest version of the demos in the ?
Jul 13, 2013 at 11:38 PM
Would that be any different if we are trying to maintain back compat with WP7.8?
Jul 14, 2013 at 7:58 AM

so you would like to have a Windows Phone 7 example. Please take a look at its a very basic wp7 sample.
I hope it helps a little... :)
Jul 25, 2013 at 8:13 PM
Edited Jul 25, 2013 at 8:33 PM
Scott, did you have to make any changes to the code for it to work on your 920? I'm working with an 810 and the code that extracts the image from each "row" is returning senseless data when running on the device only.

---- RE: Your attached vs. non attached issue, I have seen similar situations very often. There is some theorem that says that you can't observe a system without disturbing it, thats where you are. Knowing how the "observation" disrupts the system being under observation helps to figure how the "unobserved" state would be. I have no idea where I heard it but makes lots of sense :D

Throwing some ideas to the air, some re-stating or rephrasing what you mention:

The fact that the app is gone after the Start -> Back cycle suggests me that there is either a timeout on the suspend event (blocked code... as in the screen thread frozen) or an exception on the suspend code is taking place, so the system terminates the app.

The debugger is slowing the code and modifying the memory management behaviour; regardless of whether it hits breakpoints or not. Even if Debug vs. Release gave a hint of what is going on, it wouldnt matter anyway because in the store publishing process the code can be "massaged" again.
  • {guess} Code running slower or memory (collection mainly) means less screen refreshes per second {guess}, meaning less data moved around memory per time unit.
I have not looked at the part of the code that manages the live previewing and capture. I would {guess} the bitmap capture part is OK so the problem must be on the preview side The preview routine must be a task {guess} and that task.OnComplete re-starts the same task. Now, {guess} assume that there is an exception inside that task: If unhandled then there will be a global exception (UnhandledException something I believe) and the app could eventually crash. Sometimes developers put an empty catch {} where the AggregateException is supposed to be handled. I have. If that is the case {guess}, maybe that catch is not re-starting the task, so that task well, "dies" there and the screen freezes.

Lots of maybes, {guess} tags and instances of the word "task". Just ideas.

PS: My live screen feed does not freeze. Can't recognize the scanned bar code, thats a separate issue. But, doesn't block. Isn't the 920 supposed to be faster than the 810?