Multiple issue with the jitsi modules

[LeRatierBretonnien]

Server : 1 private server, backbone hosted, with Foundry and Jitsi, no bandwidth issue, no CPU issue. Foundry : Version 0.5.4 + WFRP + Jitsi module + Tile Browser + FX + Babele + Pings Players : GM + 1 player in the same house (my wife and me ;), ADSL2+), 3 players remote (2 with ADLS2+, 1 with satellite link). Two players have entry-level laptop. All Chrome.

We started a game session, and as soon as we were 5, we suffered the following issue :

• 1 player was no able to speak, his micro was not detected (see below for more details).
• 1 player (my wife) was not able to join the conference. We all (gm+other players) saw her widget, she saws our widgets, but she received no sound and no video, and we were not able to hear her.
• Then players started to get randomly disconnected.

As we were in a game session, we did not spent time to debug in deep, so we switched to my previous solution, which is using directly the Jitsi server inside a second tab of the browsers of all players/gm. With this solution, everything runs fine, without major issue on audio/video side, during 4 hours.

My guess and potential ideas :

• The issue is not related to the server itself as it was monitored during all the game. The Jitis server is the same between the Foundry module and the "direct" access, so i think that we can definitively remove this option, as it was working in "direct" access mode.
• The micro issue seems to me really related to the interfacing between Foundry <-> Jitis module. In the same browser, as soon as the player opens a new tab to access directly the Jitsi conference room, it was working automatically.
  • For the loss of connections, if begin to think that this is a CPU usage problem on players side, because the issue started as soon as the 2 players with entry-level laptop joined the game. But it impacts all players then. In that case, i suspect that running Foundry+Jitsi (or maybe any WebRTC stuff) in the same tab (-> same Chrome process) leads to performance problem, hence dropping packets or loosing connections.

I will try to debug this separately,i will let you know my findings. If you need more information that i might have been forgotten, let me know :)

[luvolondon]

Hey, thank you very much for your in detail feedback. The 2nd tab workaround really rules out many of the common problems with connections, the server etc. So you had no problems with the conference with all five players in the 2nd tab, right? If that worked well I think we can also rule out general CPU load caused by the WebRTC technology.

I think the cause is in the way incoming remoteTracks are handled by the module:

if (client._remoteTracks[participant].length >= trackcount) {
  if (ui.webrtc && (ui.webrtc._state == 1)) {
    setTimeout( function() { game.webrtc.onUserStreamChange( userId,client.getRemoteStreamForId(participant)); }, 1000);    
  } else 
    game.webrtc.onUserStreamChange( userId,client.getRemoteStreamForId(participant));
}

If the UI is currently rendering the CameraViews, the refresh is postponed for 1 second. On a slow system this value might be too low and cause problems. I´ll try to postpone the refresh in a more adaptive way.

[LeRatierBretonnien]

About the CPU, i am not sure. Chrome launches 1 process per tab, with a limited amount of thread (2 i suspect). Hence the second tab runs in a separate process, with different timings and resources. So i think we cannot cancel this option right now.

[luvolondon]

I´ve changed the handling of postponing track additions while the UI is rendering. Hope this helps with slower machines.

[LeRatierBretonnien]

I will try !) :) Thanks for you great job in this :)

[bekriebel]

I believe these issues should be resolved with @luvolondon's changes as well as the latest release. If they aren't, please comment with any existing issues and I will re-open the ticket.