https://livekit.io logo
Join Slack
Powered by
This message was deleted.
# helpdesk
s
This message was deleted.
👀 1
❤️ 1
w
We also experience this issue with flutter when using the fast connection option. When people enter the room with muted camera (and if we stop() or dispose() the localVideoTrack stream to soon it will be black), the light will stay on forever.
f
Thanks for your detailed feedback 🙏, I will fix it
🥳 1
w
@wide-shoe-67933 you can use the above code I provided to circumvent that. Thats the fix
Until its fixed on livekit
No problem @freezing-lifeguard-43174 glad it helped
So @wide-shoe-67933 dont create the audio and video track if they enabled value is false. For now until its fixed
w
@worried-leather-93857 hmm, i'll look into it
w
Also if you do connect with them aka you create the tracks you will have to .dispose() them
As currently only room.dispose is not enough
w
We are doing that, but when we do, we are getting black screens and whatever. But this issue is not really a major problem for us. I just wanted to highlight that we also experienced the same thing 🙂
But i'll check out your fix and see if we can use it until the issue is fixed
w
Ah thats a different issue from this one then
Im not getting any black screens
w
but I still think its connected to pre-join and fast connect
w
What is connected
w
related* would have been a better word to use instead of connected 😄
w
I dont connect to the room in the prejoin
Thats a bad thing to do thay the flutter example app does
I connect to the room in the room screen
w
we do that as well
w
Theb when you navigate away from prejoin
Or wait if you navigate to prejoin and navigaye back to wherever expect the call do you still have the redballs
If you dont then the issue in your call screen itself
w
the only thing we do is create localVideoTrack in pre-join, navigate to call screen, join with fast-connect. This works great, but if we do the same thing but mute before connecting, the light will stay on forever.
w
Or well in your provider/bloc thst the call screen uses assuming youre using state management
w
and if we dispose/stop the track ourselves we get black screens once we are in the call
w
Okay yeah then in that case dont create a localVideoTrack if you navigate with the light on
And by creating I mean dont assign any value to the _localVideoTrack LocalVideoTrack?
Ooh dont dispose it until you close the screen. If you want to stop you need to add an argument to room.connect that allows you to stop tracks
I dont remember the argument name needed for stopping tracks
w
even if we dispose/stop it AFTER we have connected to the room. They turn black.
w
Dont do those things
w
so how should I turn off the light, the only reason to do that is with dispose/stop, no?
But I feel like livekit need a better implementation for handling the whole pre-join/lobby experience. But I also know that they are working on it (y)
w
To turn it off while in call setCameraEnabled(false)
To turn it off if you joined with fast connect and you created the tracks. Dispose the tracks
To turn it off if you jooned with fast connect and joined with argument cameraOff dont create the track
Yeah youre right. Livekit needs to fix the room cleanup flow
And correcrlt assign the fasttracks to participant even if enabled:false
Then no disposing of tracks are needed either as room.dispose disposes the localparticipant as well
w
Yeah, exactly!
f
hey @worried-leather-93857 created PR for this issue, https://github.com/livekit/client-sdk-flutter/pull/425
w
Aight imma check it out tomorrow or sunday. Thanks @freezing-lifeguard-43174 ❤️
This fix alone is not enough to fix it seems @freezing-lifeguard-43174
It seems that with these changes even if enabled = false it will publish the track
and you can actually see the video of that participant even if he had 
TrackOption(enabled: false, track: _videoTrack)
The issue is somewhere in the call path of room.connect
hmm its very hard to debug for me
I notice that 
Engine.connect
accepts 
fastConnectOptions
but never uses them 🤔
I notice that issue is even in 
LocalVideoTrack.createCameraTrack
since if you connect without 
fastConnectOptions
the redball will still be there even if you dipose the track wheb closing the page.
f
Then the issue is that track is created from LocalVideoTrack.createCameraTrack. If it is not referenced, it must be manually dispose.
Did you find steps that you can quickly reproduce? I’ve tried a few methods that seem difficult to reproduce.
w
Even if you dispose that track manually the redball will still be there
and it is references in the fastConnectOptions. But anyhow the issue with the fix you made on the MR is that even if you do 
TrackOption(enabled: false, track: _videoTrack)
it wont care about the 
enabled:false
and will publish the mic
because it will publishAudioTrack, publishVideoTrack etc
You can try reproducing in the prejoin branch I guess not sure
f
and it is references in the fastConnectOptions. But anyhow the issue with the fix you made on the MR is that even if you do 
TrackOption(enabled: false, track: _videoTrack)
it wont care about the 
enabled:false
and will publish the mic
because it will publishAudioTrack, publishVideoTrack etc
Yeah, I changed it to this intentionally. If you don’t want to publish you should use 
TrackOption(enabled: false)
, otherwise you can use 
TrackOption(track: _videoTrack)
for quick publish
w
But you cant do 
TrackOption(enabled: false, _videoTrack)
? At least it produces bad out comes with those changes
f
There are several fastConnect processing methods for if enabled == false, track != null 1. After the room is connected, call track.dispose internally or manually call track.dispose externally to close this track. 2. Store the track inside the room until it is destroyed when the room disposes, or directly reference this track when setCameraEnabled is enabled. This method will cause the red ball to still light up even though you do not publish the track. 3. Current status. If you pass in a non-null track, it will be used and published. Personally I prefer not to pass in any track when enable == false, you should dispose it after the preview ends, And pass the deviceId you selected during preview to the CameraCaptureOptions parameter
Maybe this should be replaced with 
TrackOption.fromSelectedDevice(String? deviceId), TrackOptions.fromTrack(Track? track), TrackOptions(enabled: true)
?
w
Alright Since im now doing what im doing in the example above im fine
I personally dont pass any objects from screens to screens only strings via queryPArams
i was just interested in why 
room.dispose()
or 
track.dispose
wont stop the red ball from showing if you you create the track when for example 
args.isMicON
is false'
Somehow the issue is connected to the 
fastConnectOptions
because in prejoin screen just creating the track causes no issues
but in the call screen itself it causes issue. so weird
f
If the audio track cannot be completely released, another situation is that track it is in clone, or is held by multiple objects, you can try to add a breakpoint for dart-webrtc in the chrome console https://github.com/flutter-webrtc/dart-webrtc/blob/main/lib/src/media_stream_track_impl.dart#L87 When call the 
room.dispose
or 
track.dispose
, check the 
jsTrack.stop();
is called
Maybe you forgot to call track.start, causing track.stop to be unsuccessful?
Copy code
_audioTrack = await LocalAudioTrack.create(AudioCaptureOptions(
        deviceId: _selectedAudioDevice!.deviceId,
      ));
