NetStream.close() freezes in Android

Report · May 04, 2012

Hi,

Randomly (not always), when I close NetStream, the entire app just freezes.

Even performing a NetConnection.close() causes freezes.

I do not see any errors (even in the debug mode) so I cannot tell more.

Sometimes even simply renewing the current NetStream to "new NetStream()" or disposing it causes a freeze.

I am sure all this attributes to releasing resources and message passing between the client and FMS which probably ends up in a deadlock somewhere.

I'm not ruling out the possibility that this could also be a problem because of a slow internet connection.

What's the work around for that?

Instead of close() (if it's buggy i.e.) are there other alternatives to stop listening or sending media over netstreams?

If this is indeed a bug, I know Adobe won't let us know of it but I hope this is solved in the next AIR Release for Android.

I'm testing this on an Android 4.0 (Galaxy Nexus).

I've yet to try this on 2.3 or 3.x. Will update as soon as I try them.

Any leads?

Thank you very much.

Savio.

Report · May 04, 2012

Have you tried NetStream.dispose() (instead of .close())? I can't see any difference but .dispose() is recommended.

Report · May 11, 2012

Dispose had the same issue.

I wanted to add one more thing. This is on ICS (Android 4.0).

I've not really tried it that much on 3.x or 2.3.x

I also wanted to add that I had to call play twice to get the peer video. The first time wouldn't work.

Something is definitely buggy with Air for Android 4.

Savio.

Report · May 15, 2012

Hi,

Same problem on Asus Transformer with ICS 4.0.3 and on Android Emulator with AIR 3.3 and AIR 3.2

Vote for this bug and/or add a note:

https://bugbase.adobe.com/index.cfm?event=bug&id=3190676

Philippe

Report · May 15, 2012

Hi,

I wanted to add.

I noticed this happens only when the app's on debug mode. If I install a release version, the issue sort of goes away.

I cannot yet ascertain this behavior, but I will make certain in a day or two when I tested that behavior enough.

If this is true, I'm assuming that the debug version is trying to send a message back to the debugger on the computer whenever onclose happens and fails there or jst goes into some loop.

Just my assumption.

But, I'll update this thread soon enough.

Savio.

Report · May 15, 2012

I also had some issues with Android 4. I managed to solve them by using AIR 3.2. If the problem goes away with with a release version, are you packaging it with a captive runtime? That would explain why the release is fine and the debug is not. Debug versions use whatever AIR version is installed. Just a thought...

Report · May 15, 2012

You are right. I packaged them with captive runtime.

Yes, the debug version is 3.2, as in what's on the phone is 3.2

I will try running them without captive and try to use the PC captive and check both and let you know in time.

Savio.

Report · May 24, 2012

An Update.

Everytime I use the Camera and either use NetStream.Dispose or NetConnection.Close, Everything stops, but the logs (adb logcat), still shows the CameraHAL leaving messages every second or so. with FPS information as a floating point value.

Now when I kill my AIR app, that information stops.

This is using Captive Runtime. It seems to happen the 2nd or may be the 3rd time I close or re-open a connection or re-use it. I can never tell when.

With Captive Runtime, my app just dies and shows a huge error ... Using a Samsung Tablet with ICS 4.0.3

I/DEBUG ( 90): SET

I/DEBUG ( 90): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

I/DEBUG ( 90): Build fingerprint: 'samsung/espressowifiue/espressowifi:4.0.3/IML74K/P3113UEALD3:user/release-keys'

I/DEBUG ( 90): pid: 18877, tid: 18987 >>> my_app_package_name <<<

I/DEBUG ( 90): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000014

I/DEBUG ( 90): r0 00000000 r1 5c4a32d5 r2 00003868 r3 00007df4

I/DEBUG ( 90): r4 00000000 r5 00000140 r6 0059aa60 r7 005aa028

I/DEBUG ( 90): r8 00000000 r9 00577c18 10 5cb86c30 fp 00002978

I/DEBUG ( 90): ip 00000140 sp 61a84960 lr 5bf651bd pc 5c4a32d4 cpsr 60000030

I/DEBUG ( 90): d0 0000000000000000 d1 4616f800000025be

I/DEBUG ( 90): d2 0000002b422c0000 d3 00020000fffffe70

I/DEBUG ( 90): d4 fffdfffe00000002 d5 00010000fffdfffe

I/DEBUG ( 90): d6 0002000200010001 d7 0000000042c80000

I/DEBUG ( 90): d8 40de100000000000 d9 3ff0000000000000

I/DEBUG ( 90): d10 42bd58e2c11bae3a d11 000000003e375326

... and so on ... some register issues .. I don't understand more.

Report · May 28, 2012

Hello, did you manage to find any solution or answer?

Report · Jun 12, 2012

Hi,

This bug is confirmed by Adobe.

I'd like to ask everyone affected by this issue to take a minute

and vote for the following bug. It currently has zero votes:

https://bugbase.adobe.com/index.cfm?event=bug&id=3190676

See notes for more details.

Philippe

Report · Jun 20, 2012

I think Air 3.3 seems to have solved the close problem.

But opens another problem.

NOW ... ns.play() doesn't work. Audio works. Video freezes to the first frame or jst black screen for some reason.

Report · Jul 18, 2012

Hi guys. If the freeze you are observing is because the traffic with the server does not stop when you call close(), it will be fixed in the next version of AIR 3.4. Take a look at this thread http://forums.adobe.com/message/4563418#4563418. This is the bug that was fixed - https://bugbase.adobe.com/index.cfm?event=bug&id=3070987. The internal bug will get marked as closed soon and that should propogate up to this one.

Thanks

Kalvyn