LocalTrack debounced mute not reset when setting new track

[davideberlein]

Describe the bug

When muting the MediaTrack which was previously added to a LocalTrack and then replacing the MediaTrack using LocalTrack.replaceTrack() with a track which is not muted, the new track is muted after the debounce timeout.
The reason is, that the timeout isn't reset when setting the new track.

Reproduction

Steps to reproduce

• Create a LocalTrack with a custom video track.
• Mute the video track (debounce timeout of 5s is started)
• Call LocalTrack.replaceTrack() with a new active (not muted) track

Expectation:
The new track continues to play

Actual
The new track is muted after a couple of seconds (after the mute debounce timeout is reached)

Logs

No response

System Info

Version 118.0.5993.117 (Official Build) (arm64)
MacBook Pro M1Max

Severity

serious, but I can work around it

Additional Information

I'll open a MR with a suggestion of a fix

[lukasIO]

Hi @davideberlein,
thanks for the report and the PR!

Curious how you are muting the local track. The muted event which triggers the debounce handler is usually not emitted due to the track being manually muted, but rather if the underlying track has issues producing media.
Nevertheless your fix makes sense to me, just curious about the workflow in which you're seeing this issue.

[davideberlein]

This sort of thing happens when you're streaming from a canvas element. We're using this it do background replacement.
When we turn off the camera, we stop the background processing on the canvas and resume it once the camera is enabled again.

I think the muting is some 'weird' side effect of the canvas' stream. It triggers a 'muted' event as soon as it doesn't receive any paint events for a short amount of time anymore and triggers an 'unmuted' event once you start painting into it again.

We had our issues when using OpenTok before LiveKit as well. At some point in time they stopped handling the mute/unmute events when providing a video track off of a canvas. - In your case I think simply resetting the the debounce should be fine.

[lukasIO]

I see, that makes sense, thanks for the context!

[lukasIO]

closed via #936