Screen Sharing Stop frequently, when call is longer than 30 mins

[vijayamin83]

Hello Support Team,

We are using the following classroom application with the customisation at the design level. Overall, application work well, but at the some lever when call is longer, screen sharing stopped and behave randomly.

https://github.com/aws-samples/amazon-chime-sdk-classroom-demo

I think it's memory or cpu usage increasing.

So, Can you please suggest on this?

[simmkyu]

Could you provide us with the following information? We can check whether the attendee experienced any network drop event.

• Meeting ID
• Attendee ID
• INFO-level logs

[devalevenkatesh]

Closing this issue due to in-activity, please feel free to re-open if you still face the issue but request you to please provide above request information for debugging.

[vijayamin83]

No, I am on the high speed internet. And testing through different system.

[vijayamin83]

And this problem happen in the prod build, so, could not able to generate the log even.

[tindevelopers]

Is it possible to re-open this issue? It's not an issue of network connectivity, because the meeting is on and continues to be active.

[tindevelopers]

90% of the time, the screen share works fine for the first time, but 1 out of 10 times, when the screen share is stopped and then started again, and appears to be working i.e. it looks like it is working for the originator, but the other participants cannot see the screen share. We can’t seem to figure out how to troubleshoot this problem.

[simmkyu]

Content sharing (screen sharing) in the Chime SDK for JavaScript is no different from regular videos, except that an attendee can share screens or any MediaStream.

For example, when Attendee A enables screen sharing, a content-sharing attendee (non-human) joins a meeting and shares Attendee A's screen over the same WebRTC connection on behalf of Attendee A. i.e., This content-sharing attendee internally uses the same meetingSession.audioVideo.startLocalVideo API to stream screen.

⠀

it looks like it is working for the originator, but the other participants cannot see the screen share.

Often, the originator should not see the screen if other attendees cannot see the screen because the originator is also a viewer of the content-sharing attendee's video.

⠀

We can’t seem to figure out how to troubleshoot this problem.

When this bug occurs, can you share the meeting ID? The Chime SDK team can check if the Chime server logs provide any information.

Also, Chime SDK INFO-level logs from these attendees will be helpful.

• The originator who shares screen
• An attendee who cannot see the originator's screen

[tindevelopers]

Yes, we will monitor and send over the meeting ID. Will be updating to the latest SDK make a difference, and are there multiple ways or other ways to share a screen?

[simmkyu]

Will be updating to the latest SDK make a difference, and ...

Which version of the Chime SDK for JavaScript are you using? We have improved video APIs in the last few versions (CHANGELOG). Some of which will be applicable for content sharing since a local video and screen share use the same video API.

⠀

and are there multiple ways or other ways to share a screen?

No. The Chime SDK for JavaScript only offers the content sharing API to share a screen.

meetingSession.audioVideo.startContentShareFromScreenCapture

[tindevelopers]

This is the meeting ID: 2d5e5910 The error happened about halfway into the call @ about 16:14 Paris Time CET, after screen sharing 2 times, the 3rd time seemed to have failed.

[jing-chen1]

Hi @tindevelopers,

The format of the meetingID is not correct. Could you provide something like 92d2ab67-c207-42a9-ab9a-dca25ba60706?

[vijayamin83]

Hello @jing-chen1

this is the correct meeting ID: f9673e6-34f2-463b-9b79-e95703080706 for above meeting

Please check.

[jing-chen1]

The meeting ID may not be correct. Your meetingID is one digit less than the example meetingID, so I can not find any data in our server.

Example: 92d2ab67-c207-42a9-ab9a-dca25ba60706 Yours---: f9673e6-34f2-463b-9b79-e95703080706

[vijayamin83]

Hello @jing-chen1

{ "ClientRequestToken": "845e2097-62e3-4080-bf71-1df23e8bfe57", "MediaRegion": "us-east-1", "NotificationsConfiguration": { "SqsQueueArn": "arn:aws:sqs:us-east-1:XXXXXXXXXXX:roomzzconnect-MeetingNotificationsQueue-1JM1A8SN2MQ18" }, "MeetingHostId": "6133fe57-0ac7-4ec7-89ed-12278390880a#Gene" }

Please find the response of the create meeting API, Let me know if it's helpful or not

[vijayamin83]

