KamoCRM

Recording had never worked — jicofo never looked for jibri, and jibri never arrived

FixKlusterServices
Szycy
24 września 2026 03:50 UTC
Autor
Kamo
Pochęt się
e5497a4

Four separate faults, each enough on its own to stop every recording: - jicofo had no ENABLE_RECORDING, so the image wrote no `jibri {}` block: it never watched the brewery and refused every start request. Prosody and jibri had it on. - JIBRI_BREWERY_MUC held a full JID; the image appends the domain itself, giving **************** Prosody answered item-not-found and jibri, which does not retry, never once joined the brewery. - No PUBLIC_URL, so jibri's Chrome would have opened https://meet.Meet/<room>, which resolves nowhere. It now records through the shared host, which serves every tenant. - XMPP_RECORDER_DOMAIN is read by nothing; replaced with XMPP_HIDDEN_DOMAIN, the domain the recorder really signs in on (and the meet page's hiddenDomain must match). Prosody now loads filter_iq_jibri, so a member token whose features say recording is off is refused a start, not just shown no button. Tokens without features fall back to "is a moderator", as before. finalize.sh removes its copy once MediaService has stored it (or refused it because the organization may not record, a PHI tenant whose copy must not linger). Nothing else ever pruned the 50Gi volume. It also sends the real content type; curl's default was application/octet-stream, which MinIO stored. Verified live: a two-participant meeting recorded through jicofo → jibri → ffmpeg → finalize → MediaService ingest, and a token with recording:false was refused with `forbidden`.

Wszystkie zmiany

Jak to, co widzisz żeglugę?

Wszystko to pojawia się w twoim miejscu pracy na własną rękę. Zacznij od bezpłatnego planu i przeczytaj tę stronę ponownie w miesiącu.

Start Free ForeverZobacz ceny