Steps to reproduce the issue:
Set maxTracks in BandwidthProfile to a lower number than anticipated participants. Use the RemoteVideoTrack.isSwitchedOff to determine if video is on/off. Connect to a room where there's more participants connected than the maxTracks amount. All connected remote tracks are now switched on according to the RemoteVideoTrack.isSwitchedOff flag.
Expected behavior:
When connecting with a defined number of maxTracks in BandwidthProfile I should only get that amount or less of RemoteTracks with video switched on from Twilio.
Actual behavior:
When connecting with a defined number of maxTracks in BandwidthProfile I get all of the RemoteTracks with video switched on from Twilio. The number of tracks with video is then corrected to match maxTracks only after the initial load.
Software versions:
Hello @antonolssonVisiba,
Thank you for writing about this issue. I have one question - when you see this issue do all additional tracks stay switched on for longer periods or are they they just switched on initially and do get switched off later ?
You can use https://media.twiliocdn.com/sdk/js/video/releases/2.7.2/docs/Room.html#event:trackSwitchedOff event to listen for the track switch off state change
Can you please share room-sid for the room where you saw this behavior - If you have any code snippets that can help demonstrate the issue that would be great too.
Thanks,
Makarand
Hello @makarandp0
The tracks are indeed only switched on initially and switches off later. We are already using the trackSwitchedOff event to handle this. My questions is why this happens even though we have explicitly configured the maxTracks to a certain number of Tracks? Is this the expected behavior?
We have resolved the issue by not showing more than the number of tracks defined in maxTracks. However this is only a work around for not being able to trust Twilio to serve us only the asked number of tracks.
Do you need me to get a room-sid to be able to answer the questions above?
Hi,
I'm Jose Santos, Tech Lead for the Media Server team. As a result of the protocols we are using to communicate the state to client there is a design problem causing tracks to not be switched off initially. We are adding this task to our backlog and will work on a redesign in order to avoid this to happen. I can't tell you a time now as it may require a lot of changes that we have to evaluate first.
Thanks for the report,
Jose.
Hey! We've been able to reproduce and fix the situation you described. It may take a few weeks before we can make it available to you. Thanks for your patience.
Hey all,
@jcaden @nicopernas What the status of this ticket?
Sometimes, I receive two instant events switchedOff and then switchedOn for the first load for the switched off video. After some time I can receive the right event again (switchedOff). Then it behaves normally.
I'm using: twilio-video.js: 2.10.0
@jcaden @nicopernas @manjeshbhargav
Hey guys,
any news here?
Hey! Apologies for the silence. I meant to reply to your earlier comment but I clearly missed it.
We've been testing a solution to the original issue for a while now. This took longer than expected to get right. The fix will be made available to you with our next software release cycle (normally every two weeks)
I'll take note of letting you guys know when it's actually released.
Thanks for your patience.
Thank you @nicopernas
Seems like the release contains needed fix https://github.com/twilio/twilio-video.js/releases/tag/2.12.0
I will test this version
Fixed a race condition that sometimes caused switchedOff event for RemoteVideoTrack to not get emitted, which also resulted in wrong value for RemoteVideoTrack.isSwitchedOff property.
@vbabenko that I'm afraid is only fixing one other corner case we spotted during our debugging. The fix you are looking for (which is server side) is ready but still waiting to be released :(
Hey! we have just completed a full rollout of a fix for this issue. It's a bit embarrassing that it took that long but let's say it was a fun one :)
We would really appreciate confirmation that the issue is fixed for you. Thanks
Most helpful comment
Hey! we have just completed a full rollout of a fix for this issue. It's a bit embarrassing that it took that long but let's say it was a fun one :)
We would really appreciate confirmation that the issue is fixed for you. Thanks