Problems with Screen share

Hello guys,

Something happened with the ability of our implementation of lib-jitsi-meet in our AngularJS app.
I was having trouble implementing the screenshare on the first place, but Damiancho helped me a lot and it was working fine. Until like several days ago when I started to see the following problem after connecting and starting a video conference without any problem:

When I try to share a screen after all the checks for installed extensions and so I get this:

  1. On the machine that is starting the screenshare I can see the screen inside my video element, but on the console I get this:
    lib-jitsi-meet.min.js:6 [modules/statistics/RTPStatsCollector.js] <h._processAndEmitReport>: JitsiTrack not found for SSRC 690758671 in TPC[2,p2p:true]

  2. On the other machine which should receive the screenshare track I get this error:
    lib-jitsi-meet.min.js:40 Halt: There are no SSRC groups in the remote description.
    lib-jitsi-meet.min.js:40 Halt: There are no SSRC groups in the remote description.
    lib-jitsi-meet.min.js:6 [modules/statistics/RTPStatsCollector.js] <h._processAndEmitReport>: JitsiTrack not found for SSRC 332587280 in TCP[2,p2p:true]

    (the last line with the error repeats every second I think)
    And it shows black video track.

After that, even of the first machine stops the screenshare and starts another video track with the camera (which is visible on its interface), the second machine doesn’t get any message and keeps showing the last error every second.

I’m with bound hands so, any help will be highly appreciated.

Thanks a lot in advance,

Hey @gpolitis can this be because of simulcast screensharing?

That’s strange… I don’t think that this particular problem is related to screensharing simulcast specifically, because we always anyway signal simulcast and we haven’t changed that recently.

Could it be that you’re doing something that causes ljm to loose track of its internal state?

This is my init section (part of):

// Connection properties
$scope.jitsi.options = {
hosts: {
domain: ‘’,
muc: ‘’ // FIXME: use XEP-0030
bosh: ‘//’, // FIXME: use xep-0156 for that
// The name of client node advertised in XEP-0115 ‘c’ stanza
clientNode: ‘

Then on clicking of the button I do this:

/* remove local video tracks */
for (let i = 0; i < $scope.jitsi.localTracks.length; i++) {
if ($scope.jitsi.localTracks[i].getType()==‘video’) {
scope.jitsi.localTracks[i].dispose(); (’#spa_userStream_MediaContainer_Local > #localVideo’+i).remove();

// Start Screenshare
JitsiMeetJS.createLocalTracks({ devices: [ ‘desktop’ ] })
.catch(error => {
// handle error

And that’s basically it.
(note: $scope.jitsi is where we place all our jitsi stuff on this particular controller)


p.s. some dollar signs don’t appear due to my inability to format the code section here on this forum.

How are you loading lib-jitsi-meet btw? I want to make sure you’re getting the latest version. The recommended way, according to the lib-jitsi-meet docs, is to use a script tag pointed at I ask because previously you had stated you were going to build the chrome extension but that might not be needed for now, assuming you’re developing on the latest stable chrome or newer.

I’m using
<script type="text/javascript" src="includes/jitsi/lib-jitsi-meet.min.js"></script>

Which I thought is a stable and therefore just placed it inside the project.
Do you think I should use the CDN link instead?


Lib-jitsi-meet doesn’t have versioning so it’d be good to know you’re working on the very latest release. I know there have been some changes in the browser that lib-jitsi-meet is trying to account for and it’d be good to eliminate the lib-jitsi-meet version as a possible source of the problem. I’m guessing Damyan and George are assuming you’re on the latest. I would try the CDN link to see if it fixes your issues. I can’t guarantee it will actually change anything.

Thanks Lenny,

I did try to use the following CDN urls but the result is the same :frowning:

<script type="text/javascript"  src=""></script>
<script type="text/javascript"  src=""></script>

It seems random now.
The problem appears mainly when you’re using Firefox.
All the others seem fine. But when you connect with Firefox, half of the times the other users don’t receive onRemoteTracks callback.
They get new user with all his data, but not the remote tracks for some reason.
On the console you can see:
Halt: There are no SSRC groups in the remote description. index.js:146:8:
(several times)

From time to time though, you get onRemoteTracks callback.
I cannot find any logic under it.
It happens even on a simple example that we took from the repository of the lib-jitsi-meet which you can see here:

Any help will be appreciated.

Attached you can see the console of the Firefox when trying to createLocaltracks


Are you starting the call with no video and then adding the screenshare video tracks?

I just use the example from the lib-jitsi-meet git for our tests.
The result is the same. 2 out of 5 tests (a test is when a firefox user opens the urls and that joins him to the conference) the other participants get onRemoteTracks along with onUserJoin which is great. However on the other 3 of the times, the other participant gets only the onUserJoin callback and not the onRemoteTracks. Looks like the Firefox is not sending the remote tracks on these 3 cases.
And to answer your question, we are starting with [‘video’, ‘audio’] on all the participants immediately (as the example is).


Here is more detailed explanation on the issue.
I’m using lib-jitsi-meet example here:

When you use Firefox and you join with video - everything is fine. When you sharescreen (by clicking the switch Video link) it also works as expected, but then, when you click switchVideo again to go back to the camera, the opposite user doesn’t seem to get a remoreTrack for the camera and therefore sees nothing.
No errors on the console (just a Halt: message).

Any help will be highly appreciated.


Have you tested same scenario with, does it work?

I think you are hitting one long standing bug with Firefox, if you start with video muted, you never receive video(I think it was …). Why I think, this is the same, as you are destroying the tracks… and the video track description becomes recvonly and then it state in the bridge never changes to sendrecv. Can you try replacing them?

So, when someone approaches us with similar question about lib-jitsi-meet we will always first ask, does it work with we didn’t ask it earlier :stuck_out_tongue: which is a miss)?
Currently the only usecase we have is: jitsi-meet is using lib-jitsi-meet. If it works, then the next step is: check how it is done there. So here is the toggleScreenshare handling:

@damencho Thank you very very much.
Using replaceTrack the way you showed me made the trick and it all works well now.

Again Thank you and all the others for the support.


I have a similar behavior: when joining a room with the local video enabled, the remote participant will see the video. but if the remote joins without local video enabled, the remote participant does not see the video.
Remote gets TRACK_ADDED/TRACK_REMOVED events and the video element has autoplay=‘true’, but still no video.

If matters: The local participant’s track is disposed(), then on next createLocalTracks() the video is added to the room. So, I cannot use replaceTrack(oldTrack, newTrack). I do not use screen sharing, only trying to enable/disable video/audio at the moment.

console logs:
Halt: There are no SSRC groups in the remote description.
Imploding SIM group: 4126571993 1741511522 402379823

Fixed by following the hint of @AymericG in this post: