LiveKit Community

Hi <@U03G00XN9CJ> 

1. I don’t fully understand what you’re trying to achieve here. I’m guessing you want to use WebRTC’s data channel to send the control signals. I’m not fully aware what you mean by message track, if you can elaborate more it’ll be helpful :)
2. Can you clarify what you’re trying to achieve by playing the video repeatedly ? Is it something like on-repeat behaviour like in GIF?
3. I’m not 100% sure, will need to confirm with the LiveKit team. I believe the bot will create multiple tracks. In your client, you’ll then need to get each track and render them
4. I believe you’ll have access to the error object from those functions. You can pass the error around via Go channel or handle the error in the closure directly

Thanks for reply!
1. I want one client (as the meeting host) to  control a chatbot in the meeting room. For example, the client pre-defined three files (audio or video), send to the chatbot, and can control when the chatbot plays which file in the meeting to everyone.
2. Let me ask this question in a different way. How  can chatbot play two video files? Using one track or two different tracks?
3. If the bot creates multiple tracks (video) and publish tracks same time, will the client see two videos at the same time?
4. OK, thanks!

1. I see, that makes more sense now
2. It depends on your use-case; if you want to play the two video tracks simultaneously so they’re both visible, you’ll need 2 tracks. This means using calling `NewLocalFileTrack()` twice. But if you only want one to appear at a time, you need to store the instance of the track when it gets created, and when another file is requested, stop publishing the current track and create another one. Does this solve your problem ?
3. Yes, I believe both videos will be visible to everyone.

<@U01NZKTNE1H> any ideas what might be happening here? there was a change to use ICELite by default. CC <@U02GP9AENTH>

<@U03J7HTAF1C> can you post full logs from the client with webrtc logging enabled? This can be done with `LiveKit.enableWebRTCLogging` set to true, and `LiveKit.loggingLevel` set to VERBOSE

also, which version of Kotlin SDK are you using?

Does the Publisher connection have audio track published?

I'm also facing similar problem. It's constantly reconnecting. Downgrading server to `v1.0.2` solved the problem. For my case I've tried with plugNmeet (js client).

webrtc_log.txt

<@U01NZKTNE1H> Logs from Android is here. I stopped logging as soon as I got the DISCONNECTED state.

<@U01KZ61GV5Z> I am using self written java client, not official Kotlin SDK

<@U03LNEU9AA0> yes, other participants can hear my voice, but a few seconds before DISCONNECTED state the sound disappears

hmm, looks like the connection type here is prflx here, seems like that connection type has been causing issues. do you have a TURN server setup? this is likely an issue with the network configuration for the server.

a workaround seems to be trying out changing `RTCConfiguration.iceTransportsType` to IceTransportTypes.RELAY or NOHOST

turnserver.conf

<@U01NZKTNE1H> I have a turn server Coturn. Setup is below.

Livekit turn config
```  turn_servers:
    - host: 188.166.17.113
      port: 9090
      protocol: udp
      username: app
      credential: fB9T64B7wCGS3ENnKgzjLVdH```

it seems to be using `prflx:tcp:x.x.x.x` to connect. This means the server's port had somehow gone through NAT. (and it's using ICE/TCP).

have you opened up the ports that the server is running behind?

<@U02LCP104CQ> are you seeing this on Android as well? or is it another platform? If you can provide client SDK &amp; version, that'd be helpful

<@U01KZ61GV5Z> I tried changing the TURN server to our production, which we use for p2p calls. Problem still exists. Then I removed the TURN server from the Livekit config. Problem still exists :smiling_face_with_tear:

the TURN server isn't the issue.. prflx candidates are used when the server's port could not be connected to directly.

have you opened up the ports <https://docs.livekit.io/deploy/ports-firewall/|according to the docs>?

image.png

2022-06-23 20-36-34.mp4

I recorded a video of it happening. When there is a green indication - I hear the sound of another participant. In the logs, you can see the PUBLISHER connection status changes.

And I got level of speaking 1.125. Because of this, the animation at the end of the video broke))))
```speakers {
      active: true
      level: 1.125
      sid: "PA_o9M5BLeYaeVN"
    }```

<@U03J7HTAF1C> Can you post your livekit-server’s config ? 1.1.0 use ICELite by default, that require your server can be direct access by client (have a public address or enable use_external_ip if behinds a 1to1 nat)

