Failed to restart or rejoin a meeting after upgrading to 7.1.0 on Linux

Meeting SDK
1

Meeting SDK Type: Linux-x86_64 and Version: 7.1.0.4100

Description
Re-joining and Re-start a meeting failed when the current instance had already joined/started and left a meeting.

Error?
After getting MEETING_STATUS_CONNECTING in onMeetingStatusChanged(), I got MEETING_STATUS_DISCONNECTING and then MEETING_STATUS_FAILED with iResult MEETING_FAIL_MMR_ERR. I have to restart my app to make it work again. But before upgrading it from 6.3.5 to 7.1.0, it was working fine.

Troubleshooting Routes
There is no errors when start/join at the first time and no error when leave the meeting and cleanup successfully

Could you let me know what does this error MEETING_FAIL_MMR_ERR mean? What procedure could I miss? Thank you!

2

@Ross_Video it would be super helpful you can capture the SDK logs and share it with me.

3

Thanks for reply, Chun! Sure, please check logs here: Logs - Google Drive

4

@Ross_Video , thanks opening a ticket internally, I’ll update you again next week. Ping me if you don’t hear from me

ZSEE-207699

5

Hi, @chunsiong.zoom , do you have any update by any chance?

6

@Ross_Video ,

We are still investigating this, meanwhile there is a workaround provided for 7.1.0.

Do not call CleanUPSDK after leaving the meeting. Here’s the expected flow for this workaround:

  1. InitSDK

  2. Join meeting

  3. Leave

  4. Join meeting

  5. Leave

…

Finally: Call CleanUPSDK when the client app exits.

7

Thank you, @chunsiong.zoom . We tried the workaround today but met some problems as well :sweat_smile:

We already follow that InitSDK / CleanUPSDK lifetime:

  1. Call InitSDK() once when the process starts (or on first meeting).
  2. Join meeting → works.
  3. Leave meeting → works.
  4. Join a second meeting in the same process without calling CleanUPSDK().
  5. Call CleanUPSDK() only when the client app exits.

Between leave and the second join, we destroy and recreate the services (DestroyAuthService / DestroyMeetingService, then CreateAuthService / CreateMeetingService again). We do not call CleanUPSDK() between meetings.

On step 4 we tried two approaches:

A. Call SDKAuth() again before the second join

  • SDKAuth() is invoked.
  • onAuthenticationReturn() is never called.
  • So we never proceed to Join().

B. Skip the second SDKAuth() and call Join() directly (assuming auth from the first meeting is still valid)

  • onMeetingStatusChanged() is called.
  • We only receive MEETING_STATUS_CONNECTING.
  • We never get a later status such as MEETING_STATUS_INMEETING, MEETING_STATUS_FAILED, or MEETING_STATUS_ENDED.

Questions for you:

  1. After leave, should we keep the same IAuthService / IMeetingService instances for the next join, or is destroy/recreate supported?
  2. For the second join in the same process, should we call SDKAuth() again, or only Join()?
  3. If SDKAuth() should be called again, why would onAuthenticationReturn() not fire on Linux after the first successful auth?

Many thanks!

8

@Ross_Video this will be fixed in the upcoming release. Meanwhile if the workaround doesn’t seem ideal, it might make sense to use a last known good version such as 6.3.5 while waiting for the upcoming release dix.

9

Got it, thank you so much! Looking forward to the upcoming release!