Help Error jibri


I haven’t experienced this issue directly, but it was suggested by a team member that it may be related to the newer versions of Chrome which require user interaction before playing audio. We will experiment with selenium to determine the best way to resolve this, but for now my best guidance is to try with an older version of chrome/chromedriver and see if the problem with audio is resolved.


This has been resolved on with the latest Jibri (66) and all audio should come across in live streaming or recordings. As was suspected by Lenny, it was the issue with the new chrome not playing audio until a user interacted. The fix was to add a command line flag when launching the fake participant, to disable this feature in our chrome instance.


Hi @Aaron_K_van_Meerten @bbaldino ,

Thank you for the update. However, I am still not able to reproduce the expected behaviour. I tried the latest jibri(66) from the unstable repostiory with the latest jitsi-meet(1.0.3434) from the unstable repository. I see both the packages were uploaded on Dec 19.

Using this combination, whenever I click the Start Recording button, it prepares to record the meeting, and while the audio for Recording has started should come, the conference crashes. and jibri connection is broken. Next, when we start the recording, we need to restart the Jibri in order to at least reach the preparing to record message.

Logs for the above scenario:
Jicofo Log:
Jibri Log:

I also tried the latest jibri(66) with the latest jitsi-meet from the stable repository, i.e. version 1.0.3383, but in these, the Jibri is not found by the Jicofo and it only logs, No Jibris found and the UI says Recording unavailable.

Google Chrome Version: 71.0.3578.98
Chromedriver version: 2.45
OS: Ubuntu 16.04 LTS

@Aaron_K_van_Meerten can you let us know what is the version of Jitsi-meet on that works well with jibri(66) ?

Hi @gogekkos,

can you check and confirm the behaviour by testing this on your end?



From your pastebin logs, it appears that the jibri could not connect to your instance. It appears to be using https against an IP address, which isn’t usually supported. Also, it’s an internal IP address (10.x) so both of those are likely going to stop jibri from establishing a session:

2018-12-20 12:08:27.017 FINE: [38] org.jitsi.jibri.selenium.pageobjects.CallPage.visit() Visiting url“Jibri”

2018-12-20 12:08:58.651 SEVERE: [38] org.jitsi.jibri.selenium.pageobjects.CallPage.visit() Timed out waiting for call page to load


Hi @abhijitnathwani how are you?

In fact I have the same problem, I have done the tests and I get the same mistakes as you, we are grateful to @Aaron_K_van_Meerten and @bbaldino , to help us with the Jitsi and jibri versions that are compatible, thanks


Hello @Aaron_K_van_Meerten @Aaron_van_Meerten @abhijitnathwani @bbaldino

I found something curious, with Jibri version 5.1.58-1 recorded the video but without audio, however, when installing version 6.66 this now tells me “busy service”, I could indicate that it should be modified now, thanks


Jibri log.0.txt

Image 01

Please help


The versions running successfully on currently are jitsi-meet 3431, and jibri 67 ( a minor update from jibri 66 that simply disables chrome debug logging, so jibri 66 is just fine too ). Any versions around 3431 should be fine (3434 for instance). The individual component versions we are running on currently are: JVB 1095, Jicofo 443 and Jitsi Meet Web 3125.

The main thing to note when using different versions is that a newish Jicofo is required to use the newer Jibri. However, any JIcofo after 443 should be fine.


In this case likely you have an older jicofo which may not detect the newer jibri. You will need to upgrade your jicofo component to use the latest jibri.


Hi @Aaron_K_van_Meerten

I am testing all the deployments on the local network. Everything works fine. With the older Jibris, it is connecting and recording but no audio. So we can rule out the IP resolution issues.
I’m not sure about https connections, if you provide more information on what should be the scenario, I can test and update you.

As far the versions are concerned, I’m already running the latest of everything.

running with Jibri 66 on another VM. So I’m not sure what is the issue here :expressionless:



You’re correct, this all looks exactly right. I’ll review your pastebin logs more carefully, but it may also make sense to try to launch chrome through a remote desktop or X11 forwarded connection and browse to a meeting that way, to see if you can see any extra logs. There’s also some browser logs in the jibri directory that may assist us too. Sorry you’re experiencing this issue, I suspect there’s some kind of connection issue or javascript error that’s stopping selenium from seeing a valid working chrome session, but it’s hard to debug this kind of thing remotely.


I see nothing in the jicofo logs about discovering a Jibri, so Jicofo isn’t seeing them.

Can you do the following:

stop jibri
stop jicofo
clear the jicofo log
start jicofo
start jibri

and then include your jicofo and jibri logs?


Hello everyone, I tell you that I already have Jitsi and Jibri working correctly, the recording works with Video and audio, I share stable configuration:



However it is important to mention, that having a JIBRI server with 2 cores and 4 RAM, the audio was cut frequently, to avoid this problem, I had to increase the capacity of the server to 4 Nuclei and 15 RAM, this was the solution Now everything works wonderfully. Perform 15 tests and all perfect, recordings of 5, 15, 20, 45 and 60 minutes and all perfect.


I only have one question, if I have 4 or 5 simulated conferences and all I need to record, I know I have to create 4 or 5 new JIBRI machines, but how do I configure in JITSI that I have more JIBRI to record?

Thank you very much to the whole team for the special help to: @bbaldino @Aaron_K_van_Meerten @Aaron_K_van_Meerten @abhijitnathwani


@gogekkos the xmpp server config in jibri points it at a MUC. Jicofo joins that same MUC and considers every Jibri in that muc eligible for handling requests from clients. It will go through and find the first one that isn’t busy and forward the incoming request to it.


So, basically, if you have one working you just need to spin up more and I think make sure the nickname in the control_muc section of jibri’s config.json is different for each/


In order to have multiple JIBRIs you simply have to spin them up and connect them. Jicofo has logic to discover them in the brewery MUC and dispatch requests to them when a user requests a live stream/recording.


Hi @bbaldino,

I did as you asked. Please find the logs below:

Jicofo logs:
Jibri logs:

Please note I have upgraded everything to the latest from the unstable repo and logs are of the newer version. The recording is working fine, but still no audio :expressionless:

Jibri 6.8.68



Hi @Aaron_K_van_Meerten @bbaldino,

I still don’t have any audio. Could you please share debugging tips to narrow done why isn’t the audio recorded?

I double-checked my settings and server-configs with @gogekkos, who got audio working.



I’m honestly not sure why you’re not getting audio. Have you confirmed your alsa loopback settings are OK? You can test this by logging in as the jibri user, then using aplay to play to the loopback device and then arecord to pull from the same device and see if there’s anything but 0x0’s in the resulting output when viewed in xxd or some other hex editor (or actually download the resulting .wav and play it on a local computer). It’s important to do this as the jibri user, since that’s where the asoundrc is parsed from.

Also we’re using Chrome 71 now, likely you are too but maybe confirm that your chrome version is up to date?


Hi @Aaron_K_van_Meerten,

What settings do I look for the alsa loopback settings? I have the loopback devices listed in the aplay and arecord lists.

Google Chrome 71.0.3578.98

Also, as per your suggestion, I tried manually aplay and arecord a .mp4 file, but if I change from the root user to jibri user, I’m seeing some error in those commands about the XDG_RUNTIME_DIR. I’m not sure why is it showing.

Also, what is the passwd for the jibri user? I’m not able to run commands on sudo there.

If I could directly ssh into jibri user with the password, may be the error for the XDG_RUNTIME_DIR goes away.

P.S.: None of the errors occur in logs, when we record a jitsi meeting.



Hi @Aaron_K_van_Meerten @bbaldino,

I’m still stuck. Any insights on how I could debug?