Problem with screensharing share screen pop up does not show up

[LordAlex]

Hi,

We tried to run a demo using code provided in the documentation by RIAweek in Ottawa. We essentially did 2 simple MXML apps a Publisher and a Subscriber. Everything was running fine locally, the second we uploaded the example on a web server the share screen addin kicks in but the actual window prompting to display your desktop or app does not show anymore.

We tried running back the same example again locally as we did previously same deal you see the addin app but no share window at all. We rebooted, our machines same deal. Tried different browser like Firefox but nothing seems to work.

I askek someone to run this on windows machine and it works a couple of time but at some point the addin just stops working, same problem we have, they see the addin running but they dotn get actual smaller window to select what to share.

We are running on mac os x latest version, mac book pros but the problem seems consistent in windows as well.

Any ideas?

+LA

[Former Community Member]

Hi there,

I'm pretty sure we handled 1-3 in the last service refresh, in mid-April.

Are you still encountering this problem?

nigel

(For the record, PMing us generally isn't a very good way to get questions

answered, unless you're sending us specific roomURLs or account

credentials.)

[aponnusa]

Hi,

Are you on Win64 machine ?

Thanks

Arun

[DustyHolmes]

Well first, I found that the SDK I had was not the newest. I updated to 1.4.0 and that did not solve the problem. The suggestions by javram did fix my issue. When I attempted to connect to the feature using a guest the addin simply does nothing. This issue was difficult to find as there were no errors of any kind in the logs, in the console, or thrown by the ScreenSharePublisher.

Arun, I was reproducing my issue on OS X and Windows 7 x86.

I believe that a good resolution to my current issue would be to have better errors in the addin for situations where a user can't present. Thank you for the rapid responses.

[aponnusa]

Did you have your rooms auto-promote set to true ?

As javram suggested, we did have bug where guests weren’t able to stream even if their rooms auto-promote was set to true. We did fix it, and guests must be able to screenshare. But the rooms auto-promote setting must be set to true. I am sure you don’t want your app to have dev credentials embedded within.

I would look if I can add more helpful error messages for the scenario you mentioned.

Thanks

Arun

[DustyHolmes]

No, my auto-promote was disabled. After finding and enabling that feature, guest users were able to start a session without issue.

Thanks

Dusty

[Former Community Member]

Hi Guys,

I am still running into issues with the screen sharing popup not displaying under the following conditions:

I am authenticating all users into the room using a C# application and the server-to-server api.

When I put a user into the room initially as the owner (role=100) the connect addin shows and they can share as normal

When I put a user into the room as a viewer (role=10) and then change the user role to owner (role=100) using the room console or the server-to-server api,  the connect addin will not show (it shows in the toolbar, but the modal to select what to share never appears).

Finally,  if I put a user into the room as an owner,  then change their role temporarily to viewer, and then back to owner,  the connect addin shows as expected.

What I suspect is happening, is that their is some setting in the connect addin/screen share publisher that is set upon instantiation of the user being put into the room,  and that value is not being refreshed when the users role is changed, but I have no way to know for sure.

Do you guys have any ideas on this?

Thanks in advance.

[Former Community Member]

Hi There,

In the case where you're promoting the user, is the sequence :

User comes in with role 10

Start sharing

Promoted to 100

No love

or is it

User comes in with role 10

Promoted to 100

Start sharing

No love

I'd expect the former to have issues, but the latter to work, unless there's

a bug we're missing.

nigel

[Former Community Member]

Yes,  unfortunately it is option number 2:

User comes in with role 10

Promoted to 100

Start sharing

No love

I completely understand why option number 1 would not work, and that is the behavior I would expect. The UI we built does not allow it anyways,  we use the userManager.myUserRole property to hide or show the start sharing button, and only show the button when the role is set to 100.

[Former Community Member]

Hi,

Ok, I've found the bug =(. Unfortunately it's on the service, and we just

went through a release cycle. I'm going to see what we can do to expedite a

fix for this issue.

In the meantime, could you try this (yes, odd) workaround and see if it

works for you?

A) Make sure guestsHaveToKnock is set to false (Room Settings in the Console

controls this).

B) Have your user come in with role 5 rather than 10.

This should bring your user in as role 10 (just like you wanted) when all is

said and done. I haven't tested yet, but after you promote the user, this

should cause your screensharing to work.

let me know if this works.

nigel

[Former Community Member]

Yes, that does seem to work,  the wierd thing is that when I specify 5 for the role, they are being listed as a Publisher (which I thought was role=50) in the room console. Is that what you were expecting?

We could probably get by with this as the short term solution  (having folks come in as 50 instead of a 10 and then upgrading them to 100 for sharing instead of the ideal 50),  but long term what we really want to be able to do is have audience members come in as a 10 be elevated to role 50 for sharing, and then when they are done, go back to a 10, and reserve role 100 for only the "true" room moderator.

[Former Community Member]

Hi There,

I'm guessing you have "autoPromote" set to true, which is causing this

behavior. Un-check it from the Room Settings panel, and you should be back

to 10s all around. From there, your workflow should work as you describe.

Definitely a workaround, but it seems to be viable (and will continue to

behave in this way, so you shouldn't need to change it later) - in the

meantime we'll get a fix ready for your initial bug report and ship it with

the next release.

thanks for helping us resolve this - your participation helps a lot!

nigel