Implement removestream, removetrack events

[t-mullen]

These events were disabled due to a lack of a reliable way to detect media removals and correlate them with streams provided by the stream and track events.

They should be re-added to allow peers to observe remote stream removals.

peer.on('removestream', cb)
peer.on('removetrack', cb)

[nielsswinkels]

Any progress yet? Would be great to have indeed.

[sahiljain2497]

Yes this would be great!
Right now i have to fire an additional event to hide/remove track from ui of the receiver.
Any other better ideas as per current scenario?

[vbabenko]

Have the same problem.
I send an additional event when the stream removed. It would be great to have such events

[ted-piotrowski]

The mute event is a good workaround for the lack of a removetrack event.

link.on('track', (track) => {
    console.log('track added');
    track.addEventListener('mute', () => {
        console.log('track removed')
    });
});

[fictorial]

@ted-piotrowski isn't that only going to fire for the local stream?

localStream.getAudioTracks()[0].enabled = false

does not trigger this on a remote peer:

  peer.on('track', (track, stream) => {
    track.addEventListener('mute', () => {
      // TODO update UI
    });
  });

FWIW I'm sending the mute/unmute events out of band using the signaling server I have as a workaround.

[ted-piotrowski]

@fictorial The mute event fires on the remote peer for me (Latest Chrome/MacOS) 🤷 However, the mute event can't be used to infer if a track has ended because mute event gets periodically emitted when a peer can't stream data fast enough and unmute is emitted when data comes through again. I am also sending a trackRemoved event now, but using the simplepeer data channel instead of a signaling server. Would be a nice addition to have a removeTrack event.

[matallui]

Any traction on this yet? If not, any pointers on how this should be properly implemented? Happy to submit a PR.