{"action":"opened","issue":{"url":"https://api.github.com/repos/jitsi/jitsi-videobridge/issues/192","repository_url":"https://api.github.com/repos/jitsi/jitsi-videobridge","labels_url":"https://api.github.com/repos/jitsi/jitsi-videobridge/issues/192/labels{/name}","comments_url":"https://api.github.com/repos/jitsi/jitsi-videobridge/issues/192/comments","events_url":"https://api.github.com/repos/jitsi/jitsi-videobridge/issues/192/events","html_url":"https://github.com/jitsi/jitsi-videobridge/issues/192","id":144068993,"number":192,"title":"Last-n notification broken in certain scenario","user":{"login":"brianh5","id":5933991,"avatar_url":"https://avatars.githubusercontent.com/u/5933991?v=3","gravatar_id":"","url":"https://api.github.com/users/brianh5","html_url":"https://github.com/brianh5","followers_url":"https://api.github.com/users/brianh5/followers","following_url":"https://api.github.com/users/brianh5/following{/other_user}","gists_url":"https://api.github.com/users/brianh5/gists{/gist_id}","starred_url":"https://api.github.com/users/brianh5/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brianh5/subscriptions","organizations_url":"https://api.github.com/users/brianh5/orgs","repos_url":"https://api.github.com/users/brianh5/repos","events_url":"https://api.github.com/users/brianh5/events{/privacy}","received_events_url":"https://api.github.com/users/brianh5/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-03-28T20:01:41Z","updated_at":"2016-03-28T20:01:41Z","closed_at":null,"body":"The repro case I've been using is as follows:\r\n1. Have last-n set to 2\r\n2. Have endpoint A join a call\r\n3. Have endpoint B join the same call.  Media flows between A and B fine\r\n4. Have endpoint C join the same call.  Endpoints A and B will have one frozen video (due to #7 above, the last-n list will only contain the new conference endpoint, endpoint C)\r\n\r\nFrom the code, what happens is:\r\n1. speechActivityEndpointsChanged gets called with an ordered list of all endpoints in the conference\r\n2. it calls speechActivityEndpointIdsChanged with that same list (just with the endpoint ids, not the entire endpoint object).\r\n3. speechActivityEndpointIdsChanged filters out any 'existing' endpoints by calling removing anything from the current list that is already in conferenceSpeechActivityEndpoints\r\n4. speechActivityEndpointIdsChanged calls update with that filtered list (just the new endpoints)\r\n5. update calls \"newForwardedEndpoints = orderBy(newConferenceEndpoints, conferenceSpeechActivityEndpoints);\".  Which means newForwardedEndpoints only contains endpoints that were in newConferenceEndpoints [the loss happens here...we're trimmed the list of forwarded endpoints to only what was in the newConferenceEndpoints]\r\n\r\n\r\nThe hack I've thrown together to fix this is to remove  \"newForwardedEndpoints = orderBy(newConferenceEndpoints, conferenceSpeechActivityEndpoints);\" call in update, so we don't improperly trim the active speaker list.  Not sure if that breaks other functionality.\r\n\r\ncc @bgrozev "}}