Meeting ID1: dd7a9b1d-02e5-4825-808d-b80eb5d70706 Meeting ID2: 1d57c785-fbaa-498d-8a56-617a9ae80706

Thanks

[tindevelopers]

Meeting ID2: 1d57c785-fbaa-498d-8a56-617a9ae80706

[simmkyu]

@tindevelopers Thanks for sharing the meeting ID.

Chime SDK server logs

Chime SDK server logs for the meeting ID: 1d57c785-fbaa-498d-8a56-617a9ae80706

Content sharing-related events in bold

• Attendee A (1st attendee) and Attendee D (4th attendee) enabled screen sharing.
• For some reason, the Attendee A's screen sharing immediately stopped at 08:47:07 (PST).
• Attendee D shared the screen for about 40 minutes.
• However, Chime server logs do not have any drop event for all four attendees. A drop event often occurs when an attendee has an unstable internet connection.

Time (PST)	Attendee	Action
02/06/22 08:01:58	Attendee A	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.
02/06/22 08:01:59	Attendee A	Called the meetingSession.audioVideo.start API.
02/06/22 08:02:00	Attendee A	Successfully joined the meeting.
02/06/22 08:19:34	Attendee B	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.
02/06/22 08:19:35	Attendee B	Called the meetingSession.audioVideo.start API.
02/06/22 08:19:36	Attendee B	Successfully joined the meeting.
02/06/22 08:20:05	Attendee A	Started a local video
02/06/22 08:34:31	Attendee C	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.
02/06/22 08:34:31	Attendee C	Called the meetingSession.audioVideo.start API.
02/06/22 08:34:32	Attendee C	Successfully joined the meeting.
02/06/22 08:34:59	Attendee C	Started a local video
02/06/22 08:47:07	Attendee A	Started screen sharing
02/06/22 08:47:07	Attendee A	Stopped screen sharing
02/06/22 08:47:25	Attendee A	Left the meeting
02/06/22 08:47:32	Attendee D	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.
02/06/22 08:47:32	Attendee D	Called the meetingSession.audioVideo.start API.
02/06/22 08:47:34	Attendee D	Successfully joined the meeting.
02/06/22 08:48:01	Attendee D	Started a local video
02/06/22 08:48:23	Attendee D	Started screen sharing
02/06/22 08:52:14	Attendee D	Stopped screen sharing
02/06/22 08:52:22	Attendee D	Started screen sharing
02/06/22 09:06:55	Attendee C	Started a local video
02/06/22 09:26:46	Attendee C	Started a local video
02/06/22 09:26:56	Attendee C	Started a local video
02/06/22 09:35:09	Attendee D	Stopped screen sharing
02/06/22 09:36:50	Attendee C	Started a local video
02/06/22 09:36:52	Attendee B	Left the meeting
02/06/22 09:53:14	Attendee D	Left the meeting
02/06/22 09:53:24	Attendee C	Left the meeting

⠀

Questions

... but 1 out of 10 times, when the screen share is stopped and then started again, and appears to be working i.e. it looks like it is working for the originator, but the other participants cannot see the screen share. We can’t seem to figure out how to troubleshoot this problem.

• Attendee D disabled screen sharing at 08:52:14 (PST) and enabled it again at 08:52:22 (after 8 seconds). Is there any chance that the originator (or the client application) stopped content sharing so other attendees do not see the screen?

• What are the symptoms when screen sharing stops frequently? e.g., flicking, black screen.

• Chime SDK server logs do not show any error or drop event for the attached meeting ID. Can you please share Chime SDK INFO-level logs of the "viewer" attendee when they fail to view screen sharing? I wonder if they experience an intermediate bandwidth issue because screen sharing's data size is bigger than regular videos.

[simmkyu]

Chime SDK server logs for the meeting ID: dd7a9b1d-02e5-4825-808d-b80eb5d70706

• Attendee D toggled screen sharing three times at 07:25:49, 07:33:18, and 07:44:02 (PST). Could you check if your frequent stop events match these time?
• Other than that, this meeting ID shows the same behaviors as in another meeting ID: 1d57c785-fbaa-498d-8a56-617a9ae80706 Please see the previous comment for more details.

Time (PST)	Attendee	Action
02/06/22 06:49:02	Attendee A	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.
02/06/22 06:49:03	Attendee A	Called the meetingSession.audioVideo.start API.
02/06/22 06:49:04	Attendee A	Successfully joined the meeting.
02/06/22 06:51:59	Attendee B	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.
02/06/22 06:52:00	Attendee B	Called the meetingSession.audioVideo.start API.
02/06/22 06:52:00	Attendee B	Successfully joined the meeting.
02/06/22 06:52:11	Attendee B	Started a local video.
02/06/22 06:52:11	Attendee A	Started a local video.
02/06/22 06:55:33	Attendee B	Stopped a local video.
02/06/22 06:55:33	Attendee B	Left the meeting.
02/06/22 06:56:00	Attendee C	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.
02/06/22 06:56:01	Attendee C	Called the meetingSession.audioVideo.start API.
02/06/22 06:56:01	Attendee C	Successfully joined the meeting.
02/06/22 06:56:19	Attendee C	Started a local video.
02/06/22 07:23:02	Attendee A	Started screen sharing.
02/06/22 07:23:02	Attendee A	Stoppped screen sharing.
02/06/22 07:25:08	Attendee A	Stopped a local video.
02/06/22 07:25:08	Attendee A	Left the meeting.
02/06/22 07:25:15	Attendee D	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.
02/06/22 07:25:16	Attendee D	Called the meetingSession.audioVideo.start API.
02/06/22 07:25:17	Attendee D	Successfully joined the meeting.
02/06/22 07:25:49	Attendee D	Started screen sharing.
02/06/22 07:30:17	Attendee D	Started a local video.
02/06/22 07:32:15	Attendee D	Stoppped screen sharing.
02/06/22 07:33:18	Attendee D	Started screen sharing.
02/06/22 07:36:07	Attendee D	Stoppped screen sharing.
02/06/22 07:44:02	Attendee D	Started screen sharing.
02/06/22 07:54:33	Attendee D	Stoppped screen sharing.
02/06/22 07:54:33	Attendee C	Stopped a local video.
02/06/22 07:54:33	Attendee C	Left the meeting.
02/06/22 07:54:36	Attendee D	Stopped a local video.
02/06/22 07:54:36	Attendee D	Left the meeting.

[tindevelopers]

I am ATTENDEE "A" and the one who is starting the screen, sharing and as I see the logs, it looks like something stops the screen sharing as soon as it is started.

First Break in Failure.

02/06/22 08:47:07	Attendee A	Started screen sharing
02/06/22 08:47:07	Attendee A	Stopped screen sharing

Second Break

02/06/22 07:23:02	Attendee A	Started screen sharing.
02/06/22 07:23:02	Attendee A	Stoppped screen sharing.

There is Little to NO chance that I purposely or accidentally manually stopped the screen sharing at the exact same second I started it. I am wondering if something is causing an instantaneous double click on the front or back end. We are using REACT NATIVE and Electron. Is there a way that when the screen share starts, we could prevent for a few seconds a second click to stop it.

@vijayamin83, because the UX breaks simultaneously, perhaps this is what is causing this problem.

This helps because at least we now know that something is causing the screen share to stop.

Regards

[tindevelopers]

Attendee D toggled screen sharing three times at 07:25:49, 07:33:18, and 07:44:02 (PST). Could you check if your frequent stop events match these time?

This is actually ATTENDEE A, rejoining back, so these are real meetings and the workaround when the screen fails, is to leave the meeting as the Host, and rejoin as a normal attendee so we can continue with our meeting. Once we re-join, then we can once again screen share in the meetings.

You can see below the exit and immediate reentering the meeting:

02/06/22 08:47:25	Attendee A	Left the meeting
02/06/22 08:47:32	Attendee D	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.

02/06/22 07:25:08	Attendee A	Left the meeting.
02/06/22 07:25:15	Attendee D	Created with CreateAttendee, BatchCreateAttendees, or CreateMeetingWithAttendees API in your server application.

This process of leaving and re-joining takes about 7 seconds, and then we continue the meeting without host privileges.

[simmkyu]

I am wondering if something is causing an instantaneous double click on the front or back end. We are using REACT NATIVE and Electron. Is there a way that when the screen share starts, we could prevent for a few seconds a second click to stop it.

In the meeting 1d57c785-fbaa-498d-8a56-617a9ae80706, Attendee A started content sharing and ended it in 700 ms. Here's a table including timestamps with milliseconds.

