TRACK_REMOVED Event Fired Too Late

Description

When disconnecting from a JitsiConnection and opening a new one without refreshing, the HTML audio tag for other users stays in the HTML and gets removed when the TRACK_REMOVED event is fired exactly 16 seconds after the CONNECTION_DISCONNECTED event is fired.

If the disconnecting user decides to join the initial room again in between these 16 seconds, the HTML audio tags of the other users in the initial room gets removed (after the 16 seconds passed), so you are unable to hear anyone else.

Current behavior

Calling the disconnect function of the JitsiConnection and creating a new JitsiConnection with a new Jitsi serviceUrl causes the HTML audio track to be removed 16 seconds after the CONNECTION_DISCONNECTED event.

Expected Behavior

When receiving the CONNECTION_DISCONNECTED event, I expect the TRACK_REMOVED event to be fired as soon as possible. Or, to have a configuration to set the delay between these events.

Possible Solution

• Make delay between CONNECTION_DISCONNECTED event and TRACK_REMOVED configurable.

Steps to reproduce

• Join a jitsi room
• Disconnect from the jitsi room (without reloading the page)
• Join the jitsi room again before 16 seconds pass

Environment details

An environment in which you can dynamically join or leave a Jitsi room is required.

[ckeiner]

I was finally able to try it out. It seems to do the trick or at least show further error messages. They are most likely also related to how we are switching rooms. I will close this issue for now and open new ones should I think I have found another bug.

Thank you very much for the help @saghul 😃

[saghul]

Or do you mean that we first have to call JitisConference.leave() before disconnecting? That is not something we do first. Let me try it out.

Yes, that’s what you should be doing.