LiveKit Community

```function LiveKitTester() {
  const [clicked, setClicked] = useState(false);
  if (!clicked)
    return &lt;button onClick={() =&gt; setClicked(true)}&gt;click me&lt;/button&gt;;
  return &lt;LiveKitRoom url="<ws://localhost:7880>" token={liveKitToken} /&gt;;
}```


anything particularly off about this code?

actually, I'll try this exact piece of code on my other setup, see if that works

huh, this piece of code works when copied over to my other setup

at this point I'll assume this is a dependency issue

<@U03E06EMP33> could you please :thread: these messages? :pray:

ok, it's not an issue with the dependencies, I'm having a hard time isolating this

even when concurrent rendering is enabled

I've torn it down into complete barebones

this heavily suggests that this is a dependency issue of some sort

You may need to hire a coach to help you learn.. Keep your questions simple and its more likely others can support.

Your repo looks like its not passing in a token. Just an empty string. Did you make a dev token with your livekit-server? I made that mistake a few days ago.

I'm also learning, so, I'd be down to meet on Zoom if you want to pair code (not paid coaching.) Sent you a PM.

&gt;  Your repo looks like its not passing in a token. Just an empty string. Did you make a dev token with your livekit-server? I made that mistake a few days ago.
I did test it with the token, I just removed it from the commit

it is related to concurrent mode, although I am not sure how as of yet

this is how i get the token via node livekit-server-sdk
```  const at = new AccessToken(
    process.env.LIVEKIT_API_KEY,
    process.env.LIVEKIT_API_SECRET,
    {
      identity,
      name,
    }
  );
  at.addGrant({
    roomJoin: true,
    room,
    canPublish: true,
    canSubscribe: true,
  });```

Hello <@U02UMFKPC6Q>, Im simply curious to know.. when you pass the identity &amp; the name you are actually passing the `key: value` ? Such as:

```const at = new AccessToken(
    process.env.LIVEKIT_API_KEY,
    process.env.LIVEKIT_API_SECRET,
    {
      identity: 'UserXYZ',
      name: 'UserXYZ'
    }
  );```
and not only:

```const at = new AccessToken(
    process.env.LIVEKIT_API_KEY,
    process.env.LIVEKIT_API_SECRET,
    {
      'UserXYZ',
      'UserXYZ'
    }
  );```


Because your accessToken should return you a `sub` property to indicate participant identity.

Hello <@U032TUAL4KT> Yeah of course. it’s like option one, it’s just JS shorthand which is already working because i’m able to join the room using the identity, just the name is not wokring

Oh my bad, I thought you had mentioned that your identity was also empty, sorry about that.

I was doing a bit of testing on my end also, and I cannot seem to get the server to return the Name, even if in the server SDK I get the name set properly in the token. I'll be curious to know if there's any specific keys we need to pass up to get the name return or its an issue.

Which version of the server SDK are you using?

could you share a token created this way with me?

sure
```eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiQWhtZWQgQWRseSIsInZpZGVvIjp7InJvb21Kb2luIjp0cnVlLCJyb29tIjoiNjI2NzVlNWM4MzdhNTQ5YjhkYzNiMDk3IiwiY2FuUHVibGlzaCI6dHJ1ZSwiY2FuU3Vic2NyaWJlIjp0cnVlfSwiaWF0IjoxNjUxNDY4MDYxLCJuYmYiOjE2NTE0NjgwNjEsImV4cCI6MTY1MTQ4MjQ2MSwiaXNzIjoiQVBJVWNNVFpGWTJGdDlyIiwic3ViIjoiYWRtaW5fYWhtZWRhZGx5QGdtYWlsLmNvbSIsImp0aSI6ImFkbWluX2FobWVkYWRseUBnbWFpbC5jb20ifQ.TRkNCIsfQ39WEQ6KFw5uYxIfMvRngrxKab_DrWD6lOs```

I'm seeing name set correctly in your token.. also confirmed that `room.localParticipant.name` displays the name I've set on my end. Which version of JS sdk are you using?

i’m using
```    "livekit-client": "^0.18.2",
    "livekit-react": "^0.7.1",```

Is it similar to <https://github.com/livekit/livekit-react/issues/40|this issue>? You can clone the repo and manually update the peer deps to see if that makes a difference

ok, created a gutted version of the example react project that breaks (?) for some reason

Hi <@U03C8KQDJMA> can you describe your use-case ? The first recorder can do mux video &amp; audio per participant, but the media writer is based on Pion and is not battle-tested imo. We’re currently using it in our pre-prod pipeline. 

The second item is LiveKit’s solution and I believe it’s almost done, though it depends on the LiveKit team to plan the release. They’re using GStreamer which is battle-tested. I’ll leave it to <@U01KZ61GV5Z> to explain more.

Ultimately though, we will decommission our recorder once we validate LiveKit’s solution works for us.

Thank you <@U02SGSET1RT> for the explanation.
My use case is recording single participants. Combining the video and audio track is not necessary, but doesn't bother either.

I'm still curious for the future "in-house" solution.
It would be very helpful to know how much work is left to do in Egress to be able to finally test this kind of scenario

I see, in our company, we’re only doing video as well. I’m assuming you’d want the file to be in a container such as `mp4` or `webm` , and not raw codec file such as `ivf` or `h264`. If so, our recorder should suffice for now.

I’m actually helping out with LiveKit’s solution, so I think I can answer a little bit on this. If you want a container file, the functionality is pretty much done. The remaining todo for it is to handle track being muted, as currently, muting a track causes the service to freeze. It should be doable to fix, but I’d check with <@U01KZ61GV5Z> or <@U01UB0LHTTQ> on the timeline.

thanks Dennis for the context! Egress service should be ready to try sometimes this week! we are getting the docs ready to go in the mean time.

image.png

Hey <@U02GTF5KZ6H> we currently do this in our  sample app <https://github.com/livekit/client-sdk-js/blob/c610860570bec3c90bebe6d8101334790afa7432/example/sample.ts#L274|here> . severing the signal connection will trigger a resume of connection. If it resumed successfully, tracks would not need to be republished

hey <@U03C8KQDJMA> can you share how you are producing the ogg file?

I took the sample file from <https://commons.wikimedia.org/wiki/File:Example.ogg>
and selected it with `--publish`
Are there specific Vorbis settings needed for the file?

Can you try the <https://github.com/livekit/server-sdk-go#vp8--opus|instructions here> for encoding the files? WebRTC can be particular about what it'll accept.

<@U01KZ61GV5Z> I've used ffmpeg as described in the instructions. and it just works as source for --publish. thank you!

you'll want something that can autoscale, like kubernetes

Today this can be done using our <https://github.com/livekit/livekit-recorder|recorder>, however if you can wait a bit we will be deprecating the recorder and releasing a new <https://github.com/livekit/livekit-server/blob/master/pkg/service/egress.go|egress service> that will have the same capabilities and more

It's worrying to me that results are inconsistent.  I've seen similar results when using standalone docker images.  Can you please provide any guidance?

Here's my firewall rules, which I believe are what the documentation requires

it appears you are connected to different server instances.. two of the screenshots are running 0.14.2, and the other one 0.15.1

I think the first order of business is resolving that difference. How are you setting up TURN in your `values.yaml` ?

one sec and I will send the complete `values.yaml`

replicaCount: 1

livekit:
  log_level: info
  rtc:
    use_external_ip: true
    port_range_start: 50000
    port_range_end: 60000
    tcp_port: 7801
  redis:
    address: &lt;server_ip&gt;:6379

  keys:
    &lt;key&gt;: &lt;secret&gt;
  turn:
    enabled: false
    loadBalancerType: disabled

loadBalancer:
  type: gke-managed-cert
  staticIpName: livekit-server-dev

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 5
  targetCPUUtilizationPercentage: 60

nodeSelector: {}

resources: {}

As far as the screenshot goes, the one with the inconsistent server instance was actually from a colleague.  I just grabbed it cause it was convenient but I saw the same thing.  That's almost certainly a red herring, but I am not sure what he connected to

ah I see.. that is odd. first I would recommend updating to the latest. there's been quite a few changes since 0.15.1. we can only support the latest version since things are moving so quickly.

otherwise, I would suggest opening up <chrome://webrtc-internals> and observe the remote ICE candidates. Happy to take a look if you can capture the remote candidates when there's a connection failure

Actually, there is something weird going on along the lines you suggested

I just captured this one from my own computer and it shows 0.15.1.  The others I captured show 0.14.2.

OK, it seems like I get potluck.  Sometimes I get 0.14.2 and it all works.  Sometimes I get 0.15.1 and it doesn't.

Doesn't seem to be a DNS issue.  That was my first thought.  But there's only one DNS entry for my hostname and it is correct.

The DNS entry points to my GKE ingress.  Here's the relevant snippet from the ingress config:

spec:
  defaultBackend:
    service:
      name: lks-livekit-server
      port:
        number: 80

spec:
  clusterIP: 172.18.82.14
  clusterIPs:
  - 172.18.82.14
  externalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: http
    nodePort: 32352
    port: 80
    protocol: TCP
    targetPort: http
  selector:
    <http://app.kubernetes.io/instance|app.kubernetes.io/instance>: lks
    <http://app.kubernetes.io/name|app.kubernetes.io/name>: livekit-server
  sessionAffinity: None
  type: NodePort

I'm updating to 0.15.7 in case that might help

I'm now consistently seeing 0.15.7, but also consistent failures.  I'm happy to send you the URL and token in a PM if you're willing to take a look

<@U02L67PHKKN> the best next steps are what I suggested above:
```otherwise, I would suggest opening up <chrome://webrtc-internals> and observe the remote ICE candidates. Happy to take a look if you can capture the remote candidates when there's a connection failure```

and server logs when it took place would also help

I don't have Chrome so I have asked a colleague to provide that info

However, when I tried the test this time, the server identified as 0.14.2.  But I am seeing the traffic on the same server.

2022-05-03T22:35:44.508Z	INFO	livekit	service/rtcservice.go:211	new client WS connected	{"room": "mike-room", "participant": "mike", "connID": "CO_HEpoTz3daPoK", "roomID": "RM_SAoBVvzCohk7"}
2022-05-03T22:35:44.564Z	INFO	livekit	service/rtcservice.go:257	exit ws read loop for closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_HEpoTz3daPoK"}
2022-05-03T22:35:44.564Z	INFO	livekit	service/rtcservice.go:191	server closing WS connection	{"room": "mike-room", "participant": "mike", "connID": "CO_HEpoTz3daPoK"}
2022-05-03T22:35:44.564Z	INFO	livekit	service/rtcservice.go:230	source closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_HEpoTz3daPoK"}
2022-05-03T22:35:45.111Z	INFO	livekit	service/rtcservice.go:211	new client WS connected	{"room": "mike-room", "participant": "mike", "connID": "CO_D2fQBTD9bcLE", "roomID": "RM_SAoBVvzCohk7"}
2022-05-03T22:35:46.426Z	INFO	livekit	service/rtcservice.go:257	exit ws read loop for closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_D2fQBTD9bcLE"}
2022-05-03T22:35:46.426Z	INFO	livekit	service/rtcservice.go:191	server closing WS connection	{"room": "mike-room", "participant": "mike", "connID": "CO_D2fQBTD9bcLE"}
2022-05-03T22:35:46.426Z	INFO	livekit	service/rtcservice.go:230	source closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_D2fQBTD9bcLE"}
2022-05-03T22:35:47.978Z	INFO	livekit	service/rtcservice.go:211	new client WS connected	{"room": "mike-room", "participant": "mike", "connID": "CO_jbGoj2mh7SpE", "roomID": "RM_SAoBVvzCohk7"}
2022-05-03T22:35:57.079Z	INFO	livekit	service/rtcservice.go:257	exit ws read loop for closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_jbGoj2mh7SpE"}
2022-05-03T22:35:57.079Z	INFO	livekit	service/rtcservice.go:191	server closing WS connection	{"room": "mike-room", "participant": "mike", "connID": "CO_jbGoj2mh7SpE"}
2022-05-03T22:35:57.079Z	INFO	livekit	service/rtcservice.go:230	source closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_jbGoj2mh7SpE"}
2022-05-03T22:35:58.122Z	INFO	livekit	service/rtcservice.go:211	new client WS connected	{"room": "mike-room", "participant": "mike", "connID": "CO_8AicyYLdjEM9", "roomID": "RM_SAoBVvzCohk7"}
2022-05-03T22:36:28.123Z	INFO	livekit	service/rtcservice.go:257	exit ws read loop for closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_8AicyYLdjEM9"}
2022-05-03T22:36:28.124Z	INFO	livekit	service/rtcservice.go:191	server closing WS connection	{"room": "mike-room", "participant": "mike", "connID": "CO_8AicyYLdjEM9"}
2022-05-03T22:36:28.124Z	INFO	livekit	service/rtcservice.go:230	source closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_8AicyYLdjEM9"}
2022-05-03T22:36:28.440Z	INFO	livekit	service/rtcservice.go:211	new client WS connected	{"room": "mike-room", "participant": "mike", "connID": "CO_AJZpDGfimhXD", "roomID": "RM_SAoBVvzCohk7"}
2022-05-03T22:36:58.442Z	INFO	livekit	service/rtcservice.go:257	exit ws read loop for closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_AJZpDGfimhXD"}
2022-05-03T22:36:58.442Z	INFO	livekit	service/rtcservice.go:191	server closing WS connection	{"room": "mike-room", "participant": "mike", "connID": "CO_AJZpDGfimhXD"}
2022-05-03T22:36:58.443Z	INFO	livekit	service/rtcservice.go:230	source closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_AJZpDGfimhXD"}
2022-05-03T22:36:58.752Z	INFO	livekit	service/rtcservice.go:211	new client WS connected	{"room": "mike-room", "participant": "mike", "connID": "CO_qyhzHEFGqxJc", "roomID": "RM_SAoBVvzCohk7"}
2022-05-03T22:37:06.374Z	INFO	livekit	service/rtcservice.go:257	exit ws read loop for closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_qyhzHEFGqxJc"}
2022-05-03T22:37:06.375Z	INFO	livekit	service/rtcservice.go:191	server closing WS connection	{"room": "mike-room", "participant": "mike", "connID": "CO_qyhzHEFGqxJc"}
2022-05-03T22:37:06.375Z	INFO	livekit	service/rtcservice.go:243	error writing to websocket	{"room": "mike-room", "participant": "mike", "error": "websocket: close sent"}
2022-05-03T22:37:07.422Z	INFO	livekit	service/rtcservice.go:211	new client WS connected	{"room": "mike-room", "participant": "mike", "connID": "CO_BNhyPWJMmMR4", "roomID": "RM_SAoBVvzCohk7"}
2022-05-03T22:37:08.769Z	INFO	livekit	service/rtcservice.go:257	exit ws read loop for closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_BNhyPWJMmMR4"}
2022-05-03T22:37:08.769Z	INFO	livekit	service/rtcservice.go:191	server closing WS connection	{"room": "mike-room", "participant": "mike", "connID": "CO_BNhyPWJMmMR4"}
2022-05-03T22:37:08.771Z	INFO	livekit	service/rtcservice.go:230	source closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_BNhyPWJMmMR4"}
2022-05-03T22:37:08.811Z	INFO	livekit	service/rtcservice.go:211	new client WS connected	{"room": "mike-room", "participant": "mike", "connID": "CO_s5JrJ373EYPy", "roomID": "RM_SAoBVvzCohk7"}
2022-05-03T22:37:10.242Z	INFO	livekit	service/rtcservice.go:257	exit ws read loop for closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_s5JrJ373EYPy"}
2022-05-03T22:37:10.242Z	INFO	livekit	service/rtcservice.go:191	server closing WS connection	{"room": "mike-room", "participant": "mike", "connID": "CO_s5JrJ373EYPy"}
2022-05-03T22:37:10.243Z	INFO	livekit	service/rtcservice.go:230	source closed connection	{"room": "mike-room", "participant": "mike", "connID": "CO_s5JrJ373EYPy"}

<@U01KZ61GV5Z> we're trying to get you the ICE candidate info but we're failing to get that far.  Every single time my colleague attempts to connect we see the server identify as 0.14.2 and when it does, it succeeds.  I see his traffic on the livekit server instance, and this is the image it is using: `image: livekit/livekit-server:v0.15.7`

Can you offer a guess as to what is going on here

He finally got a connection to 0.15.7, here are the ICE candidates

I see a potential issue here.  I'm an infrastructure guy, not a webrtc guy, unlike my colleagues.  But I see the candidate address of our egress NAT listed here several times.  You will never be able to connect to that.  Is there a way for me to specify my ingress's IP instead?

That is to say, outbound traffic from our cluster will appear to be from a different address (the one listed here) than inbound traffic

So after sleeping on it, I'm wondering if perhaps the helm charts (and maybe webrtc in general) are not compatible with a GKE private cluster, which is what I am deploying on.  A GKE private cluster has nodes with internal IP addresses only, and no egress except via a Cloud NAT instance, and no ingress except through a k8s ingress.  I may try to set up and deploy on a conventional "zonal cluster" instead.

<https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters>

It does seem like deploying it on a conventional cluster, as opposed to a private cluster, is working so far.  Might be helpful to future people to put a note in the documentation clarifying that a cluster running inside a VPC with private addresses (e.g. a GKE private cluster) may not work.

Hey Mike, I just finished reading up on this. You are right.. LiveKit (and other webrtc solutions) would not work with a private cluster.. We'll add this to our docs. thank you for digging into it and letting me know

Great, thanks for putting me on the right trail with the ICE candidates thing

The main challenge is the NAT translation.. WebRTC servers have to advertise its own addresses to clients (since it's UDP, it's a bidirectional stream). Private clusters have a particular kind of NAT that doesn't forward the UDP packets back to our instance. so that makes it really tricky.

Yep.  In retrospect it makes perfect sense.

Hmm can you config the servers to only allow h264? That would be the most appropriate way I think

For client side configuration, a h264 only encoder factory can be passed in

<https://github.com/livekit/client-sdk-android/blob/main/video-encode-decode-test/src/main/java/io/livekit/android/videoencodedecode/CallViewModel.kt|https://github.com/livekit/client-sdk-android/blob/main/video-encode-decode-test/src/main/java/io/livekit/android/videoencodedecode/CallViewModel.kt>

Great, thx! I'll look into those solutions.

For server side config: <https://github.com/livekit/livekit-server/blob/master/config-sample.yaml#L113|https://github.com/livekit/livekit-server/blob/master/config-sample.yaml#L113>

hey benjamin, I think I just chose those defaults way back for visibility purposes (webrtc defaults to true anyways), but I haven’t seen any issues with them before. the WebRTC lib does test whether the feature is supported before enabling it, so turning it on by default seems safe?

what kind of issues have you seen?

On some Sony device (if needed, I can check which one exactly) we had horrible echoes when HW AEC was enabled. On the other Hand, on a Pixel 2 the situation was the opposite, with HW disabled we had more echoes than without.
I guess there’s a reason why some other services determine it based on device model and/or Android version.
Telegram also does some magic but it’s in their backend. Just by looking at the mobile sources, we could not reverse engineer their logic.

I can understand if you don’t want to provide such a logic (unless you exactly know what you are doing), but possibly you could allow setting the ADM config from some options like in `LocalAudioTrackOptions` . WDYT?

yeah, can definitely start opening up the switches for customization

we have a LiveKitOverrides which it would probably go into

Sounds great! Otherwise it looks like we’d have to fork just for these settings.

tracking here: <https://github.com/livekit/client-sdk-android/issues/80>

hey <@U03DXJ9PASH>, another user also reported echos on Android with a workaround

<https://livekit-users.slack.com/archives/C01KVTJH6BX/p1655731999858789?thread_ts=1655475205.122879&amp;cid=C01KVTJH6BX>

did you happen to figure out a general workaround for your cases? trying to see if there's some better rules we can apply to avoid this (or if yours happen to align with the above user's)

<@U02GTF5KZ6H> Can you please elaborate on what bad internet is like?

Where are you deploying the server? Which version of server are you using?

If you are using Chrome, can you check `<chrome://webrtc-internals>` and look at differences between P2P case and using LiveKit server?

In terms of tuning, we have adaptive streaming (subscribers will pull video stream of appropriate size based on visibility and video tile) and dynacast (publisher will publish video that is enough to satisfy subscribers). These are client side settings.

On server side, check congestion control settings in the config and you can try the options there - <https://github.com/livekit/livekit-server/blob/1665f51bd0ce17360de8e91f8559215769537c78/config-sample.yaml#L48>

<@U02CM28PB4Y> I using livekit for a long time already. and I  love how it works. The thing is last 2 weeks I changed location and using hotel internet. I not sure what wrong with it, but its laggy and its very affects livekit connection, while direct webrtc works much better.

 I will try to understand what is exactly different. I think part of users can experience the same thing.

Great to hear that <@U02GTF5KZ6H> . Hotel networks are definitely challenging:blush:. Look forward to your findings. Most probably, congestion control might need some tweaks, but the reconnect is surprising.

<@U02GTF5KZ6H> which version of the server are you running currently? reconnect sounds like a recent bug that we've fixed in certain network conditions.

<@U01KZ61GV5Z> I using <https://github.com/livekit/livekit-server/releases/tag/v0.15.6|v0.15.6>, I tried to update to latest today, but it broke my videos immediatelly (adaptive stream enabled), so I reverted it back

I found if I disable adaptive stream at JS SDK, it works again, but I cant distribute that to the clients fast

so I will wait for your new version of JS SDK (as I seen there are some commints related to adaptiveStream) and then will try again

got it, that is indeed odd.. let me see if I can spot what's going on.

I'm unable to reproduce it.. but definitely sounds related to the new feature we've released in the latest version

would like to track this down if you can give me a few ways to reproduce.

<@U01KZ61GV5Z> it seems like track is published paused for some reason ( this is what I understood from changelog )

Probably I need to manually start it in some way on the client side with new update?

so with adaptive stream turned on, are you using .attach() to bind to the tracks?

<@U01KZ61GV5Z> I just playing it in react child component from MediaStream

yes.. if this is the case, you should not be using adaptive stream.

adaptivestream requires usage of `.attach`

oh, didnt know that! will try to remake my code to use attach

<@U01KZ61GV5Z> thanks for pointing, sorry to disturb

no worries! see here for an example of attaching within react: <https://github.com/livekit/livekit-react/blob/master/src/components/VideoRenderer.tsx>

~/.bashrc config:

# Setting PATH for Go

export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$BOPATH/bin

Also set source to ~./bashrc

For anyone else, I set source to ~/.profile and used this config:

# Set GOPATH

export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin:/usr/local/go/bin

Running Ubuntu 20.04

<@U02C10ZEP8R> I believe that's right, we have not gotten around to add external TLS termination to the helm chart.

the main challenge is that not every cloud vendor supports TCP/TLS.

Yeah, I wouldn't use it by default but it would be nice if it could be enabled. I think it should just be as simple as adding a not statement on `.Values.livekit.turn.external_tls` in the same way all of that gets skipped when set to disabled.

The customer I'm working with handles load balancing and TLS termination differently for their cluster, so for TURN I need to be able to support external_tls. I'll see if they want to worry about it for now or just keep TURN disabled... if they want me to fix it, I'll submit a PR if it hasn't been updated yet :slightly_smiling_face:

ah ok, you are thinking that the user sets up their own custom load balancer outside of the helm chart? that makes sense too

Yep, that's the case for what I'm working on with someone right now.

I opened a ticket for it: <https://github.com/livekit/livekit-helm/issues/26>

Complete log is as follows

```redis_1              | 1:C 05 May 2022 06:21:33.889 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_1              | 1:C 05 May 2022 06:21:33.889 # Redis version=7.0.0, bits=64, commit=00000000, modified=0, pid=1, just started
redis_1              | 1:C 05 May 2022 06:21:33.889 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
redis_1              | 1:M 05 May 2022 06:21:33.890 * monotonic clock: POSIX clock_gettime
redis_1              | 1:M 05 May 2022 06:21:33.895 * Running mode=standalone, port=6379.
redis_1              | 1:M 05 May 2022 06:21:33.895 # Server initialized
redis_1              | 1:M 05 May 2022 06:21:33.895 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
redis_1              | 1:M 05 May 2022 06:21:33.897 * The AOF directory appendonlydir doesn't exist
redis_1              | 1:M 05 May 2022 06:21:33.898 * Loading RDB produced by version 7.0.0
redis_1              | 1:M 05 May 2022 06:21:33.898 * RDB age 287 seconds
redis_1              | 1:M 05 May 2022 06:21:33.898 * RDB memory usage when created 0.97 Mb
redis_1              | 1:M 05 May 2022 06:21:33.898 * Done loading RDB, keys loaded: 50, keys expired: 0.
redis_1              | 1:M 05 May 2022 06:21:33.898 * DB loaded from disk: 0.001 seconds
redis_1              | 1:M 05 May 2022 06:21:33.898 * Ready to accept connections
livekit_1            | 2022-05-05T06:22:08.046Z	INFO	livekit	logger/logger.go:26	using multi-node routing via redis	{"addr": "redis:6379"}
livekit_1            | 2022-05-05T06:22:08.163Z	INFO	livekit	logger/logger.go:30	UDP receive buffer is too small for a production set-up	{"current": 425984, "suggested": 5000000}
livekit_1            | 2022-05-05T06:22:08.178Z	INFO	livekit	logger/logger.go:26	starting LiveKit server	{"addr": ":7880", "nodeID": "ND_oDVfgLUe", "nodeIP": "15.206.159.133", "version": "0.15.5", "rtc.portTCP": 7881, "rtc.portUDP": 7882}
livekit_1            | 2022-05-05T06:22:58.725Z	INFO	livekit	service/rtcservice.go:203	new client WS connected	{"room": "dipesh-room", "participant": "dipesh", "connID": "CO_FxZKkkpVi2MJ", "roomID": "RM_XhrArw9KvWQP"}
livekit_1            | 2022-05-05T06:22:58.733Z	INFO	livekit	rtc/room.go:225	new participant joined	{"room": "dipesh-room", "roomID": "RM_XhrArw9KvWQP", "pID": "PA_gN4PWn3VXZja", "participant": "dipesh", "protocol": 7, "options": {"AutoSubscribe":true}}
livekit-recording_1  | {"level":"info","ts":1651731829.4025912,"logger":"livekit-recorder","caller":"logger/logger.go:26","msg":"connecting to redis work queue","addr":"redis:6379"}
livekit-recording_1  | {"level":"info","ts":1651731845.671769,"logger":"livekit-recorder","caller":"logger/logger.go:26","msg":"Waiting for room to start"}```


Tried with Golang SDK too. Same Issue:hand_with_index_and_middle_fingers_crossed:. Let me know if I am missing something :pray:
```req := &amp;livekit.StartRecordingRequest{
        Input: &amp;livekit.StartRecordingRequest_Template{
            Template: &amp;livekit.RecordingTemplate{
                Layout:   "speaker-dark",
                RoomName: "dipesh-room",
            },
        },
        Output: &amp;livekit.StartRecordingRequest_Rtmp{
            Rtmp: &amp;livekit.RtmpOutput{
                Urls: []string{"rtmp://.............."},
            },
        },
    }

recordingClient := lsdk.NewRecordingServiceClient('<https://livekit>...........', key, secret)
resp, err := recordingClient.StartRecording(context.Background(), req)
recordingID := resp.RecordingId```

can you set your `log_level` to debug and open the url it prints? (there will be a log message that says `launching chrome` with a url)

if you open that url, you should see the room, along with a console log message that says `START_RECORDING`

<@U01UB0LHTTQ> Log level is `debug` by default. And I have manually added too in the configuration. The log I sent above is (with log_level to debug). There is no log saying `launching chrome` .

<@U01UB0LHTTQ> I created new docker image from the latest repository and now using this new image, I am getting logs that you refered in above messages.

But now I get this warnings. And there is no recording. Can you suggest how I can move forward?

```livekit_1            | 2022-05-06T17:14:28.078Z	DEBUG	livekit	logger/logger.go:22	recording started	{"recordingID": "RR_UiCZpZDo7292"}
livekit-recording_1  | 0:00:00.274553613   185 0x5595cbabc590 WARN                 nvcodec gstcudaloader.c:114:gst_cuda_load_library: Could not open library libcuda.so.1, libcuda.so.1: cannot open shared object file: No such file or directory
livekit-recording_1  | 0:00:00.274589262   185 0x5595cbabc590 WARN                 nvcodec plugin.c:66:plugin_init: Failed to load cuda library
livekit-recording_1  | 0:00:00.315892878   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0x120000: 'AVR (Audio Visual Research)' is not mapped
livekit-recording_1  | 0:00:00.315925379   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0x180000: 'CAF (Apple Core Audio File)' is not mapped
livekit-recording_1  | 0:00:00.315933113   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0x100000: 'HTK (HMM Tool Kit)' is not mapped
livekit-recording_1  | 0:00:00.315941104   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0xc0000: 'MAT4 (GNU Octave 2.0 / Matlab 4.2)' is not mapped
livekit-recording_1  | 0:00:00.315947931   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0xd0000: 'MAT5 (GNU Octave 2.1 / Matlab 5.0)' is not mapped
livekit-recording_1  | 0:00:00.315953898   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0x210000: 'MPC (Akai MPC 2k)' is not mapped
livekit-recording_1  | 0:00:00.315963578   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0xe0000: 'PVF (Portable Voice Format)' is not mapped
livekit-recording_1  | 0:00:00.315970717   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0x160000: 'SD2 (Sound Designer II)' is not mapped
livekit-recording_1  | 0:00:00.315982927   185 0x5595cbabc590 WARN                 default gstsf.c:97:gst_sf_create_audio_template_caps: format 0x190000: 'WVE (Psion Series 3)' is not mapped
livekit-recording_1  | {"level":"info","ts":1651857269.0232658,"logger":"livekit-recorder","caller":"logger/logger.go:26","msg":"Waiting for room to start"}```

Those warnings are all expected. If you open the URL, do you see the video from the room?

yes, I see the video with one slight change in the URL generated by the recorder

<@U01UB0LHTTQ> URL generated by recorder is in the form `<https://recorder.livekit.io/grid-dark?url=>....` . This doesnt do anything. But if I add hash after baseurl `<https://recorder.livekit.io/#/grid-dark?url=>....` , I see the video of my room. But I dont see anything in my RTMP output URL.

did you put `<https://recorder.livekit.io>` in your config for template address?

By default it should be `<https://recorder.livekit.io/#>`

If I leave baseurl not defined, I get `Property 'baseUrl' is missing in type '{ layout: string; roomName: string; }' but required in type 'RecordingTemplate'.`

If I put `<https://recorder.livekit.io/#>`  as baseURL manually, I get connection refused when starting recording.
*log*
```livekit-recording_1  | 0:04:13.013171150     1 0x7f10d401bf50 WARN                   pulse pulsesrc.c:1013:gst_pulsesrc_open:&lt;pulsesrc2&gt; error: Failed to connect: Connection refused
livekit-recording_1  | {"level":"error","ts":1651850706.8738513,"logger":"livekit-recorder","caller":"logger/logger.go:34","msg":"error running pipeline","error":"Failed to change state to PLAYING","stacktrace":"<http://github.com/livekit/protocol/logger.Errorw\n\t/root/go/pkg/mod/github.com/livekit/protocol@v0.11.1-0.20211215011801-f77609470e70/logger/logger.go:34\ngithub.com/livekit/livekit-recorder/pkg/recorder.(*Recorder).Run\n\t/workspace/pkg/recorder/recorder.go:111\ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRequest.func1\n\t/workspace/pkg/service/handler.go:88|github.com/livekit/protocol/logger.Errorw\n\t/root/go/pkg/mod/github.com/livekit/protocol@v0.11.1-0.20211215011801-f77609470e70/logger/logger.go:34\ngithub.com/livekit/livekit-recorder/pkg/recorder.(*Recorder).Run\n\t/workspace/pkg/recorder/recorder.go:111\ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRequest.func1\n\t/workspace/pkg/service/handler.go:88>"}```

If I put `<https://recorder.livekit.io>`  as baseURL, I get URL and after adding # manually, it saying recording started, but there is no recording in my RTMP output URL.

<@U01UB0LHTTQ> If I leave baseurl undefined with `ts-ignore` so that it takes the default value, the URL generated now is correct. But I get *connection refused*.
*Log*
```livekit-recording_1  | {"level":"info","ts":1651902287.6899228,"logger":"livekit-recorder","caller":"logger/logger.go:26","msg":"Waiting for room to start"}
livekit-recording_1  | {"level":"info","ts":1651902287.689992,"logger":"livekit-recorder","caller":"logger/logger.go:26","msg":"Room started"}
livekit-recording_1  | 0:00:01.756047901     1 0x7f857037b000 WARN                   pulse pulsesrc.c:1013:gst_pulsesrc_open:&lt;pulsesrc0&gt; error: Failed to connect: Connection refused
livekit-recording_1  | {"level":"error","ts":1651902287.7067127,"logger":"livekit-recorder","caller":"logger/logger.go:34","msg":"error running pipeline","error":"Failed to change state to PLAYING","stacktrace":"<http://github.com/livekit/protocol/logger.Errorw\n\t/root/go/pkg/mod/github.com/livekit/protocol@v0.11.1-0.20211215011801-f77609470e70/logger/logger.go:34\ngithub.com/livekit/livekit-recorder/pkg/recorder.(*Recorder).Run\n\t/workspace/pkg/recorder/recorder.go:111\ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRequest.func1\n\t/workspace/pkg/service/handler.go:88|github.com/livekit/protocol/logger.Errorw\n\t/root/go/pkg/mod/github.com/livekit/protocol@v0.11.1-0.20211215011801-f77609470e70/logger/logger.go:34\ngithub.com/livekit/livekit-recorder/pkg/recorder.(*Recorder).Run\n\t/workspace/pkg/recorder/recorder.go:111\ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRequest.func1\n\t/workspace/pkg/service/handler.go:88>"}
livekit-recording_1  | {"level":"error","ts":1651902287.708025,"logger":"livekit-recorder","caller":"logger/logger.go:34","msg":"recording failed","recordingID":"RR_ytsBYoCe8mh9","error":"Failed to change state to PLAYING","stacktrace":"<http://github.com/livekit/protocol/logger.Errorw\n\t/root/go/pkg/mod/github.com/livekit/protocol@v0.11.1-0.20211215011801-f77609470e70/logger/logger.go:34\ngithub.com/livekit/livekit-recorder/pkg/service.LogResult\n\t/workspace/pkg/service/handler.go:132\ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRecording\n\t/workspace/pkg/service/handler.go:42\ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).Run\n\t/workspace/pkg/service/service.go:86\nmain.runService\n\t/workspace/cmd/server/service.go:50\nmain.run\n\t/workspace/cmd/server/main.go:58\ngithub.com/urfave/cli/v2.(*App).RunContext\n\t/root/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:322\ngithub.com/urfave/cli/v2.(*App).Run\n\t/root/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:224\nmain.main\n\t/workspace/cmd/server/main.go:51\nruntime.main\n\t/usr/lib/go-1.16/src/runtime/proc.go:225|github.com/livekit/protocol/logger.Errorw\n\t/root/go/pkg/mod/github.com/livekit/protocol@v0.11.1-0.20211215011801-f77609470e70/logger/logger.go:34\ngithub.com/livekit/livekit-recorder/pkg/service.LogResult\n\t/workspace/pkg/service/handler.go:132\ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRecording\n\t/workspace/pkg/service/handler.go:42\ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).Run\n\t/workspace/pkg/service/service.go:86\nmain.runService\n\t/workspace/cmd/server/service.go:50\nmain.run\n\t/workspace/cmd/server/main.go:58\ngithub.com/urfave/cli/v2.(*App).RunContext\n\t/root/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:322\ngithub.com/urfave/cli/v2.(*App).Run\n\t/root/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:224\nmain.main\n\t/workspace/cmd/server/main.go:51\nruntime.main\n\t/usr/lib/go-1.16/src/runtime/proc.go:225>"}
livekit_1            | 2022-05-07T05:44:47.709Z	ERROR	livekit	logger/logger.go:34	failed to read results	{"error": "proto: cannot parse invalid wire-format data"}
livekit_1            | <http://github.com/livekit/protocol/logger.Errorw|github.com/livekit/protocol/logger.Errorw>
livekit_1            | 	/go/pkg/mod/github.com/livekit/protocol@v0.11.14-0.20220225092016-4b44edff9ed7/logger/logger.go:34
livekit_1            | <http://github.com/livekit/livekit-server/pkg/service.(*EgressService).resultsWorker|github.com/livekit/livekit-server/pkg/service.(*EgressService).resultsWorker>
livekit_1            | 	/workspace/pkg/service/egress.go:237
livekit_1            | 2022-05-07T05:44:47.717Z	INFO	livekit	service/rtcservice.go:184	server closing WS connection	{"room": "room1", "participant": "RR_U25ve3aGXQxW", "connID": "CO_zAaTx6qJhzL3"}```

`pulse pulsesrc.c:1013:gst_pulsesrc_open:&lt;pulsesrc0&gt; error: Failed to connect: Connection refused` that’s from system audio

<@U01UB0LHTTQ> docker inside AWS EC2 Instance

Sorry I have not been very helpful so far, but I’m unable to reproduce this

The entrypoint script executes the following:
```# Start pulseaudio as system wide daemon; for debugging it helps to start in non-daemon mode
pulseaudio -D --verbose --exit-idle-time=-1 --system --disallow-exit

# Load audio sink
pactl load-module module-null-sink sink_name="grab" sink_properties=device.description="monitorOUT"```
Do you see any logs related to issues with this?

the current codec is indicated in <https://docs.livekit.io/client-sdk-js/classes/TrackPublication.html#mimeType|TrackPublication.mimeType>

<@U01KZ61GV5Z> mimeType on LocalTrackPublication appears to be empty string. I can confirm that for remote tracks, it seems to have a non-empty value.

ah ha.. that's probably a bug.. let me take a look

I saw you released 0.18.4 and switched to that, still works. :thumbsup:

I’m trying to upgrade from livekit-client v0.17.1, which didn’t have this problem

hey, how are you bundling the library? mind giving `0.18.4-RC8` a try?

0.18.4-RC8 worked! I’m not sure how the library is bundled as I’m mostly a JS noob. I’m using <https://github.com/electron-react-boilerplate/electron-react-boilerplate>

got it, thanks for the update. we'll release 0.18.4 shortly! CC <@U02EU2ZPTQU>

0.18.4 is released! <https://github.com/livekit/client-sdk-js/releases/tag/v0.18.4>

i’m using
```    "livekit-client": "^0.18.3",
    "livekit-react": "^0.9.0",
    "livekit-server-sdk": "^0.5.10",```

appreciate any help with this as the error is topping our production deployment

looks similar to the issue shared earlier in this channel: <https://livekit-users.slack.com/archives/C01KVTJH6BX/p1651787203330379>

<@U02UMFKPC6Q> can you try linking against `0.18.4-RC8` and see if that fixes your issue?
Will release 18.4 officially soon!

that worked!! thanks a lot <@U02EU2ZPTQU> :pray:

hi <@U03ERFUBXU1>,
yeah you can just run it locally and then use the resulting cloud_init with your cloud provider or run the startup script directly on the vm

Does your project use a low version of `swift-collections` ?