Time (PST)	Attendee	Action
08:47:07.089	Attendee A	Started screen sharing
08:47:07.785	Attendee A	Stopped screen sharing

⠀

Chime SDK does not offer any backend API to start or stop content sharing, so Attendee A (or the client application logic) might have called meetingSession.audioVideo.stopContentShare() on the client side.

Chime SDK INFO-level logs for Attendee A will be helpful to troubleshoot the issue further.

[vijayamin83]

Hello Support Team,

Can you please check the log for this meeting id: ee6dcbf3-f935-4ee9-8bb9-604fff980706

The Problem with this meeting id is, even I stop the screen share, it keep changing the screens on the another machines.

Thanks,

[LeviSklaroff]

Could you clarify what you mean by "it keeps changing the screens on the another machines" are you continuing to see the screen share after its been disabled? Looking through the logs I found there were 58 cases that screen share was started, and out of those 58 there were 51 cases where the other attendee was able to view the screen, 6 of these cases the screen share ended instantly like in above cases before the other attendee could view the screen, and in one case there was not attendee to view the screen.

[tindevelopers]

He means that on the host machine, when screen sharing is "stopped", the target machines continue to see the screen being shared, and the host who is sharing the screen has no way of stopping the screen share unless he exits the session or another person on the conference starts sharing their screen, taking control of the screen sharing channel.

[LeviSklaroff]

Looking at the logs and backend all instances of content share had a stop event trigger.

• Is this issue occurring in all instances of sharing your screen? Or is it similar to your issue where screen sharing instantly stops 1/10 times?

• I found one case where Attendee B started sharing their screen and then Attendee C started sharing their screen which caused Attendee B to stop. Is this an instance of the bug? In this case it looks like meetingSession.audioVideo.stopContentShare() was never called

Time (PST)	Attendee	Action
02/28/22 22:20:41	Attendee B	Started screen sharing
02/28/22 22:20:52	Attendee C	Started screen sharing
02/28/22 22:20:54	Attendee B	Stopped screen sharing

[tindevelopers]

Is this issue occurring in all instances of sharing your screen? "NO" Or is it similar to your issue where screen sharing instantly stops 1/10 times?

I found one case where Attendee B started sharing their screen and then Attendee C started sharing their screen which caused Attendee B to stop. Is this an instance of the bug? In this case it looks like meetingSession.audioVideo.stopContentShare() was never called

THAT IS OK, WHEN SOMEONE STARTS TO SCREEN SHARE, IT AUTOMATICALLY STOPS THE PERSON WHO IS ALREADY SCREEN SHARING.

[vijayamin83]

Hello Support Team,

Can you please debug the log for the following meeting ids:

1. 3e803317-7d26-4ce1-8b69-3ca770dc0706
2. d4f8a74c-2ae9-4c84-9129-84c4e7630706

It just not allowing the start screen share until I restart the application again.

When I debug, I found that following code ` try { setViewMode(ViewMode.ScreenShare); setGlobalVariables('attendeeIdFullScreen', '') setGlobalVariables('tileView', false)

                setIsPickerEnabled(false);
                await chime?.audioVideo?.startContentShareFromScreenCapture(
                  selectedSourceId
                );
                // set sream id to small view while screen share on in small window
                setSelectedSourceId(selectedSourceId);
                // setGlobalVariables('attendeeIdFullScreen', "");                      
                // localStorage.setItem("screenshare_", "true");

                } catch (error) {
                  // eslint-disable-next-line
                  console.log(error);
                  await stopContentShare();
                }

`

In Try condition there is something wrong.

[vijayamin83]

Hello Support Team, Can you please revert on this?

[devalevenkatesh]

Going through the discussion, I have few suggestion to check further below:

1. Could you check whether you implement hiding of video elements when you get a tile state update in videoTileDidUpdate as well as if you implement videoTileWasRemoved? videoTileDidUpdate on the remote side will give you whether a <attendeeId#content> tile is updated and if is not active anymore. Thus suggesting to check and handle this case in videoTileDidUpdate.

2. I suggest reproducing this issue with the Amazon Chime SDK for JavaScript browser meeting demo. In the demo, we implement both the observers and hide the non active video elements. Source. I tested starting the content share and then stopping that on local side which also stopped it on the remote side.