https://livekit.io logo
Join Slack
Powered by
This message was deleted.
# helpdesk
s
This message was deleted.
a
Do you have any of the logs?
b
I might have found my issue actually, and it seems to be related to :
Copy code
OnDataReceived: func(data []byte, rp *lksdk.RemoteParticipant) {
                fmt.Println("OnDataReceived", rp)
rp is always 
nil
. Anyone seen this in Go?
Where the data message was sent from the JS SDK from a call:
Copy code
const sendMessage = (eventRequest: EventRequest) => {
    const data = encoder.encode(JSON.stringify(eventRequest));
    room.localParticipant.publishData(data, DataPacket_Kind.RELIABLE, [
      sid,
    ]);
  };
d
I'm not able to reproduce this.. sending a data message from JS and I do get the participant in Go.
d
@dry-elephant-14928 I saw this problem too, sometimes the remote participant in OnDataReceived using go server sdk will be nil but this problem exists for a while and not related to latest version. the problem is that this will happen sometimes so reproducing it will be a little hard.
b
I could agree that this happens more often for me to return nil but sometimes it does return the object.
@dry-elephant-14928, I have a feeling where this might be due to a race condition. It seems like the participant which sent the message, my go client hasn't received any notification about him joining prior to receiving the dataMessage. I could be wrong, but my first guess is that. I'll be testing this some more
In my case, I send the database as soon as the js participant joins the room. 🤷‍♂️
I ran into something similate with cli...
Copy code
livekit-cli load-test --room f4ed79dd-78dc-4c96-8ccd-b967dbfbb771 --video-publishers 10
Using default project Infinivents
Starting load test with 10 video publishers, room: f4ed79dd-78dc-4c96-8ccd-b967dbfbb771
publishing simulcast video track - beekv_pub_0
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x6 pc=0xbc03ea]

goroutine 136 [running]:
<http://github.com/livekit/livekit-cli/pkg/provider.(*H264VideoLooper).nextSample(0xc00035c8d0|github.com/livekit/livekit-cli/pkg/provider.(*H264VideoLooper).nextSample(0xc00035c8d0>, 0x1)
        /home/a104/repos/LiveKit/livekit-cli/pkg/provider/h264looper.go:77 +0x3ea
<http://github.com/livekit/livekit-cli/pkg/provider.(*H264VideoLooper).NextSample(0xc00035c8d0?)|github.com/livekit/livekit-cli/pkg/provider.(*H264VideoLooper).NextSample(0xc00035c8d0?)>
        /home/a104/repos/LiveKit/livekit-cli/pkg/provider/h264looper.go:54 +0x48
<http://github.com/livekit/server-sdk-go.(*LocalSampleTrack).writeWorker|github.com/livekit/server-sdk-go.(*LocalSampleTrack).writeWorker>(0xc000306410, {0x7fd29c2e5420, 0xc00035c8d0}, 0x0)
        /home/a104/go/pkg/mod/github.com/livekit/server-sdk-go@v1.0.13/localsampletrack.go:410 +0x1c7
created by <http://github.com/livekit/server-sdk-go.(*LocalSampleTrack).Bind|github.com/livekit/server-sdk-go.(*LocalSampleTrack).Bind>
        /home/a104/go/pkg/mod/github.com/livekit/server-sdk-go@v1.0.13/localsampletrack.go:186 +0x57b
d
@brief-refrigerator-69901 yeah I think you are right that it could be that the participant had just joined, and that information hasn't been received by the recipient. This is not a new issue though. Re: panic, do you have Git LFS installed? that seems like it's unable to read the video loops
b
@dry-elephant-14928, Yeah maybe it hasn't been related to the latest SDK, sorry for referring to that version. But I think the race condition is it. I've implemented a bit more validation on my end, incase this happens, and things seems to be running smoothly from now.
🙌 1
Regarding the Panic, yes I do have Git LFS installed. 😕
d
hmm that's interesting. how do you reproduce it?
b
Copy code
$ livekit-cli load-test --room f4ed79dd-78dc-4c96-8ccd-b967dbfbb771 --video-publishers 8
Using default project Infinivents
Starting load test with 8 video publishers, room: f4ed79dd-78dc-4c96-8ccd-b967dbfbb771
publishing simulcast video track - rryfa_pub_0
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x6 pc=0xbc03ea]