And you are running server side at DO, can you post your host’s ifconfig output?

start.sh

config.yaml

ifconfig.txt

You are only open udp 7882 in your firewall right?

From your config, you are enable both port range and udp port mux, and port range takes higher priority. You can comment out port_range in your config file and restart server

<@U03J7HTAF1C> 142.93.141.245 is your server’s public address right?

still not working after you open port 50000-60000?

<@U02GP9AENTH> after opening port 50000-60000 still periodically disconnect

but after removing port range from config it works)

ok, your firewall/nats seems block some (ports) stun msg, next version will revert to 1.0.2 ice lite setting

will the livekit work correctly without port range configuration?

Seems it is unimplemented and always do nothing.

<@U03LNC59919> these interface exist for advanced users to capture and send to their own systems as needed. We are planning a cloud-hosted version of livekit that provides its own analytics handling

hey <@U03KA3MJUCX>, can you tell us a bit more about the set up? and which versions of livekit server/client/egress are you using?

hi <@U03J7HTAF1C>, that functionality already exists! you can just call `participant.setVolume(vol)` .
The effect is however only local and will not be distributed to other participants. What happens internally is that the volume of all attached HTMLElements gets set accordingly.

(this is talking about the javascript sdk)

Is this feature not available for android?

the feature is pretty new in the js sdk. The plan is there to provide this functionality wherever possible, but not sure if it has made its way into the android sdk yet. cc <@U01NZKTNE1H>

atm, they should be available by accessing the webrtc audio track directly, which has a `setVolume(double volume)` function

hey Ash, can you try it with the latest JS SDK? If it remains an issue, please file an issue with repro steps. Thanks!

Hi Fahad, I’m not sure what you meant by the stream screen. LiveKit is pretty much customisable from a UI perspective, but if you’re referring to the page at <https://example.livekit.io|https://example.livekit.io>, you can check out the project at <https://github.com/livekit/livekit-react/tree/master/example|https://github.com/livekit/livekit-react/tree/master/example>

<@U033W4A4H8X> the error indicates it's a DNS lookup failure.
```failed to resolve stun host: <http://global.stun.twilio.com:3478|global.stun.twilio.com:3478>: lookup <http://global.stun.twilio.com|global.stun.twilio.com> on 1.1.1.1:53: no such host```
this is used when the server is behind NAT and `use_external_ip` isn't enabled.

so I think the options are:
1. ensure DNS server availability
2. enable `use_external_ip`

ah, ok, I will investigate this issue.  <@U030EQWCDGA> On which platforms (ios/android/web/mac) does this issue appear?

Even the 1.0.1 client version still does not work.

hmm weird, this should've been fixed in 1.0.1

<@U030EQWCDGA> can you try the flutter sample app? I just tested and worked on my phones

hey <@U030EQWCDGA>, I used flutter 3.0.2 to compile/run the example on android/macOS, both sides seem to be able to send/recv through the data-channel message, have you tried to clear the pub cache and the compilation cache of android studio?

i CAN confirm it is working on the sample project. will try to rebuild my app (since i updated from flutter 2 to flutter 3).

On the server I have `v0.15.7` and on the client I have `1.0.4`.

<@U01KZ61GV5Z> Is there any way to tell if a disconnect is being performed by the server, or by the client ? I'm trying to figure out if this is a Safari bug or what.

I'm not aware of a safari bug that would cause it to be disconnected.. server logs should be helpful to see the cause of disconnect

<@U01KZ61GV5Z> Does this mean that the disconnect wasn't initiated by the server? This is from the server logs:

```Jun 30 15:33:31 localhost bash[558194]: 2022-06-30T15:33:31.600Z#011INFO#011livekit#011service/rtcservice.go:230#011source closed connection#011{"room": "workspace-Paul", "participant": "pmooser", "connID": "pmooser"}```

any other log items about that participant before then?

<@U01KZ61GV5Z> Sorry for the delay in responding. I don't want to spam here, but here is a bunch of log messages from before the actual disconnect - I see a message send failure, among other things. I've turned debugging up all the way.

