-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting Meetings Issues
Sometimes when using the Jitsi Meet platform there can be issues. Many of these issues can be resolved through changing specific configuration settings, but often times they occur in the middle of a meeting, when you don't have time to get a developer to make configuration changes. When this happens, you may need to try some of the steps below to resolve your issue immediately.
If you are unable to hear another participant, try these steps in the following order:
- Check that their microphone is on. This can be done by looking at their thumbnail and finding the microphone. If the microphone has a slash through it, the participant is muted. They will need to unmute themselves in order to be heard by other participants.
- Ask the participant to try muting and unmuting themselves. This will reset the audio for the participant.
- Have the participant refresh the meeting.
If you are unable to see another participant's screen during a screen share (if it is black or all you see are their initials):
- Try turning off the screen share, going to Settings > More and changing the desktop sharing frame rate (either go up, or go down slightly, any change will reset the screen sharing settings). Try sharing your screen again.
You can try to use a different web browser (in my tests, Firefox has been the most reliable). Some versions of some browsers are known to have issues with Jitsi Meet.
This guide was built to list the various errors and issues a developer can encounter while working on the Intulse Meetings project. While working on the project, if you encounter issues related to development (inability to run the project, cannot access APis, etc.) please add them to this wiki for future developers to reference.
When testing Intulse Meetings we use a virtual server. This doesn’t happen often, but sometimes the virtual server’s IP address can change. When it does, you need to uninstall and reinstall Jitsi Meet to the server and change the IP address that the meetings project uses for testing. Follow the following instructions to do this:
- Go to the hosts file on the server and your local machine (located at etc/hosts) and change the ip address that points to the website
- Go to https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart#uninstall
- Follow to uninstall steps (NOTE: It does not matter which folder you are in on the server when doing this)
- Follow the install steps
- When prompted, use the new ip address as the host name
- This will then ask you about the SSL certificate. When it does: Generate a new self-signed certificate
- When prompted, use the new ip address as the host name
- Navigate to your jitsi-meet folder (the one with Intulse’s code)
- Run ./deploy-local.sh (sudo bash ./deploy-local.sh)
Sometimes after upgrading to a new version of Jitsi Meet, old config files can persist and cause issues. In order to properly fix this, it is best to uninstall and reinstall all Jitsi Meet packages and see if that resolves the issues.
When trying to run the "make" command, sometimes you will see logging issues or other errors. This usually means you need to run npm install. If you are running into issues running npm install, try deleting the package-lock.json file (it will be recreated automatically when you run make).
Sometimes when Jitsi makes changes to the codebase it creates video quality issues. These issues most often appear in the video streams, but it can also cause issues with screen sharing. The first step to troubleshoot these issues is to see if there are any error in the browser console logs. If there are, then search the Jitsi Meet forums and see how others have resolved those particular errors. If no one else has shared about this issue, ask it in the Jitsi Meet forums (I have found that the forums are fairly responsive if you include the specific errors you are encountering). If there are no errors in the console logs, then you may have to disable simulcast (set disableSimulcast setting in the config.js file to true) and disable layer suspension (set enableLayerSuspension setting in the config.js file to false).
sudo apt purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-meet-web jicofo jitsi-videobridge2
Sometimes the following packages will fail to uninstall properly:
jigasi
jitsi-videobridge
When this happens, just run the uninstall command a second time and it should be ok.
The reason for the failure is that sometimes the uninstall script is faster than the process that stops the daemons. The second run of the uninstall command fixes this, as by then the jigasi or jitsi-videobridge daemons are already stopped.
Note, when you reinstall the packages you will be prompted to assign SSL certificates. You can start with a self-signed certificate by assigning the host requested to meet.intul.se and then use the letsencrypt script that will be added to /usr/share/jitsi-meet/scripts.
Additionally, you may in into issues with nginx after reinstalling all of the Jitsi packages. You can check the status of nginx using:
sudo systemctl status nginx
If you do not check the status, you will know if there is an issue with nginx if, when connecting two participants in a meeting, both of them get disconnected from the meeting immediately (you will see the disconnection on the screen and in the developer console logs by pressing F12).
This issue is caused by Jitsi Meet putting the configuration file in the wrong nginx configuration directory. You can correct this by running the following three commands:
sudo mv /etc/nginx/modules-enabled/60-jitsi-meet.conf /etc/nginx/modules-available
sudo service nginx stop
sudo service nginx start
Oftentimes, when reviewing the Jitsi Meet forums, they will claim that one of the issues being encountered is actually the fault of webrtc, rather than Jitsi Meet itself. One way to test this is to run a webrtc sample and attempt to recreate the issue there. If you can recreate the issue there, then you can confirm that webrtc is at fault and not Jitsi Meet.
Note, if you discover that webrtc is at fault, then there is really nothing that can be done about the issue (except for informing the webrtc team about it). It also means that building our own application will still retain the issue as well (because we would still be using webrtc).
You can find the webrtc samples here:
https://webrtc.github.io/samples/
Or you can test a browsers compatibility with webrtc here:
If participants cannot see or hear each other, double check the firewall / NAT rules.
/var/log/jitsi/jvb.log
/var/log/jitsi/jicofo.log
/var/log/prosody/prosody.log