Cloud Entrepreneurship Sotfware & Developers & DevOps Tools & How-Tos

Fixing recording unavailable on jitsi docker

Recording unavailable jitsi

Many organizations and engineers are making video conferencing applications during the pandemic for online learning facilities, making webinars, greeting friends with friends. As well as many companies are competing to build video conferencing applications there is were jitsi recording comes in. Some want to make webinars, take private lessons. The conferencing gains a major role as we speak; a major need that I would not advise you to miss, specially during the current pandemic. People can meet and tell how to do things, record their work plans, or they can record their conversations when the conference starts.

Lastly the recording feature will always be very important in building a video conferencing tool. In other words making recordings function during conferences is something that needs to be considered when building a video conference application.

You landed at the cloud storage of the internet. Cloud Storage Services Sesame Disk by NiHao Cloud

Use it for free NOW!

A Team File sharing system that works in China, USA, Europe, APAC and everywhere else.

how to enable recording on jitsi?

A recording is a very important digital tool in conducting conferences during online meetings. With this function, we can understand what case studies are in the meeting if there are some people who don’t attend the meeting. Recording helps us to remember when we have a conference.

Some people need a recording to remember the meeting when and with what theme.

In this first step, we will check some configurations on the server so that jitsi can make recordings during the conference. We need to enable jibri because jibri has a configuration for recording to run on jitsi. If you don’t know how to install jitsi on docker, you can read the article jitsi with docker.

When recording is unavailable on jitsi, you can check on github about recording fails. The first thing you need to do is look at the logs of the Jibri container. Let’s see what happens to the jibri container, we will check the container logs on the jibri. Check container logs with “docker-compose logs container_name”.

docker-compose -f docker-compose.yml -f jibri.yml logs jibri
jibri container logs

jibri has a problem with the container, let’s check the container process.

docker-compose -f docker-compose.yml -f jibri.yml ps
process docker-compose jitsi

The command docker-compose -f docker-compose -f jibri.yml ps is useful for viewing all running container processes. It looks like the Jibri container is not running properly, the container keeps restarting. Let’s try to check what the problem is with the server.

Our first step will be to check the alsa-loopback module on the server, this module is used by jibri to make recordings run well on the server. Check alsa-loopback module with command “arecord”.

arecord -L
arecord command jitsi

Checking kernel

That right, the alsa-loopback module doesn’t work properly on the server. We will check the kernel first with “uname -r”.

uname -r
check kernel generic

It looks like the generic kernel is already installed on the server, Let’s try to enable the alsa-loopback module. We can activate alsa-loopback with command “modprobe”.

sudo modprobe snd-aloop

We have enabled the alsa-loopback module with modprobe. Let’s check on the server to see if the alsa-loopback module is active, we can check with arecord command. The arecord command is useful for viewing the alsa-loopback driver that is already active on the server.

arecord -L
arecord command

We can make the alsa-loopback module run permanently without modprobe on our server so that when we reboot the server, the alsa-loopback module will continue to run automatically on our server. Adding snd-aloop to the /etc/modules file with the “echo and tee” command will make it easier for us.

echo snd-aloop | tee -a /etc/modules
Adding module snd-aloop

We will try to check the configuration on jibri.yml, this file is used to create a jibri container.

version: '3'

        image: jitsi/jibri:latest
        restart: ${RESTART_POLICY}
            - ${CONFIG}/jibri:/config:Z
            - /dev/shm:/dev/shm
            - SYS_ADMIN
            - NET_BIND_SERVICE
            - /dev/snd:/dev/snd
            - PUBLIC_URL
            - XMPP_AUTH_DOMAIN
            - XMPP_SERVER
            - XMPP_DOMAIN
            - JIBRI_XMPP_USER
            - JIBRI_BREWERY_MUC
            - JIBRI_LOGS_DIR
            - DISPLAY=:0
            - TZ
            - jicofo

Looks good for the jibri.yml file, in that file we change the network in docker to use our own network. Docker network allows container networks to connect to each other, we can use our own domain to create a network on docker.

Checking ENV File

Env file is used to store variables. This file contains declarations or the creation of env variables which will eventually be loaded on the container. Env files are very important for configuring the environment in jitsi. In the env there are many configurations for setting the container. This setting is what we will call in docker compose so that it can be applied to the container. There are many variables that we will configure such as public url, port, ssl, jvb, jibri, and many more.

In this step we will configure the env file to use recording in docker, let’s start to see the env configuration in docker jitsi. First step we need to enable rest api on JVB,

# A comma separated list of APIs to enable when the JVB is started [default: none]
# See for more information

This api helps for recording to run on docker jitsi. Next we need to enable variable recording in jitsi. To enable recording, we need to remove the fence in front of the variable ENABLE_RECORDING=1

# Enable recording

In the variable ENABLE_RECORDING=1 for feature recording on jitsi can be enabled on the server. This will bring up the recording menu when the moderator starts the meeting. Don’t forget to edit the xmpp domain name if you are using a different docker network than the default.

# XMPP domain for the jibri recorder

# XMPP recorder user for Jibri client connections

# Directory for recordings inside Jibri container

# The finalizing script. Will run after recording is complete

# XMPP user for Jibri client connections

# MUC name for the Jibri pool

# MUC connection timeout

# When jibri gets a request to start a service for a room, the room
# jid will look like: [email protected]_domain
# We'll build the url for the call by transforming that into:
# https://xmpp_domain/subdomain/roomName
# So if there are any prefixes in the jid (like jitsi meet, which
# has its participants join a muc at conference.xmpp_domain) then
# list that prefix here so it can be stripped out to generate
# the call url correctly

Looks good, we have configured the env file so that recording can be used. Let’s build a docker jitsi container using command “docker compose up -d”.

docker-compose -f docker-compose.yml -f jibri.yml up -d
docker compose up

Wait until the process of building the jitsi container is complete, when finished, let’s check all the services running on the container with command “docker compose ps”.

docker-compose -f docker-compose.yml -f jibri.yml ps
jibri docker compose ps

The jibri container is running fine, let’s look at the logs on the container with command “docker compose logs”.

docker compose logs jibri

Let’s try jitsi recording of a conference

It looks like jibri is running well on the logs container. Let’s try conferencing using the jitsi server.

recording conference

Recording on jitsi is currently running well, for files from recording you can see at ~/.jitsi-meet-cfg/jibri/recordings. Or you can custom config jitsi in a certain directory.

Jibri recording directory

If you follow the post your recording should be working well now on the server. Otherwise feel free to comment about the issues you face. At this point moderators can make recordings when starting a conference. This issue with the lsa-loopback module is common specially as some cloud providers do not provide generic kernels capable of accommodating jitsi’s requirements. In this case we had already changed the kernel to generic, but the alsa-loopback module was not yet active. As a consequence it can be confusing when trying to figure out what’s going on. Don’t forget to read our interesting articles, or you can choose our cloud storage products for your data storage. Have a nice day.

Hits: 142

By Budi Santoso

Budi Santoso is a Development Operations and Technical Writer with experience in cloud, server operating systems, and CICD. Enthusiastic to continue to develop learning technology topics and have a passion for information technology.

Leave a Reply

Your email address will not be published. Required fields are marked *