This message was deleted.

Now I am aware that Case 2 isn't a good practice and I wouldn't do that it's just interesting that there is a difference in the behavior of the 2 cases.

From previous experience with users who would create tracks manually, we decided that the safe bet is to leave the mediastreamtrack lifecycle to the integrating user. This means livekit will do as little as possible to that mediastreamtrack - including not emitting certain events that would indicate that LiveKit is in control of the track. Have you tried if setting the

userProvided

boolean to false helps in your case? https://docs.livekit.io/client-sdk-js/classes/LocalVideoTrack.html#constructor Regarding your observation between revoking permissions and calling track.stop() manually - that’s indeed interesting. Can you open an issue on github about it? As you said, we wouldn’t expect users to call the stop method manually in most cases, but it’s still quite surprising.

Can you open an issue on github about it?

Will do

Have you tried if setting the

userProvided

boolean to false helps in your case?

When using

LocalParticipant.publishTrack()

the

userProvided

flag is automatically set to

true

I can set it to false when calling

replaceTrack

later for a test but generally I don't want to do this as this will try to access UserMedia later on.

From previous experience with users who would create tracks manually, we decided that the safe bet is to leave the mediastreamtrack lifecycle to the integrating user.

I partially agree, however I do think it's correct to mute the track on the `end`event because there is no way this track will be valid again

I partially agree, however I do think it’s correct to mute the track on the `end`event because there is no way this track will be valid again

yeah, that sounds reasonable. I’ll take a look whether changing it to additionally mute the track would potentially break things. For a workaround until then, you could listen to

ParticipantEvent.UpstreamPaused

which will get emitted on

ended

also for user provided tracks.

Yes what I'm seeing now is that when I revoke the camera rights the

localTrackPublication.isUpstreamPaused

will go to

true

however if I manually stop the track it will stay

false

thanks for the event hint, I didn't see it right away as it's @internal

hmm, is the

TrackEvent.Ended

fired when you manually stop the track? or the

ended

event on the mediastreamtrack itself?

let me check

aha, mdn says:

Immediately after calling

stop()

, the

readyState

property is set to

ended

. Note that the

ended

event will not be fired in this situation.

yes I just realized the same thing, the event isn't triggered