Expand my Community achievements bar.

Radically easy to access on brand approved content for distribution and omnichannel performant delivery. AEM Assets Content Hub and Dynamic Media with OpenAPI capabilities is now GA.

Screen sharing with Adobe AIR not functioning

Avatar

Level 3

I have an Adobe AIR app that is using screen sharing, but, the broadcast (or reception by the subscriber) rarely sends updates.

For example, when a session first starts, the subscriber will get the appropriate screen (most of the time), but, any updates to the screen are intermittent, at best.  My app's ui has an accordion on the left and html windows in tabs on the right.  The html windows are using standard Air htmlloader component.

The AIR app is using Flex 3.4, and uses the latest 2.5 Runtime available from get.adobe.com/air.

Some examples where the sceen update is not received by the subscriber:

- changing areas on the accordion

- opening new tabs

- changing any content in the htmlloader component

- if sharing entire desktop, and then bringing up another app on the screen never shows the new app to the subscriber

I can tell that the session is live, because all of the cursor movement (even the clicks) are broadcast appropriately, it just doesn't send the screen also!  Also, I've tried sharing window, application and desktop, but, it see the similar results with all.

I've also seen similar results with being a subscriber on a Mac running OSX.  I've also run the Air app on a PC running Windows Server 2003, the Air app invokes the Adobe ScreenSharing addin, but, does not prompt for desktop/window/app to share, so, it never publishes.  I have an AddInLauncherEvent error handler for AddInLauncherEvent.FAIL, but, it's never fired.  This same behavior I've seen on my Mac. 

