This message was deleted.

Hey @full-dog-23669 , you can include the minified client SDK directly like this:

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

Many thanks for that @dry-elephant-14928 - 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:

<script src="<https://cdn.jsdelivr.net/npm/livekit-client/dist/livekit-client.umd.min.js>"></script>
<script>
// 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,
  },
});
</script>

ah sorry I forgot to mention, you would need to prefix the class names with

LivekitClient.

, i.e.

LivekitClient.Room

Hi @dry-elephant-14928, 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 @full-dog-23669, 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 here

const stats = await remoteVideoTrack.receiver.getStats();
          stats.forEach((val: any) => {
            if (val.type === "inbound-rtp") {
              if (val["framesPerSecond"]) {
                console.log('current fps', val["framesPerSecond"]);
              }
            }
          });

Hi @dry-elephant-14928, 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.

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