await _audioTrack!.start(); // <----- this line
w
Haaaaaa I need to start it if I use it in fastConnect???
f
yes …
w
Lmao
So thats why prejoin is also doing that
I mean the livekit prejoin example branch
Would it be bad if fastConnectint started the track so devs dont need to do it?
So it starts it only if enabled true interesting
f
yeah, this is the necessary step, Of course, there are implicit bugs here. Whether or not you call start should be correctly disposed. I will try to repair it and thank you for finding it
👍 1
w
It does make sense tho
That its not started if enabled false tho right? Because it saves some resources or is thst neglibigle duan?
f
Can you test it again, add 
await _audioTrack!.start(),
If the issue disappears
w
yeah im doing it rn
ill do that. Ill create the tracks eve nif args.isMicOn is false and I wont dispose the tracks
Okay it works now if they are disposed
ill now move the videoTrack and audioTrack to variables of the function instead of localVariables and check if that diminishes the need for disposal
okay they do have to be local variables of the class and they need to be disposed
But this starting basicaly provides nothing usefull now
because now the browser will show the redball even if the camera or video is off 😄
actually it shows the redball even if I dont start them
Sorry for sending so many messages I might have been unclear. Please clear with me if it was@freezing-lifeguard-43174
@freezing-lifeguard-43174 I feel like there is nothing to fix here expect what you mentioned about the disposal of track. Most likely people just have to be instructed not to create LocalTracks unless they need to use them right away. Not sure how it should be phrased
f
actually it shows the redball even if I dont start them
yes, the track redball will light up after getUserMedia, even if you don’t call track.start
w
Alright anyhow Im fine with the solution I have now that doesn't call track.start as its not needed
@freezing-lifeguard-43174 Yeah I noticed that from the source code. sad stuff 😄
f
Maybe I should create a small patch to avoid this issue, that is, localTrack should be disposed correctly regardless of whether it is started or not.
w
Agreed. Leave it up to the users of the package to create LocalTrack even if there is no need and the red ball will be showing 👍
Out of interest were will you write that dispose code to?
well anyhow just send me the mr when youre done and ill test by creating the tracks regardless of values of 
isMicOn
isCameraEnabled
and wont dispose them 👍
Open in Slack
PreviousNext
Powered by