LiveKit Community

Hello, I’m trying to build client-sdk-js but I’m getting the following error. Any ideas?  eventemitter3 is there in node_modules
```
npx yarn build
yarn run v1.22.19
$ rollup --config --bundleConfigAsCjs &amp;&amp; yarn downlevel-dts

src/index.ts → dist/livekit-client.esm.mjs, dist/livekit-client.umd.js...
[!] (plugin rpt2) RollupError: src/room/Room.ts:1:26 - error TS2307: Cannot find module 'eventemitter3' or its corresponding type declarations.

1 import EventEmitter from 'eventemitter3';```

thank you for the note. this is fixed now

for publishing, 32Kbps would give you sufficient quality

thanks for the reply! how about the bandwith for receiving audio?

it depends on how many users you are receiving from

Its only from one. So basically one spreaker and 30 - 60 receivers

I want to develop an app in flutter , we are integrating video calling app with call recording on android , ios  and web .If we can able to use this library ,Please let me know.

<@U01NZKTNE1H> BTW it's working if I use NoAudioHandler instead of AudioSwitchHandler

can you share a code snippet of how you are calling these APIs as well?

<@U01KZ61GV5Z> You mean how I create a room ?

Now I it looks like

```LiveKit.create(
    context,
    options = RoomOptions(
        adaptiveStream = false,
        dynacast = false
    ),
    overrides = LiveKitOverrides(
        audioHandler = NoAudioHandler() //AudioSwitchHandler(context)
    )
)```

If I put AudioSwitchHandler or don't provide overrides it does not work. If I'm not wrong you sample is also using AudioSwitchHandler

<@U01KZ61GV5Z> <@U01NZKTNE1H> Do you know what can be a problem. As I see you are using Twilio's AudioSwitcher inside. Can it cause this issues ?

hmm, audio switch should only handle the audio output side, not the input side.

Have you tried creating your own JavaAudioDeviceModule and testing out the `setPreferredInputDevice` method? there’s a couple AudioDeviceInfo types that might fit your needs like `TYPE_USB_DEVICE` or `TYPE_USB_ACCESSORY`

<@U01NZKTNE1H> No I did not. I have to wait it get this device to make further testing and investigating. Found that also another Android TV with mic and camera livekit made to reboot ) Did not test NoAudioHandler there yet to see if after this it will be working

Also h264 does not want to work or it's working sometimes, but with green artifacts.

<@U02PKGPAE0P> which device are you seeing green artifacts? It's likely a hardware encoder issue. If you have the device model, please let us know, we can look at how to bypass hw encoding on devices like that

<@U01KZ61GV5Z> I’ll ask to provide me full details. But most likely this board is used <https://chinese.alibaba.com/product-detail/rockchip-RK3568-android-11-board-motherboard-1600817887372.html|https://chinese.alibaba.com/product-detail/rockchip-RK3568-android-11-board-motherboard-1600817887372.html>

With android 11 and camera over Mini connection


Currently to isolate it I just filter out h264 codec from supported list 

unfortunately there isn't a way today. feel free to open an issue if that is something you are interested in. (and a PR to add the capability if you are up for it!)

<@U05C2NE9UTS> pls don’t post the same thread multiple times in channels and across channels. We try to respond to all messages when we have time. Some issues require larger blocks of time, more effort/investigation, or a specific person’s help. For all these reasons, you might see us responding to folks out of order.

load-test doesn't support this today. you can def modify it to do so though :slightly_smiling_face: (one benefit of being open source)

you could also just send out custom data messages from a single host at that rate, and it should accomplish similar goals (if it was testing how *your* server handles the load).

in general we are not concerned about the rate of data messages, since they are tiny compared to video data

The way the application is structured, messages needs to be sent from each of the participants. With this said, let me have a look on how I could update the load-test then :slightly_smiling_face: Thanks <@U01KZ61GV5Z>

adding an option to customize the http client used

example:
```
    RoomServiceClient.create(
            "host",
            "api",
            "secret",
            false,
            (OkHttpClient.Builder builder) -&gt; {
                InetAddress addr = InetAddress.getByName("<http://www.example.com|www.example.com>");
                builder.proxy(
                        new Proxy(
                                Proxy.Type.HTTP,
                                new InetSocketAddress(addr, 80)
                        )
                );
            }
    );```


Thanks for the lightning fast reaction <@U01KZ0SCDKL> and <@U01NZKTNE1H> :zap: :bow:

image.png

<@U01NZKTNE1H> unfortunately it looks like something went wrong with the build. When fetching the dependency from Maven it looks like the jar file is missing the newly added `OkHttpConfigurator` class file.

<@U01NZKTNE1H> could you see the same thing in the jars you build?

Yeah, looks like mixing java/kotlin doesn't play well with our build scripts. I've swapped that class out now, try 0.5.6

looking good now, again thanks for the fast response <@U01NZKTNE1H>

<@U04S9JQDA8Y> please update to 1.7.2, the latest release. Let us know if it reproduces there. We are unable to help with older versions of the software.

Created local sdp(offer, when publish the video track):
```v=0
o=- 5823229336453791980 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS PA_ZwbMA6gwsbbi
m=video 9 UDP/TLS/RTP/SAVPF 96 97 35 36 98 99 100 101 127 122 125 121 124 107 108 109 123 120 114 115 116
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:xT6H
a=ice-pwd:bJdzVwPsVqzbbwSD0vBmajdm
a=ice-options:trickle
a=fingerprint:sha-256 2E:4E:D9:7E:59:70:A0:30:E7:15:CC:69:34:AD:0C:34:DB:FE:CE:A4:A2:50:12:B7:A6:D7:BA:84:4A:66:3A:80
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 <http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time>
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=extmap:5 <http://www.webrtc.org/experiments/rtp-hdrext/playout-delay>
a=extmap:6 <http://www.webrtc.org/experiments/rtp-hdrext/video-content-type>
a=extmap:7 <http://www.webrtc.org/experiments/rtp-hdrext/video-timing>
a=extmap:8 <http://www.webrtc.org/experiments/rtp-hdrext/color-space>
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendonly
a=msid:PA_ZwbMA6gwsbbi 4be2b3e9-7baa-4075-bb75-c6b55e0bd9bf
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:35 AV1/90000
a=rtcp-fb:35 goog-remb
a=rtcp-fb:35 transport-cc
a=rtcp-fb:35 ccm fir
a=rtcp-fb:35 nack
a=rtcp-fb:35 nack pli
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=125
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=124
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:123 H265/90000
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=fmtp:123 level-id=120;profile-id=1;profile-space=0;tier-flag=0
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=123
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 ulpfec/90000
a=ssrc-group:FID 2221504740 1316308789
a=ssrc:2221504740 cname:1guiifXI9pT229lr
a=ssrc:2221504740 msid:PA_ZwbMA6gwsbbi 4be2b3e9-7baa-4075-bb75-c6b55e0bd9bf
a=ssrc:1316308789 cname:1guiifXI9pT229lr
a=ssrc:1316308789 msid:PA_ZwbMA6gwsbbi 4be2b3e9-7baa-4075-bb75-c6b55e0bd9bf```
Received remote sdp(answer by livekit):
```v=0
o=- 7437225389344299552 1688096144 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 A7:89:CA:C5:C6:89:9D:B8:18:E8:00:43:7D:F6:00:BF:93:A4:40:D7:C0:00:0E:29:BA:D7:AC:80:09:2F:48:A0
a=ice-lite
a=extmap-allow-mixed
a=group:BUNDLE 0
m=video 9 UDP/TLS/RTP/SAVPF 124 108
c=IN IP4 0.0.0.0
a=setup:active
a=mid:0
a=ice-ufrag:QHrRjNHLoIKXQtYB
a=ice-pwd:GHbuZhGhaZCfMATczNdHtRlPqbyfrrVB
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:124 H264/90000
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=rtpmap:108 H264/90000
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=extmap:4 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=recvonly```
Created local sdp again, (`OnRenegotiationNeeded()` callback triggered, after removing the track from pc):
```v=0
o=- 5823229336453791980 3 IN IP4 127.0.0.1
s=-
t=0 0
a=extmap-allow-mixed
a=msid-semantic: WMS
m=video 0 UDP/TLS/RTP/SAVPF 96 97 35 36 98 99 100 101 127 122 125 121 124 107 108 109 123 120 114 115 116
c=IN IP4 169.254.83.107
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1691626629 1 udp 2122260223 169.254.83.107 53434 typ host generation 0 network-id 8 network-cost 50
a=candidate:3143976315 1 udp 2122199807 fdae:5d54:7d99::9526:61bc:9e61:85f9 53435 typ host generation 0 network-id 2
a=candidate:3594733067 1 udp 2122134271 fdae:5d54:7d99::956b:41d:4331:3103 53436 typ host generation 0 network-id 3
a=candidate:3293016977 1 udp 2122068735 fdae:5d54:7d99::d728:db91:9b8c:85fb 53437 typ host generation 0 network-id 4
a=candidate:36268794 1 udp 2122003199 fdae:5d54:7d99::eb2 53438 typ host generation 0 network-id 5
a=candidate:3708875704 1 udp 2121932543 192.168.99.32 53439 typ host generation 0 network-id 1
a=ice-ufrag:xT6H
a=ice-pwd:bJdzVwPsVqzbbwSD0vBmajdm
a=ice-options:trickle
a=fingerprint:sha-256 2E:4E:D9:7E:59:70:A0:30:E7:15:CC:69:34:AD:0C:34:DB:FE:CE:A4:A2:50:12:B7:A6:D7:BA:84:4A:66:3A:80
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 <http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time>
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=extmap:5 <http://www.webrtc.org/experiments/rtp-hdrext/playout-delay>
a=extmap:6 <http://www.webrtc.org/experiments/rtp-hdrext/video-content-type>
a=extmap:7 <http://www.webrtc.org/experiments/rtp-hdrext/video-timing>
a=extmap:8 <http://www.webrtc.org/experiments/rtp-hdrext/color-space>
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=inactive
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:35 AV1/90000
a=rtcp-fb:35 goog-remb
a=rtcp-fb:35 transport-cc
a=rtcp-fb:35 ccm fir
a=rtcp-fb:35 nack
a=rtcp-fb:35 nack pli
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=125
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=124
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:123 H265/90000
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=fmtp:123 level-id=120;profile-id=1;profile-space=0;tier-flag=0
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=123
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 ulpfec/90000```
Received the remote sdp from livekit:
```v=0
o=- 7437225389344299552 1688096145 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 A7:89:CA:C5:C6:89:9D:B8:18:E8:00:43:7D:F6:00:BF:93:A4:40:D7:C0:00:0E:29:BA:D7:AC:80:09:2F:48:A0
a=ice-lite
a=extmap-allow-mixed
a=group:BUNDLE 0
m=video 9 UDP/TLS/RTP/SAVPF 124 108
c=IN IP4 0.0.0.0
a=setup:active
a=mid:0
a=ice-ufrag:QHrRjNHLoIKXQtYB
a=ice-pwd:GHbuZhGhaZCfMATczNdHtRlPqbyfrrVB
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:124 H264/90000
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=rtpmap:108 H264/90000
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=extmap:4 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=inactive
.
.
.
a=candidate:4267975093 1 tcp 2124414975 192.168.99.64 7881 typ host tcptype passive
a=candidate:4267975093 2 tcp 2124414975 192.168.99.64 7881 typ host tcptype passive
a=end-of-candidates```
---
Error occurred:
```[<http://sdp_offer_answer.cc:758|sdp_offer_answer.cc:758>]: Failed to set remote answer sdp: A BUNDLE group was added in the answer that did not exist in the offer.```
Could anybody give some hints, thanks!