```Jul  4 11:27:49 localhost bash[558194]: 2022-07-04T11:27:49.525Z#011DEBUG#011livekit#011rtc/mediatracksubscriptions.go:509#011updating quality change#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "force": false, "maxSubscriberQuality": {}, "maxSubscriberNodeQuality": {}, "maxSubscribedQuality": {"video/VP8":2}}
Jul  4 11:27:49 localhost bash[558194]: 2022-07-04T11:27:49.528Z#011DEBUG#011livekit#011rtc/mediatracksubscriptions.go:566#011updating quality change#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "changed": true, "maxSubscribedQuality": {"video/VP8":3}, "t.maxSubscribedQuality": {"video/VP8":2}, "comesDownQuality": {"video/VP8":2}}
Jul  4 11:27:54 localhost bash[558194]: 2022-07-04T11:27:54.529Z#011DEBUG#011livekit#011rtc/mediatracksubscriptions.go:509#011updating quality change#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "force": true, "maxSubscriberQuality": {}, "maxSubscriberNodeQuality": {}, "maxSubscribedQuality": {"video/VP8":2}}
Jul  4 11:27:54 localhost bash[558194]: 2022-07-04T11:27:54.531Z#011DEBUG#011livekit#011rtc/mediatracksubscriptions.go:566#011updating quality change#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "changed": true, "maxSubscribedQuality": {"video/VP8":3}, "t.maxSubscribedQuality": {"video/VP8":3}, "comesDownQuality": {"video/VP8":2}}
Jul  4 11:27:54 localhost bash[558194]: 2022-07-04T11:27:54.532Z#011DEBUG#011livekit#011rtc/mediatracksubscriptions.go:624#011subscribedMaxQualityChange#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "subscribedCodec": [{"codec":"video/VP8","qualities":[{},{"quality":1},{"quality":2}]}], "maxSubscribedQualities": [{"CodecMime":"video/VP8","Quality":3}]}
Jul  4 11:27:54 localhost bash[558194]: 2022-07-04T11:27:54.532Z#011DEBUG#011livekit#011rtc/participant.go:1447#011sending max subscribed quality#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "qualities": [{"codec":"vp8","qualities":[{},{"quality":1},{"quality":2}]}], "max": [{"CodecMime":"video/VP8","Quality":3}]}
Jul  4 11:28:09 localhost bash[558194]: 2022-07-04T11:28:09.948Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:130#011StreamTrackerManager.OnStatusChanged#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "layer": 2, "status": "stopped"}
Jul  4 11:28:09 localhost bash[558194]: 2022-07-04T11:28:09.951Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:398#011available layers changed - layer gone#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "removed": 2, "layers": [0, 1]}
Jul  4 11:28:10 localhost bash[558194]: 2022-07-04T11:28:10.031Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:130#011StreamTrackerManager.OnStatusChanged#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "layer": 0, "status": "stopped"}
Jul  4 11:28:10 localhost bash[558194]: 2022-07-04T11:28:10.031Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:398#011available layers changed - layer gone#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "removed": 0, "layers": [1]}
Jul  4 11:28:10 localhost bash[558194]: 2022-07-04T11:28:10.039Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:130#011StreamTrackerManager.OnStatusChanged#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "layer": 1, "status": "stopped"}
Jul  4 11:28:10 localhost bash[558194]: 2022-07-04T11:28:10.039Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:398#011available layers changed - layer gone#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "removed": 1, "layers": []}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.096Z#011INFO#011livekit#011service/rtcservice.go:211#011new client WS connected#011{"room": "dev-workspace-1", "participant": "pmooser", "connID": "pmooser", "roomID": "RM_LuBGNT4i6DS2"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.099Z#011DEBUG#011livekit#011service/roommanager.go:387#011RTC session finishing#011{"participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.099Z#011INFO#011livekit#011rtc/participant.go:657#011closing participant#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "sendLeave": true, "reason": "RTC_SESSION_FINISH"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.099Z#011INFO#011livekit#011rtc/participant_signal.go:243#011could not send message to participant#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "message": "*livekit.SignalResponse_Leave", "error": "channel closed"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.099Z#011DEBUG#011livekit#011rtc/mediatracksubscriptions.go:272#011removing all subscribers#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.099Z#011DEBUG#011livekit#011rtc/mediatracksubscriptions.go:272#011removing all subscribers#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_AMiTQC2aRGyvqH"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.100Z#011DEBUG#011livekit#011rtc/participant.go:1057#011updating participant state#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "state": "DISCONNECTED"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.100Z#011INFO#011livekit#011buffer/buffer.go:291#011rtp stats#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_AMiTQC2aRGyvqH", "mime": "audio/opus", "layer": 0, "stats": "t: Mon Jul  4 11:27:39 UTC 2022|Mon Jul  4 11:28:27 UTC 2022|47.56s sn: 25762|26694, ep: 933|19.62/s, p: 933|19.62/s, l: 0|0.0/s|0.00%, b: 56081|9433.9bps, f: 9|0.2/s / 0|Mon Jan  1 00:00:00 UTC 0001, d: 0|0.00/s, bd: 0|0.0bps, pp: 0|0.00/s, bp: 0|0.0bps, o: 0, c: 48000, j: 169(3534.6us)|169(3534.6us), n:0|0|0|0, pli:0|Mon Jan  1 00:00:00 UTC 0001 / 0|Mon Jan  1 00:00:00 UTC 0001, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):0|0"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.100Z#011INFO#011livekit#011buffer/buffer.go:291#011rtp stats#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "layer": 0, "stats": "t: Mon Jul  4 11:27:39 UTC 2022|Mon Jul  4 11:28:27 UTC 2022|47.57s sn: 750|1319, ep: 570|11.98/s, p: 570|11.98/s, l: 0|0.0/s|0.00%, b: 441755|74290.0bps, f: 448|9.4/s / 2|Mon Jul  4 11:27:39 UTC 2022, d: 1|0.02/s, bd: 325|54.7bps, pp: 0|0.00/s, bp: 0|0.0bps, o: 1, c: 90000, j: 256(2845.5us)|256(2845.5us), n:0|0|0|0, pli:0|Mon Jan  1 00:00:00 UTC 0001 / 0|Mon Jan  1 00:00:00 UTC 0001, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):0|0"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.100Z#011INFO#011livekit#011buffer/buffer.go:291#011rtp stats#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "layer": 1, "stats": "t: Mon Jul  4 11:27:39 UTC 2022|Mon Jul  4 11:28:27 UTC 2022|47.56s sn: 10252|11506, ep: 1255|26.39/s, p: 1232|25.90/s, l: 0|0.0/s|0.00%, b: 1103155|185552.5bps, f: 597|12.6/s / 2|Mon Jul  4 11:27:39 UTC 2022, d: 1|0.02/s, bd: 436|73.3bps, pp: 23|0.48/s, bp: 5612|943.9bps, o: 1, c: 90000, j: 239(2659.7us)|239(2659.7us), n:0|0|0|0, pli:0|Mon Jan  1 00:00:00 UTC 0001 / 0|Mon Jan  1 00:00:00 UTC 0001, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):0|0"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.100Z#011INFO#011livekit#011buffer/buffer.go:291#011rtp stats#011{"room": "dev-workspace-1", "roomID": "RM_LuBGNT4i6DS2", "participant": "pmooser", "pID": "PA_ZMvrwDEmPopr", "trackID": "TR_VCQCWYfKpH7M4Z", "mime": "video/vp8", "layer": 2, "stats": "t: Mon Jul  4 11:27:39 UTC 2022|Mon Jul  4 11:28:27 UTC 2022|47.15s sn: 24322|30087, ep: 5766|122.28/s, p: 5646|119.73/s, l: 0|0.0/s|0.00%, b: 6255149|1061216.2bps, f: 879|18.6/s / 1|Mon Jul  4 11:27:39 UTC 2022, d: 0|0.00/s, bd: 0|0.0bps, pp: 120|2.54/s, bp: 29280|4967.5bps, o: 0, c: 90000, j: 301(3348.7us)|301(3348.7us), n:0|0|0|0, pli:0|Mon Jan  1 00:00:00 UTC 0001 / 0|Mon Jan  1 00:00:00 UTC 0001, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):0|0"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.100Z#011INFO#011livekit#011service/rtcservice.go:230#011source closed connection#011{"room": "dev-workspace-1", "participant": "pmooser", "connID": "pmooser"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.103Z#011INFO#011livekit#011service/rtcservice.go:257#011exit ws read loop for closed connection#011{"room": "dev-workspace-1", "participant": "pmooser", "connID": "pmooser"}
Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.103Z#011INFO#011livekit#011service/rtcservice.go:191#011server closing WS connection#011{"room": "dev-workspace-1", "participant": "pmooser", "connID": "pmooser"}```

