KamoCRM

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

FixKlusterServices
관련 상품
2026년 9월 24일 오전 3:50 UTC
이름 *
Kamo
뚱 베어
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`.

모든 변경 사항

배송을 보는 것과 같이?

모든 것이 자신의 작업 공간에서 도착합니다. 무료 플랜을 시작하고 이 페이지를 다시 한 달에 읽으십시오.

무료 영원히 시작가격 비교