thanks for your reply, I only set the `sdp_semantics` to`SdpSemantics::kUnifiedPlan`, other configs are left to default.

I just tried the Android client <https://github.com/livekit/client-sdk-android|sdk> demo, and I met the same issue `E/RTCEngine$onAnswer: error setting remote description for answer: Failed to set remote answer sdp: A BUNDLE group in answer contains a MID='3' that was not in the offered group.`  I only modified <https://github.com/livekit/client-sdk-android/blob/main/livekit-android-sdk/src/main/java/io/livekit/android/room/participant/LocalParticipant.kt#L471-L479|this code block> to
```val transceivers = engine.publisher.peerConnection.transceivers
for (t in transceivers) {
    if (t.sender.id() == track.rtcTrack.id()) {
        engine.publisher.peerConnection.removeTrack(t.sender)
        t.stop()
    }
}```
After I did publish &amp; unpublish the screen several times, I can see more m-lines generated into the local offer sdp if I did NOT change the code, and the memory usage will keep growing until `pc.close()` got called.

According to this <https://chromestatus.com/feature/5410592384876544|link>:
&gt; Stopping a transceiver allows freeing its network port, encoder and decoder resources. This also makes its m= section in the SDP reusable by future transceivers, preventing the SDP from growing indefinitely as transceivers are added and removed.
I should call the `transceiver.stop()` if I need to publish/unpublish the same video source repeatedly, could this be a bug related to pion?

undoing my previous response because I misunderstood your question.

it is possible this is due to a behavior in Pion not correctly removing the m= section. do you mind filing an issue in livekit/livekit?

Android does not use Pion. what you are seeing is libwebrtc behavior.

FWIW, we recommend using publisher mute instead of fully unpublishing for this reason. it will also be a faster way of republishing since it wouldn't require a renegotiation to start sending bits again (this is automatic if you use the `setCameraEnabled` APIs)

Thanks for your reply and sorry for my bad English, I am willing to file an issue (please give me some time to reorganize my words).
&gt; Android does not use Pion. what you are seeing is libwebrtc behavior.
You are right, this is what I meant, I have tried use two clients (one for publishing, another for subscribing) without connect to the SFU server, and they did work fine (for the publisher side: add transceiver, stop transceiver again and again..., the m= section was removed but the a=mid was increase).
&gt;  we recommend using publisher mute instead of fully unpublishing
This is a very good idea, but if I need to publish multi video sources (add multi transceivers to the pc) to the SFU, this could be an issue because the encoders &amp; ports are not released. I did not find a public API to remove the transceiver and I guess its not support by the WebRTC stack.

our clients should support `replaceTrack` to switch between different sources.

on mid increasing, I believe that should be fine.

Already opened a new issue, <https://github.com/livekit/livekit/issues/1850>
thank you.

that sounds like you ran out of Egress workers. please refer to <https://docs.livekit.io/oss/deployment/egress/#ensuring-availability|this section> for details.

Yes, a client can connect to as many rooms as you like. 

The limitation to be aware of is the same client (dictated by participant identity) cannot have multiple connections to the same room. If you try that, the older connection to the room is dropped.

I might have found my issue actually, and it seems to be related to :

```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:

```const sendMessage = (eventRequest: EventRequest) =&gt; {
    const data = encoder.encode(JSON.stringify(eventRequest));
    room.localParticipant.publishData(data, DataPacket_Kind.RELIABLE, [
      sid,
    ]);
  };```


I'm not able to reproduce this.. sending a data message from JS and I do get the participant in Go.

<@U01KZ61GV5Z> 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.

I could agree that this happens more often for me to return nil but sometimes it does return the object.

<@U01KZ61GV5Z>, 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. :man-shrugging:

I ran into something similate with cli...
```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```


<@U032TUAL4KT> 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

<@U01KZ61GV5Z>, 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.

Regarding the Panic, yes I do have Git LFS installed. :confused:

hmm that's interesting. how do you reproduce it?

```$ 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```

did you build this CLI or is it using our official builds?

so the most likely issue is still Git LFS.

the placeholder files you've got in place are probably not valid video files

<@U01KZ61GV5Z> what's the status of this problem so far?
I still have this problem :slightly_frowning_face:

<@U0575PCGSN4>, 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.

<@U032TUAL4KT> 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? :thinking_face:

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 ...

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.

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.

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.

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 :slightly_frowning_face:
reproducing that in order to test that 1 sec hold that you said is hard :expressionless:
I will notify you next time that happened.

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.

Oh well this makes a whole lot of sense now. Thanks for the clarification <@U01KZ61GV5Z> :pray: :fire:

```s023-07-03T12:22:41.523Z    INFO    egress  redis/redis.go:92   connecting to redis {"nodeID": "NE_oAL7YXrDkx5P", "clusterID": "", "simple": true, "addr": "redis-svc:6379"}
2023-07-03T12:22:41.563Z    INFO    egress  stats/monitor.go:135    available CPU cores: 6 max cost: 4.000000   {"nodeID": "NE_oAL7YXrDkx5P", "clusterID": ""}
2023-07-03T12:22:41.581Z    DEBUG   egress  service/debug.go:24 debug handler disabled  {"nodeID": "NE_oAL7YXrDkx5P", "clusterID": ""}
2023-07-03T12:22:41.581Z    DEBUG   egress  service/service.go:77   starting service    {"nodeID": "NE_oAL7YXrDkx5P", "clusterID": "", "version": "1.7.3"}
2023-07-03T12:22:41.581Z    DEBUG   egress  service/templates_server.go:24  starting template server on address localhost:7980  {"nodeID": "NE_oAL7YXrDkx5P", "clusterID": ""}
2023-07-03T12:22:41.585Z    DEBUG   egress  service/service_deprecated.go:27    service ready   {"nodeID": "NE_oAL7YXrDkx5P", "clusterID": ""}
2023-07-03T12:22:52.163Z    INFO    egress  service/service.go:111  request received    {"nodeID": "NE_oAL7YXrDkx5P", "clusterID": "", "egressID": "EG_8tr8kWochxP4"}
2023-07-03T12:22:52.165Z    INFO    egress  service/service.go:119  request validated   {"nodeID": "NE_oAL7YXrDkx5P", "clusterID": "", "egressID": "EG_8tr8kWochxP4", "request_type": "room_composite", "output_type": "file", "room": "my-room", "request": {"RoomComposite":{"room_name":"my-room","layout":"speaker","Output":{"File":{"file_type":1,"filepath":"livekit-demo/","Output":null}},"Options":null}}}
2023-07-03T12:22:52.262Z    DEBUG   egress  server/main.go:169  handler launched    {"nodeID": "NE_oAL7YXrDkx5P", "handlerID": "EGH_SYVBrA7QnjD5", "clusterID": "", "egressID": "EG_8tr8kWochxP4"}
2023-07-03T12:22:52.263Z    INFO    egress  redis/redis.go:92   connecting to redis {"nodeID": "NE_oAL7YXrDkx5P", "handlerID": "EGH_SYVBrA7QnjD5", "clusterID": "", "egressID": "EG_8tr8kWochxP4", "simple": true, "addr": "redis-svc:6379"}
2023-07-03T12:22:52.285Z    DEBUG   egress  source/web.go:143   launching xvfb  {"nodeID": "NE_oAL7YXrDkx5P", "handlerID": "EGH_SYVBrA7QnjD5", "clusterID": "", "egressID": "EG_8tr8kWochxP4", "display": ":1033851095", "dims": "1920x1080x24"}
2023-07-03T12:22:52.286Z    DEBUG   egress  source/web.go:174   launching chrome    {"nodeID": "NE_oAL7YXrDkx5P", "handlerID": "EGH_SYVBrA7QnjD5", "clusterID": "", "egressID": "EG_8tr8kWochxP4", "url": "<http://localhost:7980/?layout=speaker&amp;token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2ODg0NzMzNzIsImlzcyI6ImRldmtleSIsIm5iZiI6MTY4ODM4Njk3Miwic3ViIjoiRUdfOHRyOGtXb2NoeFA0IiwidmlkZW8iOnsiY2FuUHVibGlzaCI6ZmFsc2UsImNhblB1Ymxpc2hEYXRhIjpmYWxzZSwiY2FuU3Vic2NyaWJlIjp0cnVlLCJoaWRkZW4iOnRydWUsInJlY29yZGVyIjp0cnVlLCJyb29tIjoibXktcm9vbSIsInJvb21Kb2luIjp0cnVlfX0.9I9nfQCehlgyI-96fbAm-yCy61_Owsm_4RmDjvxKSZs&amp;url=ws%3A%2F%2Flivekit%3A7880>"}
2023-07-03T12:22:52.958Z    DEBUG   egress  pipeline/pipeline.go:166    waiting for start signal    {"nodeID": "NE_oAL7YXrDkx5P", "handlerID": "EGH_SYVBrA7QnjD5", "clusterID": "", "egressID": "EG_8tr8kWochxP4"}
2023-07-03T12:23:07.987Z    INFO    egress  source/web.go:252   chrome: END_RECORDING   {"nodeID": "NE_oAL7YXrDkx5P", "handlerID": "EGH_SYVBrA7QnjD5", "clusterID": "", "egressID": "EG_8tr8kWochxP4"}```

did anyone publish to the room? the default template would start recording only when the first track has been published: <https://github.com/livekit/egress/blob/main/template-default/src/Room.tsx#L66>

<@U01KZ61GV5Z> I'm calling startRoomCompositeEgress as soon as the room is created, using wehooks event. And then media is publish before the "waiting for start signal" (not sure if it is relevant or not).
But on the webhook I don't receive track_published event. Which makes me think that something is not configured properly.
```leiaa-interview-service-livekit-1         | {"level":"info","ts":1688466045.5395367,"logger":"livekit","caller":"rtc/participant.go:1198","msg":"mediaTrack published","room":"my-room","roomID":"RM_J6jCvyuTYvUF","participant":"rabreu","pID":"PA_XbEzyuzRzcgU","remote":false,"kind":"video","trackID":"TR_VCAojGm4PxGbf2","webrtcTrackID":"b66243bf-939b-44e7-923b-57ea7b48e856","rid":"q","SSRC":4128474531,"mime":"video/VP8"}
leiaa-interview-service-livekit-1         | {"level":"info","ts":1688466045.5500493,"logger":"livekit","caller":"rtc/participant.go:1198","msg":"mediaTrack published","room":"my-room","roomID":"RM_J6jCvyuTYvUF","participant":"rabreu","pID":"PA_XbEzyuzRzcgU","remote":false,"kind":"video","trackID":"TR_VCAojGm4PxGbf2","webrtcTrackID":"b66243bf-939b-44e7-923b-57ea7b48e856","rid":"h","SSRC":2569397893,"mime":"video/VP8"}
leiaa-interview-service-livekit-1         | {"level":"info","ts":1688466045.552106,"logger":"livekit","caller":"rtc/participant.go:1198","msg":"mediaTrack published","room":"my-room","roomID":"RM_J6jCvyuTYvUF","participant":"rabreu","pID":"PA_XbEzyuzRzcgU","remote":false,"kind":"audio","trackID":"TR_AMdeXF2r7AaQqh","webrtcTrackID":"6dd96904-53f0-42fc-8e50-3d8fbda6d7ae","rid":"","SSRC":3363822786,"mime":"audio/red"}
leiaa-interview-service-livekit-1         | {"level":"info","ts":1688466045.7664754,"logger":"livekit","caller":"rtc/participant.go:1198","msg":"mediaTrack published","room":"my-room","roomID":"RM_J6jCvyuTYvUF","participant":"rabreu","pID":"PA_XbEzyuzRzcgU","remote":false,"kind":"video","trackID":"TR_VCAojGm4PxGbf2","webrtcTrackID":"b66243bf-939b-44e7-923b-57ea7b48e856","rid":"f","SSRC":3892662080,"mime":"video/VP8"}```

I think the bigger problem is not receiving the event swith this livekit version, I feel that something might be missing in my config:
```port: 7880
rtc:
    tcp_port: 7881
    use_external_ip: true
room:
    auto_create: true
redis:
  address: redis-svc:6379
keys:
    devkey: &lt;mykey&gt;
logging:
    json: true
    level: info
    pion_level: debug
webhook:
    api_key: devkey
    urls:
        - "<http://backend-server:3010/webhooks>"
turn:
    enabled: true
    udp_port: 443```

Livekit works but I don't receive the events

your config looks correct. it's not clear why your webhooks aren't being received.. are there any errors in livekit server logs?

No, not even warnings, I downgraded livekit to version 1.4.1, and the webhooks work fine now.

Although now I get all the events, I needed to also downgrade egress because the Start signal wouldn’t trigger for some reason. I’m not sure if is something related to the “psrpc”, or some additional config. Although version 1,6 seem to work properly in terms of the described flow in the docs.

Anyway the recordings seem to end after aprox 15 seconds and the file is empty. I’m using the default room composite but tried track and web it does the same thing :thinking_face: 


<@U01KZ61GV5Z>
Do you have any ideia of what might be happening here? The rest works fine I can make calls normally but for recordings, doesn't work.

I'm running everything through a docker compose don't know if that's relevant here.

sorry, it's not clear what's happening. as noted, Egress does not appear to be recording because `START_RECORDING` was not logged to console. try using our default templates and ensure someone is actually publishing a `Source.VIDEO` track to the room

in terms of webhook, if configured properly, you should see these log lines:
```2023-07-06T23:48:16.312-0700	INFO	livekit	webhook/url_notifier.go```

<@U052Z93P8KA> can you provide more details here? which SDK are you using and on which device?

what does your publish settings look like? audio quality is directly related to the publishing bitrate.

lastly, can you reproduce this with <http://meet.livekit.io|meet.livekit.io> ?

<https://github.com/livekit/client-sdk-android> is currently 1.1.10
This is the problem on all Android devices. In comparison, the sound is good on the web part and poor on Android devices and compared to Google Meet

What I meant is, have you tried using <http://meet.livekit.io|meet.livekit.io> on the same Android device? how is the audio quality there?

You can with web/room composite if you use a custom template and call endRecording on a timer. With track or track composite you will need to send a stop request

we do support music streaming. however, it's not currently trivial to stream a music file from Android.

we do have an <https://github.com/livekit-examples/spatial-audio/blob/main/src/controller/JukeBoxProvider.tsx|example app> showing you how this could be done from the browser SDK.

thanks, do you have android kotlin example?

we'll look into how this could be done more easily.

Hi david
Hope you're doing well

I am assuming we can use this frontend code as a inspiration to write code in kotlin once we have done that will it solve our problem of sending music to stream inside room ?

Unfortunately not.. Kotlin SDK doesn't support publishing of audio samples. I would recommend doing this from the backend. Take a look at our <https://github.com/livekit/livekit-cli|CLI> and <https://github.com/livekit/server-sdk-go|Go SDK>

Here is the code:

```      const room = await roomState.connect(url, token, undefined);
      
      const videoTrack = await createLocalVideoTrack({
        deviceId: { exact: deviceId },
        // preset resolutions
        resolution: VideoPresets.h1080,
      });

      await room.localParticipant.publishTrack(videoTrack);```

CleanShot 2023-07-05 at 08.16.35@2x.png

This message contains interactive elements.

Note that i need to use the `exact deviceId` so that it connects the correct device to the room. Without the `exact` keyword it doesn't add the correct device.

just to confirm, does the device support capturing at 1080p?

this is strange that it's not honoring the specified dimensions.

what happens when you acquire the track manually with `getUserMedia`? does it give you 1080p?

hi <@U01KZ61GV5Z>.
• The device I'm testing with supports 4k (it's a 360 camera)
• `getUserMedia` returns the same  `640x480` dimensions


Also tested it just now with the built in Facetime camera on the mac M2. Still `640x480`. Very strange.

that sounds like a compatibility issue with the browser and the 360 camera? we would basically pass on the call to getUserMedia. It's worth trying different combination of getUserMedia calls, if any of them can successfully retrieve 4k, then you could do the same with livekit

Thanks for your help on this David. I found out that the camera resource was being used in the background (I hadn't unmounted the component correctly), which caused the camera to connect at a lower resolution.

it is possible to have multiple Ingress participants in the room. However, they need to use a unique identity.

LiveKit enforces unique identities in the room. The behavior you are seeing is what happens when they are sharing the same identity (i.e. new user with that identity will "kick" the old user out)

It seems cloud ingress is limited to 2 sessions. I am testing the WHIP endpoint. Is it correct that I can’t publish more than 2 sources?

are you on a free plan? if so there is a limit of a single concurrent ingress: <https://docs.livekit.io/cloud/quotas-and-limits/>

no, we are using the self hosting way. but i figured out the problem. i have used the same participant name when adding a new ingress :see_no_evil: many thanks for your response

```livekit-client: 1.6.5
livekit-server-sdk: 1.1.0```

hi!
it would be great to have a bit more info around this:
what OS are you seeing this on?
Can you paste the full livekit-client logs shortly before and after this happens, with debug logging enabled (also including the whole error message)?

Hi <@U02EU2ZPTQU>

We are facing the issue with restart tracks in both *iOS* and *Android* occasionally.

The browser log while facing the issue is " *Uncaught (in promise) DOMException: Could not start video source* "

For following code

restartTrack({
        facingMode: "environment" ,
      }

thanks, this is likely a `NotReadableError` which points to hardware/OS level problems (see <https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia#exceptions>). This error could also surface if the device is in use already.
there’s unfortunately not much we can do about this. Would be best to put the method in a `try/catch` clause and either retry or give up depending on your needs

this means traefik isn't configured probably. you can test by going to the URL with https://&lt;<http://your-domain.com|your-domain.com>&gt;

it should return `OK` when things have been setup correctly

not currently, but this should be very straight forward to add. If you are interested in making a PR for it!

Hello Livekit Community.

Please Look this result:
Case 1、real user:    3 participants , video and audio

Case 2、benchmark:  2 publishers 3 subscribers , video only


Both cases have the same number of subscriptions
Why are the bandwidths so different in these two cases

Hello Livekit Community.

Please Look this result:
Case 1、real user:    3 participants , video only
<https://my-bucket-0-1.oss-cn-shanghai.aliyuncs.com/WechatIMG582.png>

Case 2、benchmark:  3 publishers 2 subscribers , video only
 Summary | Tester | Tracks | Bitrate        | Total Dropped | Error
    | Sub 0 | 2/2  | 1.3mbps        | 5611 (3.097%) | -
    | Sub 1 | 2/2  | 1.5mbps        | 856 (0.416%)  | -
    | Sub 2 | 2/2  | 1.4mbps        | 3600 (1.875%) | -
    | Total | 6/6  | 4.2mbps (1.4mbps avg) | 10067 (1.738%) | 0


Both cases have the same number of subscriptions
Why are the bandwidths so different in these two cases

WechatIMG582.png

WechatIMG586.png

`bitrate` is a newer field (found in `IngressAudioEncodingOptions`)

I tried upgrading both my cli and server libraries to latest version and problem persists. Seems that the error is being thrown on the server side, even direct curl has this error. 

Hi there, still receiving this error whenever I try and list the ingresses on my livekit cloud account (and now I see this thread should have been posted in <#C048FRL1N2C|helpdesk-cloud>)

```$ livekit-cli list-ingress --api-key API******** --api-secret ******** --url https://**********.livekit.cloud
twirp error internal: rpc error: code = Internal desc = proto: (line 1:2): unknown field "bitrate"```

hmm there must be some incompatible Ingresses that are left in your account (from earlier in the beta). It would make sense to clean them out.

If I have your permission to do so, I can attempt to delete the old entries from the DB.

<@U01KZ61GV5Z> yes thanks, permission granted.

reset complete, it shouldn't error for you any longer

Thanks, all fixed :slightly_smiling_face:

Hey <@U05G6PRBAV7> , you can include the minified client SDK directly like this:

```&lt;script src="<https://cdn.jsdelivr.net/npm/livekit-client/dist/livekit-client.umd.min.js>"&gt;&lt;/script&gt;```

Many thanks for that <@U01KZ61GV5Z> - that's great!

I'm trying to just put together the demo from the JS SDK docs to see how it all works, but including the js file mentioned above and then trying to run the rest of the sample code is giving me a ReferenceError: Room is not defined. I'm guessing that's because I'm not importing Room as the JS isn't being loaded as a module now?

Trying to include the js file mentioned above as a module gives me a different error: "ambiguous indirect export: Room"

Many thanks for the help - appreciate this is probably just something really basic I'm missing!

Code:

```&lt;script src="<https://cdn.jsdelivr.net/npm/livekit-client/dist/livekit-client.umd.min.js>"&gt;&lt;/script&gt;
&lt;script&gt;
// creates a new room with options
const room = new Room({
  // automatically manage subscribed video quality
  adaptiveStream: true,

  // optimize publishing bandwidth and CPU for published tracks
  dynacast: true,

  // default capture settings
  videoCaptureDefaults: {
    resolution: VideoPresets.h720.resolution,
  },
});
&lt;/script&gt;```

ah sorry I forgot to mention, you would need to prefix the class names with `LivekitClient.`, i.e. `LivekitClient.Room`

Hi <@U01KZ61GV5Z>,

Thanks for the reply - I've just about got it working now, and it's pretty awesome! I think this is exactly what we were looking for - can't believe I hadn't found it before!

I did just have three questions about some potential snags I've hit while developing:

1. Every now and then, I'm getting a strange issue where, when joining as a receiving client (not broadcasting, only receiving), it connects to the websocket server, then seemingly sits idle for so long it disconnects from the server. I get a log in the console saying "closing engine", and "skipping incoming track after Room disconnected" and then a fair few seconds later, it reconnects to the server and gets the stream properly. I'm not sure why it seems to sit idle for so long, but it's looking like it's timing out. Looking at the cloud logs on the Livekit site, it looks like it's taking 250 - 500ms to connect to the websocket server, which seems a bit on the long side. Not sure if it's related!
2. In one of your demos (<https://blog.livekit.io/livekit-one-dot-zero/>) there's a live info feed for the stream res and bitrate. Is it possible to access this myself with the JS SDK for debugging?
3. Just to clarify pricing - your docs mention there's a 100 participant limit in rooms on free accounts, but that paid can scale to 100k users per room. Is it as simple as that, that adding credit card details lets you scale to 100k users if you need to, or are there any other charges?
Thanks again for all the help!

Hey <@U05G6PRBAV7>, I'm glad you got it to work! To answer your questions:
1. do you have logs from the JS SDK when this happens? it'll be helpful to turn on debug logging `setLogLevel('debug')` so we can see what's going on.
2. Yeah, you can access the current publishing bitrate via `LocalTrack.currentBitrate`, and receiving bitrate via `RemoteTrack.currentBitrate` . Getting the FPS is a bit more convoluted, I've attached a snippet of how it can be retrieved from a `RemoteVideoTrack` object.
3. Yes, there are no additional charge in order to scale to 100k. You'll be able to request higher concurrent limits with a paid plan. more details <https://docs.livekit.io/cloud/quotas-and-limits/|here>
```const stats = await remoteVideoTrack.receiver.getStats();
          stats.forEach((val: any) =&gt; {
            if (val.type === "inbound-rtp") {
              if (val["framesPerSecond"]) {
                console.log('current fps', val["framesPerSecond"]);
              }
            }
          });```

log.jpg

console-export-2023-7-25_14-32-10.txt

Hi <@U01KZ61GV5Z>,

Many thanks for the reply! I managed to get it to do it again with debug turned on. This time it didn't actually start showing the video at all, so it looks like it only sometimes manages to recover. I'm not sure of the best way to save it, so I shared the console export., but have also included a patched together screenshot of the logs.

If I refresh the broadcaster's page, it'll all start come through fine on the receiver's end, but I guess it's meant to do that without the refresh!

Is this happening when the user initially connected to the server? or did it happen after a period of time?

Do you happen to have the link to the session from livekit cloud? we can take a look on our side to see if we can spot anything.

Hi David,

Sorry for the huge delay in getting back to you - I've been away and then bogged down on other projects, but back looking at this now.

It's happening on initially connecting to the server - in fact, I've just had it happen again if that helps. I think this was the session it was in (<https://cloud.livekit.io/projects/p_2cj885wmep8/sessions/RM_hAwK63wgMPau>) and it was using the token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2aWRlbyI6eyJyb29tSm9pbiI6dHJ1ZSwicm9vbSI6ImUxNzQifSwiaWF0IjoxNjk0NTI5MDExLCJuYmYiOjE2OTQ1MjkwMTEsImV4cCI6MTY5NDU1MDYxMSwiaXNzIjoiQVBJN0o0em9rRVcydmhCIiwic3ViIjoicW0iLCJqdGkiOiJxbSJ9.g7suAsFfnD8Sl0A5naZ4uDnsnTVyupNBW5bWMrC0dxA

connected to Livekit Server edition: 1, version: 1.4.4, protocol: 10, region: Germany, nodeId: NM_DFRA1A_bVaFrWCAQJBH,

It disconnected, changed region to dfra1a, then reconnected and seemingly worked.

Not sure if this link will work, but this should also be another session where the same happened <https://cloud.livekit.io/projects/p_2cj885wmep8/sessions/RM_UFTF59mzvTnJ/participants/PA_fHTMmDrWeqPW>

Hi <@U01KZ61GV5Z>, sorry to be tagging you but I know this is a pretty old thread and I'm not sure if it still sends notifications for that! I just wanted to let you know it seems to be happening a lot this morning, with a slightly different error messag: initial connection failed, retrying with another region
Object { nextUrl: "<https://warp-point-kk928krm.dfra1a.production.livekit.cloud>" }

I believe this is one of the sessions it happened in <https://cloud.livekit.io/projects/p_2cj885wmep8/sessions/RM_hW6hy5SQU8Xs/participants/PA_hT2zT4Tw2J26>. I think there should be several around it though, as it seems to be happening every time at the moment

Hey Ian, no worries. Thank you for bringing this to my attention. I'll check with the team to see what might be happening

<@U05FE5Q62HJ> What issues are you seeing? can you elaborate? CC: <@U01NZKTNE1H>

are there any error logs that appear when you try to connect?

Screenshot 2023-07-07 at 17.57.42.png

Hi, <@U01NZKTNE1H>
In the screenshot, you can see the error that is caught in the catch block. I'm also copying the fragment of my code for you. The token and the URL that I pass as parameters are correct. According to this <https://livekit.io/connection-test>, it should work, and it also works in the sample app. Thank you

``` const RoomPage = ({ route }) =&gt; {
  const [, setIsConnected] = useState(false)
  const [room] = useState(
    () =&gt; new Room({ adaptiveStream: { pixelDensity: 'screen' } }),
  )
  const { participants } = useRoom(room)
  const { url, token } = route.params
  const [isCameraFrontFacing, setCameraFrontFacing] = useState(true)


  console.log(room)
  useEffect(() =&gt; {
    let connect = async () =&gt; {
      try {
        await AudioSession.startAudioSession()
        await room.connect(url, token, {})
        setIsConnected(true)
      } catch (err) {
        console.log(err)
      }
    }

    connect()

    return () =&gt; {
      room.disconnect()
      AudioSession.stopAudioSession()
    }
  }, [url, token, room])```

Error:

```TypeError: n.removeEventListener is not a function
    at Ko.handleDisconnect (livekit-client.umd.js:1)
    at Ko._callee115$ (livekit-client.umd.js:1)
    at tryCatch (regeneratorRuntime.js:44)
    at Generator.&lt;anonymous&gt; (regeneratorRuntime.js:125)
    at Generator.throw (regeneratorRuntime.js:69)
    at a (livekit-client.umd.js:1)
    at tryCallOne (core.js:37)
    at core.js:123
    at JSTimers.js:248
    at _callTimer (JSTimers.js:112)```

which version of livekit-client are you using? it appears to be an old version that didn't properly check for RN during removeEventListener

I am using this:
```"@livekit/react-native": "^1.1.2",
"@livekit/react-native-webrtc": "^104.0.1",```

can you add a line for `'livekit-client': '^1.12.0` ?

Screenshot 2023-07-07 at 19.35.14.png

same error <@U01KZ61GV5Z>, but when I installed the package, it gave me the following warning.
```"@livekit/react-native": "^1.1.2",
"@livekit/react-native-webrtc": "^104.0.1",
"livekit-client": "^1.12.0",```

I added this line    "./package.json": "./package.json", The warning no longer appears, but the error that comes through the catch remains the same.
``` "exports": {
    ".": {
      "types": "./dist/src/index.d.ts",
      "import": "./dist/livekit-client.esm.mjs",
      "require": "./dist/livekit-client.umd.js"
    },
    "./e2ee-worker": {
      "types": "./dist/src/e2ee/worker/e2ee.worker.d.ts",
      "import": "./dist/livekit-client.e2ee.worker.mjs",
      "require": "./dist/livekit-client.e2ee.worker.js"
    },
    "./package.json": "./package.json"
  },```

hmm, tried running it on 0.66.5 (there was a breaking bug on 0.66.4 that prevents android builds), didn’t run into this issue. did you remember to call `registerGlobals()` in your index.js file?

the only other thing I can think of is you have `document` defined by something in your app, and that’s making our library think it’s being run on web (and calling web-only methods)

Hello, thank you very much for your help. <@U01NZKTNE1H> <@U01KZ61GV5Z>
Perhaps this information will be useful to future colleagues, the observable-hooks library hinders the proper functioning of LiveKit.

thanks for identifying the library, we’ll see if we can fix this up

<@U05FE5Q62HJ> hmm, I wasn’t able to reproduce it with the observable-hooks library. is it possible to upload a sample project that repros this issue?

maybe is this library    "@rn-matrix/core" is causing the error.   I use observable-hooks  and rn-matrix/core tooto, I updated the library obsable-hooks to the last version in my app and in the rn-matrix/core. and the app continue failed.

But when I delete those libreria, livekit start works <@U01NZKTNE1H>

<@U05FH67L0TH>

server grant audio only permission
<https://docs.livekit.io/concepts/authentication/#video-grant>

client just attach audio track

<https://docs.livekit.io/getting-started/quickstarts/flutter/#2.-connect-to-a-room,-publish-video-&amp;-audio>