I just installed the official jitsi helm chart (GitHub - jitsi-contrib/jitsi-helm: A helm chart to deploy Jitsi to Kubernetes) with minor changes (as proposed here May not contain more than 1 protocol when type is 'LoadBalancer' (mixed protocols error) AWS EKS · Issue #50 · jitsi-contrib/jitsi-helm · GitHub).
The meeting works fine with 4 people, but recording simply doesn’t want to work.
I’ve had looked through the tutorial (TUTORIAL: Jibri Overview, Troubleshooting Tips & Tricks - Solve your Jibri Problems, Quickly!) but didn’t get any further.
I’ve found this thread (Jitsi Not joined yet: Cannot read properties of undefined (reading 'isJoined')) but it didn’t bring me any further
I’ve seen a suspicious line in the browser.log, but that didn’t bring me any further as i enabled neither the lobby nor have i set a password:
Jibri 2022-08-03 08:48:19.496 INFO:  JibriSelenium.leaveCallAndQuitBrowser#348: [2022-08-03T08:47:49+0200] [SEVERE] https://jitsi2.example.com/libs/app.bundle.min.js?v=6260 137:1186382 "2022-08-03T06:47:49.213Z" "[connection.js]" "\u003Cr.s>: " "CONNECTION FAILED:" "connection.passwordRequired"
As i’m not yet allowed to upload files, here are my log files and values.yaml:
Jibri log: ZeroBin.net
Browser Log: ZeroBin.net
(The real domain has been replaced by example.com on purpose)
Thanks for any help in advance!
Hi Andre, welcome to the community! Shooting a bit in the dark here, do you see anything related in the prosody and/or the Jicofo logs? Can you upload them on zerobin as well?
Thank for your quick reply!
Of course i can.
As Jicofo seems to have issues with a single jibri, i tried it with a jibri.replicaCount of 3 and the following is the output of jifico with 3 Jibris (running on three distinct cluster nodes). Recording is still not possible: ZeroBin.net
All Jibri nodes produce the same log as the one i already uploaded.
Thanks for the additional logs! Unfortunately, the prosody logs don’t have much signal, we probably need to increase the logging level so that we can see all the connection attempts as well as attach the error logs which presumably have the failed join attempts.
The Jicofo logs show that your Jibri is attempting to join but it fails. Then it retries, so it’s been kept busy. That’s healthy behavior as far as I can tell.
Your jibri spins up a Chrome instance and tries to connect to this url. Can you maybe try to join the same url (make sure you change the room name in the url) and see if you’re getting the same error as your Jibri?
Thanks for your information.
I increased the log level, tried it again with three Jibri-Nodes and here are the logs: ZeroBin.net
I already recognized the Url you mentioned earlier and tried to open it locally as follows. That perfectly worked on my local machine and the chrome instance joined the conference. (Don’t be confused by the zshell escaping in the Url)
/usr/bin/google-chrome --allow-pre-commit-input --autoplay-policy=no-user-gesture-required --disable-background-networking --disable-client-side-phishing-detection --disable-default-apps --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --enable-automation --enable-blink-features=ShadowDOMV0 --enable-logging --enabled --kiosk --log-level=0 --no-first-run --no-service-autorun --password-store=basic --remote-debugging-port=0 --start-maximized --test-type=webdriver --use-fake-ui-for-media-stream --use-mock-keychain --user-data-dir=/tmp/.com.google.Chrome.y58Qhq https://jitsi2.example.com/chemicalcountsresignamazingly\#config.iAmRecorder\=true\&config.externalConnectUrl\=null\&config.startWithAudioMuted\=true\&config.startWithVideoMuted\=true\&interfaceConfig.APP_NAME\="Jibri"\&config.analytics.disabled=true\&config.p2p.enabled=false\&config.prejoinPageEnabled=false\&config.prejoinConfig.enabled=false\&config.requireDisplayName=false
Edit: Sorry, i forgot the error logs. Where can i find the ones you’re looking for?
That’s very strange…
You should be able to find them in /var/log/prosody/prosody.err.
There are no logs available at this path
Just to be sure: I changed the log-level of prosody by setting the environment variable “LOG_LEVEL” to “debug”.