Changing the default value from http to https. At this point the playback links generated in the recording metadata.xml files should default to httpS protocol
This is a workaround for #19178 - but it does not fix the issue. The
caption recording events with invalid empty `<locale/>` are simply
dropped with a warning message, to allow the recording and any valid
caption streams present to be processed.
Co-authored-by: Calvin Walton <calvin.walton@blindsidenetworks.com>
Both bbb-playback and the recording processing scripts fail if the version string is not in the format MAJOR.MINOR.PATCH (3.0.0 in this case instead of 3.0)
Recording archive may fail when remuxing invalid files from KMS or the
new recorder - eg when the raw files are 0-byte sized.
This commit handles the exception raised by EDL::encode so archive keeps
going, logs the issue as a warning and archives the problematic file anyways.
EDL::encode now removes the temporary file when the ffmpeg command execution
fails - this should avoid leaving any stale files around in case of failure.
No specific check for the nature of the error is done - the idea is that
subsequent phases will discard or fix the files if necessary according
to the processing scripts' necessities, making the behavior (in this
specific scenario) similar to what it was before the archive remuxing was
introduced.
Kurento may *rarely* generate WebM/MKV files with corrupt or absent
SeekHead sectors. bbb-webrtc-recorder also doesn't generate SeekHead or
even the Cues sectors by default.
While those are are *optional* fields by spec, files need to be seekable
for our recording processing scripts to work.
This commit adds a remuxing step for Kurento and bbb-webrtc-recorder raw
files that is executed during the archive phase. It should re-include
any of the missing fields that make files seekable and restore the Cues
sector in WebM files.
- Update the version to 2.6.0 to ease the detection of old/new whiteboard events
- Fix recording cursor when there is no pan/zoom and annotations in tldraw
- Don't generate slides pngs for 2.6.0, they are not used anymore in playback (svgs instead).
In BBB 2.5, we switched the recording system to use bundled gems
included privately in the recording package, rather than installed
system-wide. The rap-enqueue.rb script needs to be updated to load the
bundler gems.
According to bundler devs, setting the BUNDLE_GEMFILE environement
variable is the supported way to tell bundler where to find it
(otherwise bundler will search starting at the current working directory
- which in the case of rap-enqueue.rb is probably nowhere near the
Gemfile).
Use a relative path from the directory where the script is located so it
can be run both when installed and from a development environment.
Switch the script interpreter to use /usr/bin/env to load ruby from the
path. Doesn't make a difference in the installed package, but it makes
testing on development systems with multiple ruby environments easier.
Fixes#15085
Several scripts internally run bundler setup, so no explicit bundler
command is needed. For the others, start up using /usr/bin/bundle
(installed by ruby-bundler) to load the environment.
Move all Etherpad's access control from Meteor to a separated [Node application](https://github.com/bigbluebutton/bbb-pads).
This new app uses [Etherpad's API](https://etherpad.org/doc/v1.8.4/#index_overview)
to create groups and manage session tokens for users to access them. Each group
represents one distinct pad at the html5 client.
- Removed locked users' access to pads: replaced readOnly pad's access with a new pad's content sharing routine
- Pad's access is now controlled by [Etherpad's API](https://etherpad.org/doc/v1.8.4/#index_overview)
- Closed captions edited content now reflects at it's live feedback
- Improved closed caption's dictation mode live feedback
- Moved all Etherpad's API control from Meteor to a separated [app](https://github.com/bigbluebutton/bbb-pads)
- Included access control both in akka-apps and bbb-pads
I was going to resort to some trickery to make mediasoup raw files end up in the
same directory as KMS to reduce changes, but it ended up being too dirty.
I am adding a third directory (/var/mediasoup) to be tracked by the rap scripts
which is where the new raw files end up in.
Move the handling of chat events into the shared library so it can be
used by multiple recording formats.
The anonymization of names is based on the external user id, if
available, so users have a consistent name through the meeting. Note
that no effort is made to edit chat messages - if someone is mentioned
by name in a chat message, that will still be visible.
Default settings for anonymization can be controlled in
bigbluebutton.yml, and per-meeting overrides can be done using meta
parameters on the create call.
Previously, bbb-record --rebuild was restarting recording processing
from scratch by creating the .../recording/<meeting_id>.done file. This
causes the recording to be reprocessed starting at the archive step.
However, re-running the archive step for an existing meeting is not
really supported! Ever since the segmented recording code was added, it
shouldn't /corrupt/ the recording files, but it's still not good.
And as a side-effect, re-running the archive step will re-create the
.norecord file for meetings without recording marks, meaning that you
cannot use bbb-record --rebuild to force a recording without marks to be
processed.
Switch bbb-record to restart recording processing at the sanity stage to
match the BBB 2.2 behaviour. Rather than have it insert tasks directly
into resque via redis-cli, it goes through a ruby wrapper that performs
input validation and uses the resque apis.
Since Meteor was split in multiple process and events started to be
filtered by instances, all Etherpad's Redis events were being discarded.
Etherpad has a Redis' publisher plugin that is unaware of BigBlueButton's
existence. All the communication between them is kept simple with minimal
of internal data exchange. The concept of distincts subscribers at Meteor's
side broke part of this simplicity and, now, Etherpad has to know which
instance must receive it's messages. To provide such information I decided
to include Meteor's instance as part of the pad's id. Should look like:
- [instanceId]padId for the shared notes
- [instanceId]padId_cc_(locale) for the closed captions
With those changes the pad id generation made at the recording scripts had to
be re-done because there is no instance id available. Pad id is now recorded at
akka-apps and queried while archiving the shared notes.
When managing Etherpad's pads, Meteor makes API calls to initiate the closed captions
and shared notes modules. The pad id was being mapped to a shorter id than the meeting
id because of a Etherpad lenght limitation.
Changed to something less guessable.