it seems that you've had another participant join with the exact same identity: `Jul  4 11:28:27 localhost bash[558194]: 2022-07-04T11:28:27.096Z#011INFO#011livekit#011service/rtcservice.go:211#011new client WS connected#011{"room": "dev-workspace-1", "participant": "pmooser", "connID": "pmooser", "roomID": "RM_LuBGNT4i6DS2"}``

<@U01KZ61GV5Z> That's very interesting. My code does the following:

• create a Room object
• set event handlers for the room
• call `connect` on the room
• call `enableCameraAndMicrophone` on the local participant
That's literally it. The only way I can explain a second connection is if the client thought it lost the connection and so reconnected/retried (please let me know if this seems possible) before the server ever thought the connection was gone, resulting in what you saw, which was another participant joining with the same identity.

My code has no kind of retry/reconnect built in on its own at all. I use the `Disconnected` handler for cleanup.

When tailing the server logs AND looking at the client logging in the browser, what I see is that the server always logs something like this:

```Jul  5 07:27:53 localhost bash[558194]: 2022-07-05T07:27:53.812Z#011DEBUG#011livekit#011rtc/mediatracksubscriptions.go:624#011subscribedMaxQualityChange#011{"room": "dev-workspace-1", "roomID": "RM_D3wu9Kpew7DC", "participant": "pmooser", "pID": "PA_FYGMwSE6vJuR", "trackID": "TR_VCENHWJfHXSVH3", "subscribedCodec": [{"codec":"video/H264","qualities":[{},{"quality":1},{"quality":2}]}], "maxSubscribedQualities": [{"CodecMime":"video/H264","Quality":3}]}
Jul  5 07:27:53 localhost bash[558194]: 2022-07-05T07:27:53.813Z#011DEBUG#011livekit#011rtc/participant.go:1447#011sending max subscribed quality#011{"room": "dev-workspace-1", "roomID": "RM_D3wu9Kpew7DC", "participant": "pmooser", "pID": "PA_FYGMwSE6vJuR", "trackID": "TR_VCENHWJfHXSVH3", "qualities": [{"codec":"h264","qualities":[{},{"quality":1},{"quality":2}]}], "max": [{"CodecMime":"video/H264","Quality":3}]}
Jul  5 07:28:08 localhost bash[558194]: 2022-07-05T07:28:08.839Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:130#011StreamTrackerManager.OnStatusChanged#011{"room": "dev-workspace-1", "roomID": "RM_D3wu9Kpew7DC", "participant": "pmooser", "pID": "PA_FYGMwSE6vJuR", "trackID": "TR_VCENHWJfHXSVH3", "mime": "video/h264", "layer": 1, "status": "stopped"}
Jul  5 07:28:08 localhost bash[558194]: 2022-07-05T07:28:08.842Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:398#011available layers changed - layer gone#011{"room": "dev-workspace-1", "roomID": "RM_D3wu9Kpew7DC", "participant": "pmooser", "pID": "PA_FYGMwSE6vJuR", "trackID": "TR_VCENHWJfHXSVH3", "mime": "video/h264", "removed": 1, "layers": [0, 2]}
Jul  5 07:28:08 localhost bash[558194]: 2022-07-05T07:28:08.875Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:130#011StreamTrackerManager.OnStatusChanged#011{"room": "dev-workspace-1", "roomID": "RM_D3wu9Kpew7DC", "participant": "pmooser", "pID": "PA_FYGMwSE6vJuR", "trackID": "TR_VCENHWJfHXSVH3", "mime": "video/h264", "layer": 2, "status": "stopped"}
Jul  5 07:28:08 localhost bash[558194]: 2022-07-05T07:28:08.875Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:398#011available layers changed - layer gone#011{"room": "dev-workspace-1", "roomID": "RM_D3wu9Kpew7DC", "participant": "pmooser", "pID": "PA_FYGMwSE6vJuR", "trackID": "TR_VCENHWJfHXSVH3", "mime": "video/h264", "removed": 2, "layers": [0]}
Jul  5 07:28:09 localhost bash[558194]: 2022-07-05T07:28:09.313Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:130#011StreamTrackerManager.OnStatusChanged#011{"room": "dev-workspace-1", "roomID": "RM_D3wu9Kpew7DC", "participant": "pmooser", "pID": "PA_FYGMwSE6vJuR", "trackID": "TR_VCENHWJfHXSVH3", "mime": "video/h264", "layer": 0, "status": "stopped"}
Jul  5 07:28:09 localhost bash[558194]: 2022-07-05T07:28:09.314Z#011DEBUG#011livekit#011sfu/streamtrackermanager.go:398#011available layers changed - layer gone#011{"room": "dev-workspace-1", "roomID": "RM_D3wu9Kpew7DC", "participant": "pmooser", "pID": "PA_FYGMwSE6vJuR", "trackID": "TR_VCENHWJfHXSVH3", "mime": "video/h264", "removed": 0, "layers": []}```
About a second before the client sees a disconnect.

