KamoCRM

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

FixKlusterServices
Name
lúc 03:50 24 tháng 9, 2026 UTC
Tác giả
Kamo
Cam kết
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`.

Mọi thay đổi

Như những gì anh thấy vận chuyển?

Tất cả những thứ đó đều đến trong không gian làm việc của anh. Bắt đầu với kế hoạch miễn phí và đọc lại trang này trong một tháng.

Bắt đầu tự do mãi mãiXem truy cập