goroutine 242 [running]:
<http://github.com/livekit/livekit-cli/pkg/provider.(*H264VideoLooper).nextSample(0xc000598870|github.com/livekit/livekit-cli/pkg/provider.(*H264VideoLooper).nextSample(0xc000598870>, 0x1)
        /home/a104/repos/LiveKit/livekit-cli/pkg/provider/h264looper.go:77 +0x3ea
<http://github.com/livekit/livekit-cli/pkg/provider.(*H264VideoLooper).NextSample(0xc000598870?)|github.com/livekit/livekit-cli/pkg/provider.(*H264VideoLooper).NextSample(0xc000598870?)>
        /home/a104/repos/LiveKit/livekit-cli/pkg/provider/h264looper.go:54 +0x48
<http://github.com/livekit/server-sdk-go.(*LocalSampleTrack).writeWorker|github.com/livekit/server-sdk-go.(*LocalSampleTrack).writeWorker>(0xc0000ce5b0, {0x7ff9a01b80c8, 0xc000598870}, 0x0)
        /home/a104/go/pkg/mod/github.com/livekit/server-sdk-go@v1.0.13/localsampletrack.go:410 +0x1c7
created by <http://github.com/livekit/server-sdk-go.(*LocalSampleTrack).Bind|github.com/livekit/server-sdk-go.(*LocalSampleTrack).Bind>
        /home/a104/go/pkg/mod/github.com/livekit/server-sdk-go@v1.0.13/localsampletrack.go:186 +0x57b
d
did you build this CLI or is it using our official builds?
b
built
Maybe that's why.
d
so the most likely issue is still Git LFS.
the placeholder files you've got in place are probably not valid video files
b
Okay. Thanks David. Ill look into that.
d
@dry-elephant-14928 what's the status of this problem so far? I still have this problem 🙁
b
@dry-farmer-50272, If the issue is based on the participant hasn't been notify within the SDK yet, I would have the following suggest. Check if participant is empty, then you could create a queue to be parsed as soon as you have received the participant_joined call. By then, everything should work just as it should. Based on what I'm seeing, this seems like a race condition happening. Maybe thing the LK Team can do about it. Im not sure.
d
@brief-refrigerator-69901 The problem is that when the onDataReceived event is triggered it means that there was definitely a user who sent the data, in this case the question is why should the rp be nil at all? 🤔 btw I ran my project using go race detector and it didn't find any race so if there is a race condition it might be in livekit server itself not go sdk I think ...
b
That'd be correct. Id be on the server. Just to get more info, are you running into that issue on room create? Or participants have been in the room for a while?
I'm trying to see if you are running into the same issue which i was facing and for the same reasons.
d
I have 2 types of users in my project : registered users and anonymous (guest) users. as far as I know this problem almost happen with anonymous users like this : first they will connect to livekit with everything (permissions and ....) like registered users except "canSubscribe" permission then they will send a "enter to room request" to me (my server that uses go sdk) and I will send that request to room host users then they will accept or reject the request if they accept user will update to get canSubscribe permission and if they reject user will be disconnected. this problem happens in this step and user "enter to room" request arrives to me with rp that is nil.
b
You could validate if this would fix it, just for debugging purpose, put a 1-3 second hold before sending your 
enter room request
. See if that fixes the issue, it is not a fix, but it would confirm if the participant is known on the go app or not. By adding a delay, you'd give the race condition a headstart to make sure your server is aware of that participant. I cannot say this is your bug, but Id be curious if it does fix the issue.
For me, once my Go server knew about that participant, everything worked as it should.
d
even with anonymous user this problem happens completely by chance I just tried 4 times to send enter room request as anonymous user and this problem didn't happen 🙁 reproducing that in order to test that 1 sec hold that you said is hard 😑 I will notify you next time that happened.
d
this isn't a "race condition" in the typical sense.. currently because participant metadata is being sent down via websocket, and data message sent over webrtc.. it's possible for the data message to arrive before the metadata identifying the sender. a workaround could be to reconstruct a placeholder Participant object with the correct sender ID.
b
Oh well this makes a whole lot of sense now. Thanks for the clarification @dry-elephant-14928 🙏 🔥
👌 1
3 Views
Open in Slack
PreviousNext
Powered by