In particular, what does it mean when we get a `layer gone` with an empty array of layers ? Is this an error ?

those are fine.. that usually is because you are using dynacast and there are no subscribers. can you reproduce this with the <https://example.livekit.io|example app>? I'm not able to.

I will test that and get back to you. Thank you.

<@U01KZ61GV5Z> Yes, it's reproduceable, as long as I point at my livekit server.

I'm going through a VPN (at work) so I'm not sure if that could somehow trigger this problem, or if there's some other configuration-related element that triggers this problem.

I don't think UDP is currently being used (I haven't figured out how to make it work through the VPN etc) ... I'm not sure if that could trigger things either, although it works perfectly fine in chrome.

I wonder if this could be a problem which only happens for Safari (desktop) with TCP connections only (no UDP).

ah that's certainly possible! but only Safari huh?

which VPN are you using? is it going through TURN as well? (if you've set up TURN/TLS)

I'm not sure if this is what you mean, but my VPN is over SSL.

I am using the TURN server in livekit - at least I intend to be doing so. I have it enabled and I've configured the `cert_file` and `key_file`  ... I'm set to port 443 for TLS right now.

I see, I'm just asking in order to replicate the bug. we have not been able to get Safari to disconnect in the way that you'd described.

<@U01KZ61GV5Z> For a different issue, lukas directed me to the livekit connection test (which I hadn't known existed), which showed that I'm not able to make a TURN connection.

Capture d’écran 2022-06-28 à 11.19.44.png

I haven't used our helm chart with terraform before. Does it work if you use the helm command directly?

Yes, the helm command works directly.
Actually, I figured out why: the reason is that terraform does not track the namespace of this helm_release, so when testing if it is up, it is trying to test on the default namespace.

What I did is just remove the namespace and create_namespace entries and it worked like a charm :star-struck:

clipboard_1656417836980.png

Hello, Community, when I compile livekit-react using the code pulled from github, I got the error below, is this a bug or a environmental issue? Thanks.

We don't support a build with bitcode.. so I think disabling bitcode would be the way to go here.

your command looks right.. and seems like it's attempting to connect.. what do you get when you run:
```curl <https://livekit.mydomain.com>```
If it's reachable, it should return `OK`

on both machines it says OK. I can connect via both client sdk and server sdk also. even the  livekit cli works fine and only the load tester has issues.

I searched through source code and it seems the error message is coming from gorilla websocket library. I tried a chrome websocket extension and also sent websocket requests via Postman to the livekit server and both solution work fine. So I guess the issue might be related to how the gorilla is sending WebSocket requests. I'll try to dig deeper into the source code.

Sorry,  my bad,:man-facepalming: I have two test machines for livekit and I was passing wrong api key and secret to this instance. thank you for your time.
By the way, it might be good to show a more descriptive error message if it's possible.

ah yes.. agreed. I'm glad you've figured it out tho

use for some sort of authorization would also be good, since it seems that template pages are (or at least can be) internet accessible. LiveKit does this for itself with `token`, but I have other app services I also want to prevent public access to. Making the recording page have special privilege to join things like live collaboration data sockets could be a vulnerability for room privacy if discovered.

if I could pass a custom param, I could generate a "recording password" for each session and provide that, then verify it when the recording client browser connects to allow access to app data.

hey Grant, what about a custom baseurl that encodes any parameters that you'd like? for example:
```base_url: <http://your-page/>&lt;recording-password&gt;```

we would simply append parameters to it with the composite stack.. so your base url is passed to your application

your suggestion is great too! to accept a user-data parameter that we can pass through

is the base url runtime configurable? I'm still reading the docs and haven't gotten anything working yet, but it looked like the base URL was something you set on the Egress service and not something passed by the SDK at runtime

oh I see, it's at the end of the parameter list in the Node SDK

thanks, that will be a cleaner implementation

worked out ok, I'd still recommend adding a way to pass additional parameters. URL path fragments are an awkward solution for encoding arbitrary data.

Hey <@U03MK5DEWUS>, it appears that you’re creating two rooms and trying to send messages between them. Unfortunately, this isn’t going to work. Your participants should join the same room, where you can then send data between them.

I assumed the room was determined by the jwt and the connection rather than room objects. When I get the participants of the room, it shows all users I expect within the list of participants. If that is not how it would work, how would I use the same room to manage two separate entities?

As more clarification, while the tokens are different, the room requested is the same between the two tokens.

I think the issue is here: `[botroom.sid]`

the second parameter to `publishData` should be the destination participant's SID.. not the room's id

it should be an ID starting with `PA_` (we'll make this easier in the future so it could be the participant's identity instead)

in your above example <@U03MK5DEWUS>:
```myroom.localParticipant.publishData(encoder.encode("payload"), DataPacket_Kind.RELIABLE, [botroom.localParticipant.sid]).then(() =&gt; { ... })```

微信图片_20220629200442.jpg

hmm, seems like a bug, will look into fixing it

What is the expected behavior? I saw restart track is called in this scenario? Is the behavior designed to be calling create a new track or restart the track? Thanks.

if you're talking about the sample app, it should reuse the same track

tracking here: <https://github.com/livekit/client-sdk-react-native/issues/10>

When I look at the call trace, it does calling the restart track, but looks the status of the track is unpublished track when it restarts, so it reported the error.

When I look at the code about disabling the camera, I did not see the code set the track unpublished, so I got lost.

to clarify, the full filename of a recording looks like `./tmp-recordings/recordingname.mp4`

in a normal filesystem that'd be a valid relative path, but I think GCP storage just treats the `.` like a virtual directory, and then can't resolve that into a valid URL to download the file or something

I think a `/./` path fragment like that in a URL just gets deleted (i.e. "resolved" to the same path location)

but either way I'm guessing the intention wasn't to make `./tmp-recordings` the actual storage path, seems more like a malformed upload took the local filepath instead of specifying a destination bucket path

Hey Grant, are you seeing this with the latest version? It may be an unintended behavior with <https://github.com/livekit/egress/pull/55|this PR>, or <https://github.com/livekit/egress/pull/51|this one>

can you share the request that you've sent as well?

yeah, I just installed Egress yesterday from latest charts

the request was made through the Node SDK

oh shoot, just grabbing the code and I realized I put `./tmp-recordings/${name}.mp4` as the filepath in the output config... that's probably it!

thanks for taking a look, I'm guessing if I change that to something meaningful my problem will be fixed

Might be as straightforward as swapping out JitsiFactory for a LiveKitFactory, but not sure.

<https://github.com/thecodingmachine/workadventure/blob/390e1a5086910dfa17d4664a962a82d9e3ac01ee/front/src/WebRtc/JitsiFactory.ts|https://github.com/thecodingmachine/workadventure/blob/390e1a5086910dfa17d4664a962a82d9e3ac01ee/front/src/WebRtc/JitsiFactory.ts>

what does your client look like? it's possible that it's not getting the new track appropriately.

unpublish/republish is fairly expensive, because it causes all of the subscribers to unsubscribe + resubscribe to a new track. nonetheless, the use case should still work.

can you try joining the room as a new subscriber *after* the new track is published? does the new subscriber see the video?

&gt; can you try joining the room as a new subscriber *after* the new track is published? does the new subscriber see the video?
ahhh yes I could see the video when I joined as a new subscriber!!

ok, then it probably means the issue is with the JS subscriber, it might not be rendering the right track.

That helps narrow it down a lot, thank you! I'm going to look into it now.

&gt; unpublish/republish is fairly expensive, because it causes all of the subscribers to unsubscribe + resubscribe to a new track. nonetheless, the use case should still work.
As for this, is there a better way I could do it?

yeah, so the easiest way is to Mute the track publication, and stop writing data. then call <https://github.com/livekit/server-sdk-go/blob/main/localsampletrack.go#L224|LocalSampleTrack.StartWrite> with the new sample provider

and of course unmute before you start writing the new file

Great, thank you for the responses I appreciate it!

Hey David, are there any user facing symptoms? These messages by themselves aren't a cause for concern. it could happen when a participant has disconnect while we are trying to send it essages

we are seeing feeds get disconnected and going black when others come online... it seemed to correspond with these messages, but it must be something else going on

are there other log lines other than this that look abnormal?

seeing these as well:
```REMB not supported, RTCP feedback will not be generated

error when handling datagram: failed to create stun message from packet: unexpecte │
│ Loop```

gotcha, that seems abnormal. how can one reproduce this? do you recall what actions might be taken when "feeds get disconnected"?

Thank you for responding. After doing more troubleshooting, i think the issue might be on the client side. I think our components are re-rendering causing the client to disconnect/reconnect.

although, one config issue i'm facing is with the API keys... does the server itself also support the separated `LIVEKIT_KEY` and `LIVEKIT_SECRET` vars like the SDK or just the combined `LIVEKIT_SECRETS` var?

Updating to <https://github.com/livekit/client-sdk-js/releases/tag/v1.1.9|v1.1.9> not resovle a problem

are there any errors when connecting to the USB camera?

would be great if you can debug it and see where it's failing

No errors. Also i have this issue on "sample" without any errors.

I don't know if it helps. But when i switch notebook camera to usb - i see that camera turn off with indicator and after that starts again

I can reproduce this problem  On Chrome, Opera, Brave - i think the problem with chromium browsers
Firefox is ok
Platform windows

Hey <@U03HAK3GKA9>, yes, it can be used with CloudFront.

You'd have to add a cloudfront distribution to the bucket that you are outputting to with Egress. then point the player to the m3u8 playlist that we are generating

Hi <@U034V68D5SQ>,
does it work for you with the official `@livekit/react-components` package?
you can test it on <http://example.livekit.io|example.livekit.io>

<@U02EU2ZPTQU> hi, same i cannot share entire screen. I think it is related to my mac or browser setting

values=old.yaml

can you see any information on the deployment itself? looks like you've copied resource requests for 8 CPUs.. that's probably overkill for your instance and might cause it to be unscheduled

And the server instance is running a cpu of i7-7700 so technically 8 cores should be OK I guess

the closest thing is <https://docs.livekit.io/deploy/benchmark/> to understand CPU requirements for your application. though majority of the costs would be related to bandwidth

Hey Mike, are you using a private cluster on Kubernetes? Are the ports forwarded correctly?

We ended up reverting the ice-lite change (and will be released in the next version). It should work well if all of the ports are forwarded (and there isn't additional NAT); but some of these configurations can be tricky to get right

No, I never got it to work with a private cluster, so switched to public cluster and it was fine after that.  So do I just need to wait for 1.1.1 or whatever, or is there anything I can do now to make 1.1.0 work?

you can manually set rtc.use_ice_lite to false for now. see if that works for you

<@U01KZ61GV5Z> setting `use_ice_lite=false` seems to have resolved the issue, thank you!  Do you know approximately when the next release will ship?

it'll ship later this week :slightly_smiling_face:

Simulcast is the same feed at different resolutions, so probably not what you want. I'm not familiar with ios but you wouldn't want to instantiate the feed twice, you'd want to grab the feeds stream and render it twice.

maybe just create another VideoView and assign the same track? <https://docs.livekit.io/client-sdk-swift/VideoView/#videoview.track>

Thanks for the response.  Yeah I tried the latter, if I use a local video view with the same track only one of the tracks renders at a time

&gt; render the same track twice
Hello, do you mean you are trying to attach a single track to multiple `VideoView` s ?

At the moment multiple VideoViews can’t be attached to a single track,
but I’m working on fixing this. (Although not sure if this is what you are asking for)

(related to the AdaptiveStream feature)

Thanks <@U02MAJLGN65> that is what I'm talking about.

Unless there is another way to have the same local track twice, we can wait for your fix 

Hi, improvements have been merged into `main` branch of the SDK.
I’ll try to get more fixes in and tag a new version.

Hi Chris,

When you publish a file track, the function calls a goroutine underneath, so you shouldn’t need to wrap it inside another goroutine. 

But should you want to wrap it inside a goroutine, you need to ensure that the main function waits for that goroutine to finish. This can be achieved using WaitGroups or channels. I recommend this <https://gobyexample.com/waitgroups|page> for learning more. 

Let me know if you have more questions, I’m happy to help :+1: