https://livekit.io logo
Join Slack
Powered by
# helpdesk
  • c

    clever-kite-90169

    01/28/2021, 5:50 PM
    i’ve been using latest (main) for local testing
  • c

    clever-kite-90169

    01/28/2021, 5:50 PM
    for our deployment we’ll use tag versions
  • c

    clever-kite-90169

    01/28/2021, 8:05 PM
    Getting this error pretty regularly right now
    lk_debug.txt
  • s

    steep-balloon-41261

    01/28/2021, 8:07 PM
    This message was deleted.
    w
    d
    • 3
    • 5
  • c

    clever-kite-90169

    01/28/2021, 8:07 PM
    oh ok cool i’ll flip to that
  • c

    clever-kite-90169

    01/28/2021, 11:27 PM
    getting some publishing errors, it might be on republish from the same user back into a session (w/o a clean hangup)
    lk_debug.txt
  • c

    clever-kite-90169

    01/28/2021, 11:27 PM
    this is the case where it works properly
    lk_debug2.txt
  • c

    clever-kite-90169

    01/28/2021, 11:27 PM
    there's a lot more logs in teh bad case i can try to capture the entire thing
  • c

    clever-kite-90169

    01/28/2021, 11:27 PM
    Also see a lot of this today:
    Copy code
    2021-01-28T23:27:41.936Z        DEBUG   rtc/mediatrack.go:327   forwarder got nack      {"packet": "TransportLayerNack from 1\n\tMedia Ssrc a4e70aec\n\tID\tLostPackets\n\t34520\t0\n"}
  • d

    dry-elephant-14928

    01/28/2021, 11:29 PM
    ah ha.. thanks for sharing these.. I’ll take a look
  • d

    dry-elephant-14928

    01/28/2021, 11:29 PM
    the NACKs are great, that means it’s recovered from a packet loss
  • c

    clever-kite-90169

    01/28/2021, 11:41 PM
    yeah 🙂
  • c

    clever-kite-90169

    01/28/2021, 11:41 PM
    surprisingly its happening today
  • c

    clever-kite-90169

    01/28/2021, 11:42 PM
    might be desktop vs laptop
  • c

    clever-kite-90169

    01/28/2021, 11:42 PM
    or the device itself too
  • s

    steep-balloon-41261

    01/29/2021, 12:05 AM
    This message was deleted.
    d
    c
    • 3
    • 6
  • c

    clever-kite-90169

    01/29/2021, 12:05 AM
    i tried both / each one
  • c

    clever-kite-90169

    01/29/2021, 12:08 AM
    Also just got the first 2 way video call fully working in our system + livekit!
    🎉 2
    🙌 2
  • s

    steep-balloon-41261

    01/29/2021, 12:09 AM
    This message was deleted.
    c
    • 2
    • 1
  • c

    clever-kite-90169

    01/29/2021, 12:15 AM
    Fwiw single mode is more reliable for me with multi person calls, redis eventually gets better but I think there’s a couple ttl’s that are too long
  • s

    steep-balloon-41261

    01/29/2021, 12:19 AM
    This message was deleted.
    c
    d
    • 3
    • 2
  • c

    clever-kite-90169

    01/29/2021, 7:47 AM
    in the LK react example if connect returns we're assumed to be "connected" but this doesn't mean the peer connection happened. So right now what I see: • call livekit connect • no peer info was exchanged (no timeout here either) • .connect returns • no actual peer was connected Not sure if this is a bug or if there's a better way i'm supposed to be doing this
  • c

    clever-kite-90169

    01/29/2021, 7:47 AM
    Copy code
    if (connected || connecting) {
                    return;
                }
    
                setConnecting(true);
                try {
                    const authResp = await fetch('/api/rtc/auth', {
                        body: JSON.stringify({
                            room_id: sessionId,
                        }),
                        headers: {
                            'Content-Type': 'application/json',
                        },
                        method: 'POST',
                    });
    
                    const { token } = await authResp.json();
                    const r = await Livekit.connect(
                        {
                            host: RTC_HOST as string,
                            port: parseInt(RTC_PORT as string, 10),
                            secure: RTC_SECURE === 'true',
                        },
                        token,
                        {
                            logLevel: LogLevel.debug,
                        },
                    );
                    room.current = r;
                    setConnected(true);
                    setConnecting(false);
                    console.log('Connnected!');
    
                    room.current
                        .on(RoomEvent.ParticipantConnected, ParticipantConnected)
                        .on(RoomEvent.ParticipantDisconnected, ParticipantDisconnected)
                        .on(RoomEvent.TrackMessage, TrackMessage)
                        .on(RoomEvent.TrackSubscribed, onTrackSubscribed)
                        .on(RoomEvent.TrackUnsubscribed, onTrackUnsubscribed);
                } catch (err) {
                    setConnected(false);
                    setConnecting(false);
                    console.error('Failed to connect to livekit', err);
                }
  • c

    clever-kite-90169

    01/29/2021, 7:48 AM
    does that look correct?
  • c

    clever-kite-90169

    01/29/2021, 7:49 AM
    server doesn't send a response to offer, client doesn't have a timeout (or it might be longer)
  • d

    dry-elephant-14928

    01/29/2021, 7:51 AM
    hey, the react example hasn't been tested fully.. still in the process of updating it to LK
  • s

    steep-balloon-41261

    01/29/2021, 7:52 AM
    This message was deleted.
    d
    c
    • 3
    • 4
  • d

    dry-elephant-14928

    01/29/2021, 7:53 AM
    you are right, currently connect returns after the offer is sent.. but not necessarily negotiated
  • d

    dry-elephant-14928

    01/29/2021, 7:56 AM
    this probably should be improved to make connect resolve or error on RTC status.. versus websocket
  • c

    clever-kite-90169

    01/29/2021, 7:56 AM
    yeah i think in this case i'd want to know both or possibly another event
1...91011...91Latest