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

Fixing recording unavailable on jitsi docker

Recording unavailable jitsi

Many of us make video conferencing applications during the pandemic for online learning facilities, making webinars, greeting friends with friends. 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 conference is a major need that cannot be missed, 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.

The recording feature is very important in building a video conference, making recordings function during conferences is something that needs to be considered when building a video conference application.

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.

Maybe we think it is necessary to enable recording at the meeting because things at the conference must be documented. 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 followed the post your recording should be working well now on our server. 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 accomodating 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: 11

Entrepreneurship Management and Projects Sotfware & Developers & DevOps Tools & How-Tos

What is Agile Automation Framework?

Agile Automation Testing is a methodology for implementing automated tests in agile software development. The aim of agile, automated testing is to increase the effectiveness and efficiency of the software development lifecycle while preserving quality, timeliness, and resource utilization. As a result, implementing such a procedure needs extensive coordination and cooperation across teams.

In the past few years, ever since the agile approach was introduced with its creators demanding an end to the tedious and complex reality of the old waterfall model, the effect of the same can also be seen regarding Automation Testing.

A real example of a financial service organization that developed a large-scale agile capacity to meet its aspirational automation goals. The firm began implementing agile methods in phases, beginning with its software development teams. It then implemented agile across teams to facilitate collaboration and the sharing of best practices. Finally, the firm convinced the program’s leadership to make the method the default for all automation initiatives. Since the transformation, the firm has seen project delivery times decrease by about 30% and expenses decrease by 15% to 20% across six distinct business lines.

Agile Automation
Automation in Agile

Automation in Waterfall

Within the context of the waterfall, automation testing is typically feasible when the application is consistent and reliable. The requirement requires a significant amount of time and a team of highly skilled automation expert resources, and a significant amount of set-up costs in most instances. Automation Testing’s primary goal is to decrease expenses over time and maximizes. Moreover, it guarantees that no new problems occur due to current test cases.

How to do Agile Automation as a Methodology

By definition, the agile approach emphasizes eliminating time-consuming and tedious documentation to facilitate the implementation of unique and innovative ideas and for people to communicate freely to reduce the implementation of more exploratory ideas.

As a result, we may see a conflict between the core principles of agile methods and automated testing.

Why is Agile Automation Necessary for Testing?

Automation results in improved production and cost savings. Automation has grown so embedded in agile software development so that it’s impossible to imagine one without the other.

We discussed the primary reasons why automation is necessary for agile testing methodology:

Incremental Development: 

The shortest development cycle is the primary reason that requires automation in agile testing. Agile Scrum teams have few weeks to understand the requirements, modify the code, and test the revised code. If we perform all the testing manually, the time needed would force scrum masters to exceed the time spent on development. As a result, we will have to rush the testing process hence results in reducing the overall quality.

Continual Modifications: 

Agile projects do not operate under a complete set of criteria. The requirements evolve over time and often alter in response to changing client requirements, market developments, and end-user needs. While the agile method’s most advantageous characteristic is its rapid flexibility to change, this also means that testing must be flexible enough to keep up with the changes. Moreover, Automation provides testing with the required agility and enables it to react more quickly and adaptable to changes.

Continuous assessment: 

Agility demands frequent testing. The newly introduced code is covered by the tests and the code from earlier versions. This is to verify that no previously implemented functionality is damaged due to the newly introduced feature. This puts a great deal of strain on the testers and may harm the product’s quality. By automating specific tests, testers get more time for exploratory testing.

Gain immediate insight into the quality of your code: 

Automation testing enables you to rapidly test your code using a standard set of test scripts. This provides the software tester and developer with an early indication of the code’s reliability and allows them more time to respond if the code falls short of expectations.

Testing support functions: 

Automation in testing may be used to automate test script execution against code and data setup, test result validation, and test reporting. Agile development needs continuous code releases, which can be automated. This relieves testers of tedious, repeated duties, allowing them to concentrate on testing.

Regression testing: 

Automation enables testing to be performed indefinitely, allowing for a thorough study of the code. This is very beneficial when dealing with a restricted testing window and guaranteeing code quality.

Agile Automation Tools

As discussed, not all the tests should be automated in Agile. However, the automated testing tool used by Agile teams should cover as much of the testing scope as feasible.

To do this, the team must examine the following factors while choosing an automation tool, keeping in mind the Agile methodology’s nature:

  • The tool must be compatible with all operating systems on which the program expects to operate; it must also support various devices and browsers for parallel testing.
  • The technology’s learning curve should be minimal, allowing all QA teams to involve rapidly; the solution has comprehensive reporting and integration features.
  • Apart from these criteria, the team must consider other factors while determining the most suitable automation tool for their projects.

Some important tools that cover all the above-listed requirements are:

  • Selenium
  • Kobiton
  • TestProject
  • Ranorex
  • Eggplant
  • Subject7
  • LambdaTest
  • IBM Rational Functional Tester
  • Katalon Studio


The growing need for Agile applications by virtually every software development team highlights automation’s competitive advantage. Although the long-term benefits of automation are unknown, QA teams must design their automation methods from the beginning.

On an individual basis, each team and company must consider additional considerations while developing an Agile automated testing plan that maximizes the methodology’s advantages.

Hits: 15