No Audio or Video on KDE 20.04 LTS install

I have a problem with Jitsi-Meet. I test with Firefox and Android app. No video or audio for host, or anyone else. (I can provide hidden network access via email with a fully qualified network URL for demo) Problem started after upgrade kubuntu Bionic18.04 LTS to kubuntu Focal 20.04 LTS and then installed latest Jitsi-meet over Bionic install. Bionic version, installed mid 2020, worked great on Bionic O/S.

I installed “Focal” O/S via disk which rewrote original “Bionic” /root partition and Focal /etc applications but saved /etc/jitsi (prosody, etc.) /etc files.

Jitsi-Meet start screen (Firefox) is functional. Open a meeting and video and audio are off. Wait about a minute and the application says will rejoin meeting and displays a progress bar. A warning says “appears you are not connected to network”. This repeats about every minute.

Jitsi-Meet versions:
$ dpkg -l | grep jitsi
ii jitsi-archive-keyring 1.0.1 all The public key for the Jitsi packages repository
ii jitsi-meet 2.0.5390-3 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.4628-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-tokens 1.0.4628-1 all Prosody token authentication plugin for Jitsi Meet
ii jitsi-meet-turnserver 1.0.4628-1 all Configures coturn to be used with Jitsi Meet
ii jitsi-meet-web 1.0.4628-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.4628-1 all Configuration for web serving of Jitsi Meet
ii jitsi-upload-integrations 0.15.15-1 all jitsi-upload-integrations
ic jitsi-videobridge 1126-1 amd64 WebRTC compatible Selective Forwarding Unit (SFU)
ii jitsi-videobridge2 2.1-416-g2f43d1b4-1 all WebRTC compatible Selective Forwarding Unit (SFU)

I reinstalled Jitsi-Meet, looked at and modified all config files as directed. Only odd thing I encountered on original install was request about tokens. I entered “jitsi-meet” but could find no guidance on that. This >new< install ofJitsi-Meet server has never worked. Found a “verify” statement in config file that said “token” so changed to “anonymous” still nojoy.

I think the fastest fix will be reinstalling Jitsi on a fresh Ubuntu 20.04. Upgrading may cause conflict issues in some cases.

I guess that would require getting certified as https legal again. Is there any way to keep that?

This is not a big deal, you can get a new TLS certificate from Let’s Encrypt

if you mean by that keeping your existing let’sencrypt account and certificates I think that backing up the /etc/letsencrypt directory and (instead of running the jitsi-meet script) then after reinstalling jitsi-meet running apt install certbot and restoring the directory should get you there,
It’s even cleaner than the let’sencrypt script since it will use the systemd timer for renewals (a feature more convenient than the cron job created by jitsi-meet script)

I did reinstall the Kubuntu 20.04 O/S and saved the letsencrypt info. Following the quick install left me with a non-working jitsi-meet. Repeatedly would not accept host login. I looked all over the Internet for days on new installs and finally found a “manual install” that spoke of using:

“internal_hash” instead of “internal_plain” in /etc/prosody/conf.avail/jitsi.your_domain.cfg.lua .

I did a purge of everything jitsi except nginx. To ensure there were no “leftovers” from previous attempts, I did
sudo -r /etc/prosody and same for /etc/jitsi.
I then did
sudo find /var -name “jitsi” -print and the same for prosody. I removed all results.
I did the same search in /usr and removed all that showed up.

I rebooted.

Now I did the “Jitsi Quick Install” at How To Install Jitsi Meet on Ubuntu 20.04 | DigitalOcean , and used “internal_hash” instead of “internal_plain” in /etc/prosody/conf.avail/jitsi.your_domain.cfg.lua .

I ran the letsencrypt script and it said I had a good cert and "installed it into nginx.
Restarted prosody, jicoco, videobridge2 AND …

Worked the first time.

I had looked at the log files and did see errors in jicofo.log before I reinstalled, but they did not tell me what was wrong.

JICOFO ERROR LOG BEFORE REINSTALL:

Jicofo 2021-03-22 22:33:37.932 SEVERE: [661] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to connect/login: SASLError using SCRAM-SHA-1: not-authorized
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:292)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1100)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:1000)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1016)
at java.base/java.lang.Thread.run(Thread.java:832)

looks like bad password

I looked at the stored passwords before and after re-installation. Before they were in plain text. After they were encrypted. The password before was bad because prosody saw the command “internal_plain” instead of “internal_hash” while creating the user ID/Password but when validating the host ID/password jicofo did use the hash algorithm. That failed because the password was in plain text, not a hash. The error said the problem was password, but did not say what was wrong with it. After, when I totally reloaded jitsi-meet, I reloaded the user list with “internal_hash” in prosody and suddenly all was well. I probably could have just changed “internal_plain” to “internal_hash” without reinstalling everything in my original installation, but I did not know if “internal_hash” was really the problem. What I report here is 20/20 hindsight.

sure - all upgrades that impact the data structure stored on the existing system have potential problems and as of the Murphy law usually do have problems and to solve them you have to understand the structural change. Or use the Alexander method and redo everything.