For most of my testing the host of the screen sharing session is running Windows Vista 64 bit.  The addin was by manually downloading from Acrobat Exchange (http://www.adobe.com/cfusion/exchange/index.cfm?event=extensionDetail&loc=en_us&extid=1802025#) for the PC and from acrobat.com on the Mac.  (the dll's seem to be updated everytime the addin runs, not sure why)

Can someone tell me if these are known issues ?  This feature is basically unusable to me in its current state.

Thanks,

David

38 Replies

Avatar

Level 2

Hi Guys I just made a post, and while reading the issues described here I think we are experiencing similar issues about the delay in screen-sharing, the cursor working and the intermittent updates after 2 to 3 minutes.

http://forums.adobe.com/thread/842096?tstart=0

I have to say the description of the issue exposed here is almost uncanny to what we are experiencing. If this is the case, I would like join in to help debug this faster.

Kind regards.

+LA

Avatar

Level 3

Both had fairly high resolutions, subscriber had 1920 by 1080 (32 bit) and the publisher was 1680 by 945 (32 bit).  I reduced the subscriber to 1280x720 and it started working fairly well, although it still had times where it took 30 seconds to update the screen.

I'm sharing this screen while I type and it still hasn't repainted the last sentence on the subscriber screen, and, it's been over a minute since I typed it.

Also, as some point, on it's pause time, the screen subscriber area gets very fuzzy, and extremely pixedlated, usually for 10 to 20 seconds, then repaints.  And then, I wait again for the next update.

So, it's a little better, but, seems like it's only better because of the pixels have been reduced.  But, it's still really far.

So, bottom line, for this test is reducing the resolution helps, in the pause time, but, it's still VERY long and seems like it's still experiencing a "hang" of some kind.  And, the pixelating, is that common?

Thanks,

David

Avatar

Employee

Actually what I was asking was to reduce the resolution on the publisher side.

FMS doesn't do any downsampling if the "receiver" resolution is smaller than the "sender" resolution, so I was thinking that it would be interesting to know what happen if you just send less pixels to the "receiver".

The ScreenSharePublisher has some quality settings that we can play with (frame rate, image quality, etc.) but I would start by just sending "less pixels".

Avatar

Level 3

Raff:

Sorry, I wrote my comment backwards, I actually reduced the publisher resolution first, same results.  Then, I reduced the receiver resolution as well, had minimal effect.

My publisher is:

<rtc:ScreenSharePublisher id="sspublisher" playerVersion="10" connectSession="{cSession}" enableHFSS="false" fps="15" quality="70" />

Also, fyi, I also have a mobile version (ios) that only subscibes to the same screen sharing, and, the same behavior occurs in this client.  It gets a couple of updates for the first few seconds, then stops for a few minutes, then gets a couple of updates (also pixelates before the update).  Basically the same behavior as the web and Air subscribers.

All are using 10.1 LCCS swcs.

Thanks!

David

Avatar

Level 3

Finally got around to testing this some more, and here's some interesting information: this problem only seems to surface when the broadcasting client is on Windows Vista (confirmed on both 32bit and 64bit versions).  When the publisher is on the Mac, I do not see this problem at all: all screen updates are sent almost immediately.  All of these machines are the same internal network.

If you look at the Windows Task Manager, the CPU Usage for the acaddin.exe task hardly ever moves (0 to 2), but, when it actually broadcasts a change, it will spike up to 8 or 10 when it's active and publishing a change to the screen.

But, alas, even with lots of screen activity, acaddin.exe does not detect a change, and therefore, doesn't seem to do anything.

And, this doesn't seem to matter if I'm using the Air client or the web client (very similar code in both).

Hope this helps...

Avatar

Former Community Member

Hello,

Vista has the same problem as Windows 7, where the add-in pop-up doesn't force focus to the front of the screen. If you click on the add-in button on the Windows toolbar, does it fix the issue?

Thanks,

JG

Avatar

Level 3

Selecting the add-on during the session seems to have minimal (if any)

effect on the publishing of the screen.

Avatar

Level 3

This is obviously a problem with acaddin.exe...it doesn't send any changes,

just sits there with 0 cpu, doesn't send any changes to the server.

How can I get help with this?  Is there someone else I should be contacting?

Avatar

Level 3

Can someone PLEASE help with this?

Avatar

Former Community Member

Hi David,

I am contacting you offline to see if JG/Arun/I can further assist you with this issue.

Thank you,

Julien

LCCS Quality Engineering

Avatar

Level 1

I'd like to have updates regarding this issue as well. Cursor movement is about a second late which is normal, but the actual screen or updates to the screen comes up anywhere from 30 seconds to 2-3 minutes or never at all. Thanks.

Avatar

Level 2

"Hi David,

I am contacting you offline to see if JG/Arun/I can further assist you with this issue.

Thank you,

Julien

LCCS Quality Engineering"

Hi Julien,

My problem is the perfectly same with ScreenSharing and I need help too. Please share the result of "further assist"!

Thank's!

Avatar

Level 3

tomipoint:

There are no updates to this issue...I still can't get screen sharing to work properly in my app.

I sent the code to Arun/Julien and they were able to duplicate my issues on Windows, but, it works fine on the Mac, which is fairly obvious to me that the issue is the Windows add-in.  I have suggested this to Arun/Julien at Adobe, but, have had no response yet.

Thanks,

David

Avatar

Level 2

Hi,


I have to find a sample, what works well for me with my developer LCCS account. Download and install the LCCS SDK with Navigator (https://cocomo.acrobat.com/), and search for: {LCCS SDK install dir}\com.adobe.lccs\sampleApps\ScreenShareExample\src.

In the source code modify the userName,password,roomURL parameters.

I use this sample in my app, and works well too. (WIndows 7 64 bit)

I don't know what is the trick, because nothing special in the code...Maybe the layout of display objects....

Do you know this?


ScreenShareSubscriber.requestControlling();


Screen control... and it works!

tomipont

Avatar

Former Community Member

Hi All,

To be painfully clear, we also built a smaller AIR app that did screen

sharing properly on both platforms. There's something in David's app which

is causing settings to get set improperly, but there's just too much code

there for us to take on at the moment.

nigel

Avatar

Level 1

I got the same results when I tried it on the demo screen sharing app. I'm

convinced it has something to do with either the flashplayer version or the

connect plug in itself. I got it to stop the '2 minutes at least wait per

refresh, wait 2 more minutes or so, refresh cycle' after uninstalling the

plugin, uninstalling flashplayer, and reverting to an older version. And

then updating to latest when that didn't work, uninstalling the plugin

again. I'm not saying that that fixed it though, just that for some reason

the problem is gone.

Avatar

Former Community Member

Hi Arturo,

Try take a look at http://www.riagora.com/2010/09/build-a-chat-with-flex-test/ i believe you will find solve to your probelm in this example.

Regrads,

Avatar

Level 3

Nigel:

There's no doubt that a "smaller app" works, but, unfortunately, this isn't the situation.  We have a complex app, but, the QA folks (Arun/Julien) could not find any issues with the code.

I still believe it is related to the add-in, which, simply doesn't see and broadcast changes for a while, then it wakes up, sleeps for while, etc.  But, for some reason, this isn't being pursued.

I posted a while back how can we engage someone (i.e. paid) to investigate an issue that is beyond the scope of an "example" app and/or simple usage of the API (http://forums.adobe.com/thread/862191).

So, I guess we are stuck not using screen sharing in our app.

David