getValidRecivedShareSource returns non-zero array after first share is ended

Meeting SDK macOS
1

Description
The getValidRecivedShareSource inside CustomizedRecordingLayoutHelper returns a non-empty array after any user starts and stops sharing.

This is occurring inside the recording layout handler

  • ( void )setRecordingLayoutForHelper:(CustomizedRecordingLayoutHelper *)helper

Which macOS Meeting SDK version?
5.9.6

To Reproduce(If applicable)
Steps to reproduce the behavior:

  1. Launch a meeting as host with custom SDK application (user A)
  2. Join the meeting with the Zoom client (user B)

(lldb) po [helper getValidRecivedShareSource]
<__NSArrayM 0x600001b21d70>(
)

NOTE: Empty array

  1. Allow user B to share screen
  2. user B starts screen share

(lldb) po [helper getValidRecivedShareSource]
<__NSArrayM 0x600001b21d70>(
0,
16779264
)

NOTE: Contains userID of sharer + a zero entry for some reason

  1. User B stops screen share

(lldb) po [helper getValidRecivedShareSource]
<__NSArrayM 0x600001b21d70>(
0
)

NOTE: Non-empty array.

Device (please complete the following information):
Apple MacBook Pro (13-inch, M1)
12.2.1

Additional context

This causes an issue with the following code:

  • ( void )setRecordingLayoutForHelper:(CustomizedRecordingLayoutHelper *)helper

    // Array of userID’s for the received share sources
    NSArray <NSNumber *> *validRecievedShareSource = [helper getValidRecivedShareSource];

    if (validRecievedShareSource.count > 0) {
    // Assume some user is actively sharing
    } else {
    // No users are sharing
    }
    }

The workaround of course is to check for any zero entries. But I am not sure why there is a zero entry at all after the first share. This is inconsistent because it does not occur before the first occurrence of a share session.

2

Hi @KieranAC,

I was able to reproduce this behavior. We’ll need to investigate and will keep you updated as soon as we have any new information.

Thanks!

3

Thanks. We have a functional workaround for now.

4

Hi @KieranAC,

As it turns out, we have already identified a fix for this issue which will be included in the next SDK release (v.5.10.0).

Thanks!