NetStream.close() freezes in Android

[savimonty]

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.

[phillipkerman]

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

[savimonty]

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.

[Phil Flash]

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

[savimonty]

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.

[Colin_Childs]

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...

[savimonty]

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.

[savimonty]

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.

[Guest]

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

[Phil Flash]

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

[savimonty123]

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.

[Kalvyn Rasquinha]

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