Viewer device receives 0x0 video dimensions in onVideoTileAdded from second content share onward

[vuht1014]

Hi AWS Chime team,

We're running into a persistent issue only on Android where the viewer fails to receive valid video data when content sharing is restarted multiple times from another device.
🧪 Scenario:

• Device A (sharer): Starts content share

• Device B (viewer): Receives onVideoTileAdded with:

  videoStreamContentWidth = 1280
  videoStreamContentHeight = 550
  pauseState = Unpaused
  

  → ✅ Everything works fine on the first content share.

• Device A: Calls stop share, then starts sharing again

• Device B (viewer) receives new onVideoTileAdded, but this time:

videoStreamContentWidth = 0
videoStreamContentHeight = 0
pauseState = PausedForPoorConnection

🛑 This problem occurs consistently from the second share onwards. The stream does not display,

🔍 Additional Notes:

• The sharing device logs show no errors — startContentShare works fine again
• The viewer receives a new tileId, so the tile is recreated — but with invalid dimensions
• The pause state is reported as PausedForPoorConnection, but the network is stable
• This is not a rendering/view bug — the tile dimensions are already 0 in the VideoTileState returned by the SDK
• Restarting the Chime session on the viewer device fixes the issue, but that's not a viable workaround

📦 SDK Versions:

chime_sdk: "0.18.3"
chime_sdk_media: "0.18.3"

❓Questions:

• Is this a known issue in the Chime Android SDK where viewers fail to receive valid video data after multiple content share restarts?
• Does the viewer need to reset or unbind anything between content share sessions?
• Is there an internal tile state on the viewer side that might not be cleaned up correctly?
• Any recommended way to force tile state refresh on the viewer without restarting the whole meeting session?

Thanks in advance for your support!

[linsang21]

Is this a known issue in the Chime Android SDK where viewers fail to receive valid video data after multiple content share restarts?

No, restart should work consistently as the first one. Are you able to reproduce using the Chime SDK demo app in the repo?

Does the viewer need to reset or unbind anything between content share sessions?

When the first content share stopped, have you unbind the stopped video tile? If not, could you try that?

Is there an internal tile state on the viewer side that might not be cleaned up correctly?

Only clean up on the viewer side should be done through the unbinding the unwanted video tile.

Any recommended way to force tile state refresh on the viewer without restarting the whole meeting session?

Restarting the meeting session should not be required for such use case. Some suggestions:

1. Use latest version of SDK
2. Reproduce the issue using demo app in the repo and record the steps
3. Provide verbose client logs