"Couldn't find packet detail for the seq nums" after JVB failover

possibly a follow-up to Shutting down a JVB crashes a conference on another JVB

I have a basic setup with 2 JVBs. When testing the failover of a conference between JVBs when one JVB goes down, I’m having issues with video quality of the recovered conference. After a couple of seconds of working fine in HD, It’s goes down to LD and the JVB that is now handling the conference is throwing a lot of these errors:

2021-03-23 11:28:49.344 WARNING: [78] [confId=eaca4c8bf6b8a879 epId=e9129e4d gid=409664 stats_id=Bennie-tUC conf_name=test4@conference.new.OUR-DOMAIN] TransportCcEngine.tccReceived#170: TCC packet contained received sequence numbers: 16930-17117. Couldn't find packet detail for the seq nums: 16930-17117. Latest seqNum was 12434, size is 1000. Latest RTT is 142.020854 ms.

If I refresh a browser window, then that client will be back to normal - received video quality will go back to HD, but only for that client.

I’m using the following package versions:

jicofo=1.0-644-1
jitsi-meet-prosody=1.0.4628-1
jitsi-meet-turnserver=1.0.4628-1
jitsi-meet-web-config=1.0.4628-1
jitsi-meet-tokens=1.0.4628-1
jitsi-meet-web=1.0.4628-1
jitsi-videobridge2=2.1-416-g2f43d1b4-1

If I start a conference with #config.disableSimulcast=true in the URL, the video will work fine after failover. It’s in HD and does not break up in any way.

Can you try with enableForcedReload set true in your config.js ? This should reload the clients automatically and should fix the issue. There is a known issues with Chrome and TCC which makes the client stuck at low BWE when the failover happens.

Unfortunately this option doesn’t seem available for jitsi-meet-web=1.0.4628-1, it seems to have been added in February so it’s probably only in unstable versions.

I was seeing the same issue with JVB failover, and explicitly setting enableForceReload to true did indeed solve the issue. Thanks!

Probably worth pointing out that despite the comments stating that the feature is “enabled by default”, that does not appear to be the case – issue persists until I explicitly set the option to true.

Also, I have disabled Octo and still see the issue so the comments regarding Octo as threw me off course a little.

That said, I am super impressed by how well JVB failover works and how quick and clean the recovery experience is for the end user! Awesome stuff! :muscle:t4:

1 Like

Ahh… I see that comment has already been fixed. :blush: