LiveKit Community

I'm able to reproduce this for audioinput. will take a look. <https://github.com/livekit/client-sdk-js/issues/63>

this has been fixed. we'll cut a build in the next day or so

However, it looks like if it unpublish the old track myself and republish a new one with the right deviceId (etc) it works? I'm still verifying.

It appears to work fine for me in chrome to use `switchActiveDevice`.

Cross browser really messed with me. Sometimes you just have to unpublish and republish to cover all the cases

I tested this in a couple of other setups (simplepeer and Jitsi) and they seem to hold the resource after muting. I could see some cases where it would be desired to have it release the resource entirely, but in my use case it's causing more harm than good.

For one, I provide push-to-talk functionality that quickly mutes/unmutes the line, and flipping the profile like that is likely to causes issues considering how unstable bluetooth likes to be at the best of times :joy:

I just tested with the JS sample app and this happens as-is. An easy way to test is to start playing some music on your PC, then launch and connect to the sample app. If the mic is unmuted, you'll notice a drop in music quality (expected with the communication profile). Mute the mic and you'll hear the music audio quality improve again as it switches back to high-quality/non-communications mode.

Oddly, if I do:
```audioTrack.isMuted = true;
audioTrack.mediaStreamTrack.enabled = false;
audioTrack.emit("muted", audioTrack);```
It doesn't do this. It mutes/unmutes the track but doesn't switch profiles.

This doesn't make a lot of sense to me, since that seems to be the same thing that is done here: <https://github.com/livekit/client-sdk-js/blob/2b97b81b6ea0cd0ad26c8af7a41fdc8fb51c0d3a/src/room/track/LocalTrack.ts#L160-L168>

But it's consistent. If I use audioTrack.mute() BT switches profiles. If I use that code snipit, it doesn't.

FWIW, this also happens if using the new `setMicrophoneEnabled` method.

hey, I think I know why this is happening.. in order to prevent the recording indicator from being on, we actually stop the underlying audio track when you mute

I didn't realize it would cause a profile with BT devices.. I think we should offer a flag to tweak that behavior..

I am thinking not stopping track on mute should be default? The indicator going off is a good one, but does unmuting trigger a renegotiation or is it using `replaceTrack`?

it doesn't trigger re-negotiation in this case. transceiver wasn't stopped

<@U01KZ61GV5Z> that makes sense. If this could be an option, that would be great. I do like the behavior, but for my use case it unfortunately doesn't fit very well.

yeah, we will provide an option for it. <https://github.com/livekit/client-sdk-js/issues/65>

In case anyone else is reading this thread later, I now know why doing the muting manually was different. I was looking at the `mute()` method in LocalTrack instead of LocalAudioTrack. This is the part that does the stop action. Not sure why I wasn't seeing this last night :face_palm: <https://github.com/livekit/client-sdk-js/blob/2b97b81b6ea0cd0ad26c8af7a41fdc8fb51c0d3a/src/room/track/LocalAudioTrack.ts#L29>

The comment there in that code says
&gt; // also stop the track, so that camera indicator is turned off
Should that be `camera` -&gt; `microphone`

almost certainly should be <@U02CM28PB4Y>

image.png

Hi <@U02KJKJ43CH>! Welcome! :wave:  Maybe <@U02BBTRGF98> might be able to help?

hi <@U02KJKJ43CH>! I haven't tried deploying on GCE yet, but this should work! what happens if you try to run the LiveKit docker image without Systemd?
```systemctl stop docker.livekit-server@v0.13

docker run --rm --name livekit-server \
  --net host \
  --volume /opt/livekit-server:/opt/livekit-server \
  livekit/livekit-server:latest \
  --config /opt/livekit-server/config.yaml```

Thanks for the help <@U02BBTRGF98> ! Ive finally got it up and running! 

Actually Im not really sure, but I think there just seems to be some file access permission issues that is why the docker service cant start properly

So it worked when started from your shell, but not as a service that starts up with your VM? I'll have to investigate this one some time.

:thinking_face: that's really strange. that it's mobile iOS specific.. we'll have to test this.

Does it happen when you have audio/video published as well?

Yes, it happens regardless of whether audio/video is published or not. I‘m very glad to help you test this if I somehow can.

<@U028SSAKLQ1> I found the issue! It's a strange difference in behavior on mobile safari. Fixed in <https://github.com/livekit/client-sdk-js/commit/bfb009be639ba080d3f958e80c23d8cd407aa07d>

<@U01KZ61GV5Z>, you can‘t imagine how much I appreciate your work. Thank you! :pray:

Can you try turning off bitcode for your app

ok, I tried that but still seeing that same error

<@U029G6PA4D7> thanks for that, later on it was helpful because Idid have to turn off bitcode to successfully "archive" my build

For web/JS SDK, take a look at <https://github.com/livekit/client-sdk-js#handling-common-track-types>

it's quite simple using our new high level API `LocalParticipant.setScreenShareEnabled(true)`

Hi! That SSL error means that Nginx was is not able to read the private key from your SSL certificate.

you can find the cert and key files in `/opt/livekit-server/ssl` on your server and check to make sure they're what you expect

once you have the right cert and key files, you can restart Nginx with `systemctl restart nginx`

Had it been the same server version the entire time? Your report indicates for some reasons the client didn't receive that metadata update. which is really odd...

there hasn't been any client side changes between 0.13.4 and 0.13.6 that would impact its ability to get metadata updates.

do you see any livekit related logs in JS console?

I guess you did mention the unpublished track message.. was that on the client side or server side?

Server was the same, I just downgraded the clients. The error I saw was client side, I didn't get a chance to grab server logs.

The fact that it worked after downgrading may have been a fluke. Once we had everyone hearing each other, we stopped messing with it.

see if you can subscribe to this event: <https://docs.livekit.io/client-sdk-js/enums/roomevent.html#tracksubscriptionfailed>
this will get fired if the subscription was attempted, but didn't go through

1635533404518.log

I was just able to reproduce the error and am trying to get some logs now. Client side log attached. I'm checking to see if there is anything noteworthy on the server side now

I'll add that subscription into my code as well.

My setup at the moment is 7 test clients. To add some latency, I have the room running out of my Frankfurt, Germany node and have all of the clients connecting to a Chicago node for signaling, coming from Seattle. If I connect the clients all quickly one after the other, I'm consistently getting at least a couple of failures on one more more clients. I'm going to turn on trace logging client side now, then I'll try the downgrade again and see if it reproduces.

I didn't see anything of note on the server side logs. I see the subscription attempts (this is for the same user the above log is from:
```{"level":"debug","ts":1635534701.3388116,"logger":"livekit","caller":"rtc/room.go:444","msg":"subscribing to new track","participants":["bekitTest04","gmAssTest00"],"pIDs":["PA_8erL66nVyqyf","PA_4mPqb9u5m9mT"],"track":"TR_trZaSyeLasGd"}
...
{"level":"debug","ts":1635534701.33935,"logger":"livekit","caller":"rtc/participant.go:700","msg":"added subscribedTrack","pIDs":["PA_8erL66nVyqyf","PA_4mPqb9u5m9mT"],"participant":"gmAssTest00","track":"TR_trZaSyeLasGd"}```
but no errors or indication of a problem from either the room host or signal node..

oh wow, this is fantastic.. this will give us a good amount to work off of. I think there might be a condition where the track updates were missed. Need to figure out if that's a server bug or client bug

I downgraded to a version running client 0.13.1 and am still able to repro, so I don't think it's a new bug. I think it's really just down to latency or something like it. That explains why I didn't see the issue with my more recent tests, I had mostly been meeting with people all in Seattle so we were likely using a close node and everyone was signaling through the same one. My session last night had people connecting across the US, so some folks would be going through my chicago node and some through my seattle node.

I'm going to update my server cluster to 13.6 and see if it reproduces with that.

will file an issue and look into it today

are your test clients joining at the same time?

<https://github.com/livekit/livekit-server/issues/162>

Thanks! Sorry, I should have done that but I didn't want to last night because I didn't have a repro yet.

In case it isn't obvious from the stuff I've pasted, this is where the errors are spawning: <https://github.com/livekit/client-sdk-js/blob/95db3244dc4dcdb3ef55a61ee4f35f6c5adf526b/src/room/participant/RemoteParticipant.ts#L98-L105>

And it doesn't seem to just be a matter of a delay, since I can test minutes later and the remoteParticipant object on the client that spawned the error will still not have the offending track listed. If I go to other clients and check for the same participant, some of them have that track and some won't. It seems like if it fails for one client, it's likely to fail for multiple clients, but rarely all.

They aren't joining at the exact same time, but one after the other about a second or two apart (as quickly as I can switch tabs and tell the next user to log in, since I'm testing manually).

Because the room node is across the world from me, several of the clients will be negotiating at the same time.

ah ha.. ok that's helpful context. mind pasting them to the Issue?

Sure thing. I'll start posting any other findings there.

I won't be around for today to test anything else, but will probably try to do some more debugging this evening (PDT).

Is there a call I can make from the client to ask the engine to update the information about a participant from the server? That might help with testing later, and maybe I can at least build a workaround to this in the meantime if there's a way to do that.

There isn't a way unfortunately. I'm confident we can track this down though.

<@U02C10ZEP8R> what you're describing has been happening to us, too. For us it wasn't related to [geo-based] latency, but the situation with multiple connections in quick succession sounds very familiar. Unfortunately I haven't been able to track it down more narrowly than you and thought it may be caused by a bug in the custom join process we've built around livekit (which is why I haven't reported anything so far). If you think it might be helpful I'm open to hopp on a call to discuss how we can tackle this together.

<@U028SSAKLQ1> David has been making some great progress on the issue. I'm about to test another update from him. If you have an easy way to test, I'd check out the snapshots that David has provided in this ticket and see if it resolves your issue: <https://github.com/livekit/livekit-server/issues/162>

<@U02C10ZEP8R> will do! Thanks for the heads-up!

<@U028SSAKLQ1> In case you didn't see from that ticket, David got the issue fixed up and it's released in v0.13.7 of the livekit-server. If what you were seeing was the same problem, it should be taken care of.

Thanks for the thoughtful update, Brint, I really appreciate it. I’ve followed your discussion right after you posted it and we have tested the changes with Davids snapshot yesterday, trying to reproduce our issue for hours. As the issue was already closed and it semeed resolved from our perspective, I‘ve not commented anymore. Thanks a lot to both of you for reporting and fixing this issue! You’ve saved us from quite a headache over here! :heart: :pray: 

:wave: can you show me the output from the troubleshooting commands?

```systemctl status docker.service
systemctl status nginx.service
systemctl status docker.livekit-server@v0.13.service```

my guess here is that your SSL certificate is invalid, as AWS does not allow you to export public SSL certificates, only private ones

that said, private certs should work too, if get your system and/or browser to trust your private CA

ports don't need to be mapped because we are using host networking.

do you have the ports open on your security group?

Screenshot from 2021-10-30 23-49-34.png

Here's ss of client(left) and server logs(right).

Hey Himanshu, thanks so much for the kind words! :pray: <@U02BBTRGF98> might be able to provide some guidance on deploying to DO.

Hmm the server seems to be working based off of the logs. I'm not as familiar with the client side. Maybe try giving the js sample client a shot: <https://github.com/livekit/client-sdk-js|https://github.com/livekit/client-sdk-js>

<@U02KN5U5P1Q>, you need a certificate signed by a CA.. OpenSSL self-signed certs don't work with browsers

<@U01KZ61GV5Z> We should be able to connect directly thru ip address, no (by bypassing nginx layer completelly)?

From logs looks like server is closing connection after some time, if we could hop on small call that would be great.

you'd need a CA certificate. see <https://docs.livekit.io/deploy#domain-ssl-certificates-and-load-balancer|https://docs.livekit.io/deploy#domain-ssl-certificates-and-load-balancer>

Hey Yashraj, welcome! Yup, you can build a custom UI with our react lib. Here's an example playground instance that mimics Clubhouse's audio rooms using the LiveKit hooks:

<https://livekit.io/playground#room=custom-ui&amp;minimized=false&amp;code=f04193db2dd1017ca08b77bb>

Thanks a lot, but when I ran the example on my local machine I was not able to figure out createLocalTracks (wasn't able to import it).
It would be great if you could help with it

<@U02KM0MNZU6> `createLocalTracks` isn't an available export from `livekit-react` -- if you install <https://github.com/livekit/client-sdk-js>, you can import it from there

If you use `go sdk` to join as participant that time in the similar scenario you'll get similar message there too. I mean in both client &amp; server.

1. Yes, just missing documentation as recording is still in beta and has gone through a number of breaking changes. Can be found here: <https://github.com/livekit/server-sdk-js/blob/main/src/RecordingServiceClient.ts>
2. Reservations happen behind the scenes - that’s how it works, but the user doesn’t need to know or care about it. Just send the StartRecording request and if a recorder cannot be reserved, it will fail

if you want to know more about how reservations happen, the code is in livekit-server: <https://github.com/livekit/livekit-server/blob/master/pkg/service/recordingservice.go#L50>

thanks <@U01UB0LHTTQ> that's exactly what I needed to know. it is much appreciated :wink:

just to let you guys know, RecordingServiceClient is not exported on livekit-server-sdk, I've tried with JS and TS
I have to explicitly import it like this:
 `import RecordingServiceClient from 'livekit-server-sdk/dist/RecordingServiceClient'`

thanks for pointing that out, should be fixed now in v0.5.6

Are you getting a `no recorders available` error on the cli/sdk end, or is the request to the server timing out?

<@U01UB0LHTTQ> no, nothing at all, I just get an empty response, but no messages

are you on the latest cli/sdk/server/recorder? That shouldn’t be possible, as both the sdk and livekit-server will return either a StartRecordingResult or an error, and the cli will return an error if it doesn’t get a recording ID

I just updated the livekit-server to 0.13.7 and livekit-recorder to 0.3.5 , restarted the vm and now seems to throw some errors, but now I'm getting a recording ID

```(gst-plugin-scanner:174): GStreamer-WARNING **: 07:28:21.592: Failed to load plugin '/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so': libva-wayland.so.2: cannot open shared object file: No such file or directory
0:00:02.992071747   174 0x5602084a9f20 ERROR            msdkcontext gstmsdkcontext.c:140:gst_msdk_context_use_vaapi: Couldn't find a drm device node to open```

here's the result of an `ldd /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so`
running it inside the livekit-recorder docker
```root@425e4dae2e0a:/# ldd /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
        linux-vdso.so.1 (0x00007ffe3d5a2000)
        libgstbase-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgstbase-1.0.so.0 (0x00007fda5e27f000)
        libgstreamer-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 (0x00007fda5e129000)
        libgobject-2.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fda5e0ce000)
        libglib-2.0.so.0 =&gt; /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fda5df98000)
        libgstvideo-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgstvideo-1.0.so.0 (0x00007fda5de99000)
        libgstallocators-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgstallocators-1.0.so.0 (0x00007fda5de90000)
        libgstpbutils-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgstpbutils-1.0.so.0 (0x00007fda5de4e000)
        libva.so.2 =&gt; /lib/x86_64-linux-gnu/libva.so.2 (0x00007fda5de21000)
        libgstgl-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgstgl-1.0.so.0 (0x00007fda5dda3000)
        libgstcodecparsers-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgstcodecparsers-1.0.so.0 (0x00007fda5dd24000)
        libm.so.6 =&gt; /lib/x86_64-linux-gnu/libm.so.6 (0x00007fda5dbd6000)
        libva-drm.so.2 =&gt; /lib/x86_64-linux-gnu/libva-drm.so.2 (0x00007fda5dbcf000)
        libdrm.so.2 =&gt; /lib/x86_64-linux-gnu/libdrm.so.2 (0x00007fda5dbbb000)
        libudev.so.1 =&gt; /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fda5db92000)
        libEGL.so.1 =&gt; /lib/x86_64-linux-gnu/libEGL.so.1 (0x00007fda5db7c000)
        libgmodule-2.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fda5db76000)
        libva-wayland.so.2 =&gt; not found
        libwayland-client.so.0 =&gt; /lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007fda5db63000)
        libpthread.so.0 =&gt; /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fda5db41000)
        libc.so.6 =&gt; /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda5d955000)
        libdl.so.2 =&gt; /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fda5d94e000)
        libunwind.so.8 =&gt; /lib/x86_64-linux-gnu/libunwind.so.8 (0x00007fda5d933000)
        libdw.so.1 =&gt; /lib/x86_64-linux-gnu/libdw.so.1 (0x00007fda5d885000)
        libffi.so.8 =&gt; /lib/x86_64-linux-gnu/libffi.so.8 (0x00007fda5d877000)
        libpcre.so.3 =&gt; /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fda5d801000)
        liborc-0.4.so.0 =&gt; /lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007fda5d77b000)
        libgstaudio-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgstaudio-1.0.so.0 (0x00007fda5d6f3000)
        libgsttag-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgsttag-1.0.so.0 (0x00007fda5d6ac000)
        libwayland-cursor.so.0 =&gt; /lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007fda5d69f000)
        libwayland-egl.so.1 =&gt; /lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007fda5d69a000)
        libgudev-1.0.so.0 =&gt; /lib/x86_64-linux-gnu/libgudev-1.0.so.0 (0x00007fda5d68c000)
        libgbm.so.1 =&gt; /lib/x86_64-linux-gnu/libgbm.so.1 (0x00007fda5d67c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fda5e3f8000)
        libGLdispatch.so.0 =&gt; /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007fda5d5c4000)
        liblzma.so.5 =&gt; /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fda5d597000)
        libelf.so.1 =&gt; /lib/x86_64-linux-gnu/libelf.so.1 (0x00007fda5d57a000)
        libz.so.1 =&gt; /lib/x86_64-linux-gnu/libz.so.1 (0x00007fda5d55e000)
        libbz2.so.1.0 =&gt; /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fda5d54b000)
        libwayland-server.so.0 =&gt; /lib/x86_64-linux-gnu/libwayland-server.so.0 (0x00007fda5d535000)
        libexpat.so.1 =&gt; /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fda5d504000)```


Those are safe to ignore. The docker image we’re using has those plugins but we skipped their dependencies because we don’t use vaapi/wayland

nice.! I'm making some progress, now it starts recording, I stop the recorder docker after a while, start it again, and  I can see the .mp4 file, it's got 0 bytes, I'll play some more with it, to see what's going on

<@U01UB0LHTTQ> I've been able to record videos in standalone mode, but when I go to service mode, I get 0 bytes sized videos. This is the complete log from the recorder in such situation:

<https://www.toptal.com/developers/hastebin/lazopocera.swift>

after quitting room, the recorder doesn't seem to stop, but I see the "END_RECORDING" console.log that should trigger it... so at that point, I just manually stop the container so it flushes the video to disk, but I get 0 bytes

any ideas?

ah, yeah `END_RECORDING` is broken in 0.3.5 - it just prints the message, but doesn’t actually stop the recording. Fix has already been pushed, I’ll publish 0.3.6 now

related, if you kill the container it needs enough time to flush an EOS and write the file metadata. You should be able to get a working file by either sending an `EndRecordingRequest`, or by using `docker stop -t 60` to make sure it has enough time to close and write

the docker stop -t 60 didn't work, but sending an EndRecordingRequest does the job.

Anyway, the 0.3.6 fixes the issue, now I get videos in service mode without having to send an EndRecordingRequest.

thanks a lot <@U01UB0LHTTQ>

A few more questions:
• is there any dynamic allocation feature for livekit-recorder? let's say to start/stop recorders in order to maintain 2 available recorders at all time? I think I've read something about it, but I'm not sure where
• I get a few "WARNING - Can't record audio fast enough" when it starts recording, even with 3 cpus on the recorder docker, is there anything else to tweak besides cpus count?

Right now the best way is with auto scaling based on CPU, in the future we plan on having a way to have x available at all times.

I get the same warning sometimes as well, I don't think more CPU is the best/only fix. I'll try increasing queue sizes with the next release and see if that helps

you can publish multiple (video or audio) tracks for each participant.
the api for publishing a track is
```await room.localParticipant.publishTrack(myTrack)```
<https://docs.livekit.io/guides/room/publish>

Thanks. Is it simple to make this work on livekit playground sample?

You could also just do: `room.localParticipant.setScreenShareEnabled(true);`

<@U02LPQVF6QH>, we haven't seen this before. can you check your package.lock to see which version of protobufjs it's pulling in?

<@U01KZ61GV5Z> So I made some progress.
When we generate an app using ng new it creates a default tsconfig.json file.

Adding
    `"esModuleInterop": true,`

to compilerOptions section in this file, fixes this issue.

do you have ssl certs on localhost? also, please thread the messages :pray:

no.. I am running a separate aws server with SSL certificate.. ok.. I get the point.. *wss -&gt; ws secure*

I don't see anything on the api to pause it, until they implement it, if they do, you could start and stop the recording, creating many video files and concatenate them all together as a single video after you finish, with ffmpeg or similar <https://trac.ffmpeg.org/wiki/Concatenate>

the nice thing about this aproach, is you could have a very small clip (200ms or so) with tv static or tv color bars in between each cut, so you can have a visual indicator when it was paused

`-e LIVEKIT_RECORDER_CONFIG='api_key: APIKey\napi_secret: APISecretSID\nws_url: &lt;wss:www.sample.com&gt;\nlog_level: debug\nredis:\n  address: 127.0.0.1:6379' \`

This seems to solve the specific problem above. (Not ideal for longer configuration). Now in the log, there is a message "missing request".

Server side method `startRecording` fails with "no recorders available"

you need either `SERVICE_MODE` or `RECORDING_REQUEST` when running the recorder. No recorders available means it cannot reach any recorders through redis

<https://github.com/livekit/livekit-recorder/blob/main/README.md>

`-e SERVICE_MODE=1`  was missing.

 Now the recorder is starting in service mode correctly.

 Trying to start recording using

 `const livekitApi = require('livekit-server-sdk');`
`const input = "{layout: 'grid-dark',room_name: 'classRoom2'}"`

`const output = "path/recording.mp4";`

`const recordingClient = new NewRecordingServiceClient("<https://www.sample.com>", "APIKey", "APISecret");`
`recordingClient.startRecording(input, output)`
`.then(response =&gt; {console.log(response)})`
`.catch(err =&gt; {console.log(err)});`

I am getting a valid recordingId

However, it is failing on server side with the below messages.

`Nov 10 03:12:37 ip-172-31-1-45 docker[1147028]: {"level":"debug","ts":1636513957.762388,"logger":"livekit-recorder","caller":"display/display_prod.go:61","msg":"launching chrome"}`
`Nov 10 03:12:38 ip-172-31-1-45 docker[1147028]: {"level":"error","ts":1636513958.231491,"logger":"livekit-recorder","caller":"recorder/recorder.go:44","msg":"error launching display","error":"Cannot navigate to invalid URL (-32000)","stacktrace":"<http://github.com/livekit/livekit-recorder/pkg/recorder.(*Recorder).Run|github.com/livekit/livekit-recorder/pkg/recorder.(*Recorder).Run>\n\t/workspace/pkg/recorder/recorder.go:44\<http://ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRequest.func1|ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRequest.func1>\n\t/workspace/pkg/service/handler.go:85"}`
`Nov 10 03:12:38 ip-172-31-1-45 docker[1147028]: {"level":"error","ts":1636513958.2315826,"logger":"livekit-recorder","caller":"service/handler.go:129","msg":"recording failed","recordingId":"RR_Mnn9rSQy2fwK","error":"Cannot navigate to invalid URL (-32000)","stacktrace":"<http://github.com/livekit/livekit-recorder/pkg/service.LogResult|github.com/livekit/livekit-recorder/pkg/service.LogResult>\n\t/workspace/pkg/service/handler.go:129\<http://ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRecording|ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).handleRecording>\n\t/workspace/pkg/service/handler.go:43\<http://ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).Run|ngithub.com/livekit/livekit-recorder/pkg/service.(*Service).Run>\n\t/workspace/pkg/service/service.go:83\nmain.runService\n\t/workspace/cmd/server/service.go:52\nmain.run\n\t/workspace/cmd/server/main.go:62\<http://ngithub.com/urfave/cli/v2.(*App).RunContext|ngithub.com/urfave/cli/v2.(*App).RunContext>\n\t/root/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:322\<http://ngithub.com/urfave/cli/v2.(*App).Run|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:55\nruntime.main\n\t/usr/lib/go-1.16/src/runtime/proc.go:225"}`
`Nov 10 03:12:38 ip-172-31-1-45 docker[1147028]: {"level":"debug","ts":1636513958.2821114,"logger":"livekit-recorder","caller":"service/service.go:58","msg":"recorder waiting"}`

What could be possible reasons for the error `"Cannot navigate to invalid URL (-32000)"`. It is not printing that actual "invalid" url in the logs.

Please help.

check your `ws_url` in your config, when you use a template the input url is built using that

Got it... const input = "{layout: 'grid-dark',room_name: 'classRoom2'}" changed to json {layout: 'grid-dark',roomName: 'classRoom1', token:undefined} and I am past that hurdle... Thanks.

there's even a repo for multistream recorder that does this render to canvas thing I mentioned: <https://github.com/streamproc/MediaStreamRecorder>

Screen Shot 2021-11-09 at 11.46.47 AM.png

We ran into too many issues with recording methods based on `getUserMedia()` once you have more than a couple users in the room - MediaStreamRecorder uses this and their README says it can only handle 4 tracks.

We would also need gstreamer either way for conversion to rtmp output

also, we wanted something that'd be flexible for the developer to easily customize the composed UI, rather than having to deal with canvases or something else. a web view is generally simple enough to build, and works the same way as building a livekit-enabled app.

Screen Shot 2021-11-08 at 7.03.23 PM.png

It only happens when the SFU server is in a region far away from the signaling server

hey <@U02BBKNMF1C> can you provide more details on this? which version of the server, and detailed steps to reproducing this.

Users connect to the signaling server in a region near us-east1 the SFU server where the room was assigned is in a region far away us-west2. I run a stress test with 200 simultaneous users only half successfully connected.
This problem does not happen when the signaling server and the SFU are in close proximity with low latency.

Screen Shot 2021-11-10 at 12.34.29 AM.png

thanks, this is helpful. we are able to get a repro. will investigate

Hi <@U01KZ61GV5Z>, you were able to replicate the error?

<@U02BBKNMF1C> yes, sorry I forgot to update the thread. We fixed the issue in master, and will be cutting a build shortly. if you have a chance, could you try docker tag v0.14.2-SNAPSHOT4?

I'm pretty confident it's the same issue as you saw, we were able to replicate locks during load testing last week

I see strange behavior with that version, users are assigned to different nodes when they belong to the same room.

is that because the initial node is overloaded? CC: <@U02BBTRGF98>

That is possible. If the node becomes overloaded to the point it is not able to process messages, it will be unregistered after a few seconds, and users will be routed to the next available node

The problem is still present in v0.14.2-SNAPSHOT4, we have been able to solve it by adding a small delay between the entry of one user and another, apparently the problem is caused by the burst of users connecting to a single node almost instantaneously.

another thing I noticed, is a huge slowdown everytime the video is unmuted (even with the spinner fix) it starts dropping audio frames for a few seconds (WARNING - Can't record audio fast enough).

The audio frame dropping happens at the start of the recording, and every time after unmuting the video.

thanks for reporting this <@U02HN8GPUBY>. To help us keep track of this, could you file it as an issue in the recorder repo?

done <https://github.com/livekit/livekit-recorder/issues/22> :wink:

Adding the following between `x264Enc` and `videoQueue` should do it:
```	profileFilter, err := gst.NewElement("capsfilter")
	if err != nil {
		return nil, err
	}
	err = profileFilter.SetProperty("caps", gst.NewCapsFromString("video/x-h264, profile=baseline"))
	if err != nil {
		return nil, err
	}```
(also add `profileFilter` to the bin on L135 and videoElements on L153)

I think they should match. please file an issue.

LiveKit manages its own "mute" in the metadata layer. this allows us to emit 'TrackMuted' events for other RemoteParticipants

I was looking for this solution too. As a work around I generate token for smaller time duration because token need to validate during first join only, I guess.

<@U02HN8GPUBY> would you mind describing the use case you need this functionality for? :pray::skin-tone-4: 

Jibon, curious on yours, as well. Could you tell us more about why you need this? (To be clear, we’re open to these requests, just want to understand them first! :))

<@U01KZ0SCDKL>, sure, in my case we use livekit for telemedicine, so a healthcare operator may need real time support from a remote specialist, so it makes such request, which is then associated with a unique randomly generated livekit room, and everything that happens on it is stored on a backend according government regulations (video, audio, timestamps, healthcare telemetry on webrtc datachannels, etc), once the request have been fulfilled, the room is closed, the video capture if finished, and all data is stored and archived for auditing. When we reach that point, we can't allow to re-open the same room, since that will mess things up.

so, as things work today with livekit, we don't let users join a room that has been marked as "finished" in our backend, but we do that in the application level, nothing stops people from re-using the livekit token (while still valid) to re-create the same room using a standard livekit client.

if we could choose to have some specific grants on the livekit tokens, not to auto-create a room if it doesn't exist, it will give us more freedom to create/delete rooms and have full control over its life cycle, not having to control all that on the application level.