Custom poll answers were previously printed into the gnuplot control
file directly, between double-quotes. As a result, if a poll answer
contains a double-quote, it could cause a syntax error in the gnuplot
script, or worse.
Gnuplot accepts standard C-style double-quoted string escapes, so I can
just use ruby's "inspect" method to generate a safetly escaped string.
Note that within the string, % still has to be escaped separately
(doubled) to avoid issues with the string formatting. As well, I have
disabled "enhanced" mode which allows using special characters for
formatting commands.
Fixes#3039
These were commented out, apparently by accident, when the metadata code
was being refactored. The effect was that the $meeting_end variable was
treated as if it had a value of zero, meaning that the last slide had a
start time of some positive number and an end time of zero. As a result,
it was never shown (and didn't get any shapes either).
Fixes#3021
This allows configuring a server to use https without having to edit
any ruby files directly.
(Ideally, the metadata files wouldn't include the server name/protocol
at all; that should be set dynamically by bbb-web, but this is what we
have for now.)
This fixes loading the shapes svg, and the events and cursor xml files
on servers configured with https support. (Otherwise they'll be loaded
off http:// and trigger mixed-content errors).
FreeSWITCH writes wav files >4GB long with incorrect values in the length
field in the header. Recalculate the length based on file size, and ensure
that ffmpeg reads the complete audio file rather than stopping.
There were a couple of problems:
* A division by 0 when calculating the percentages
* Positioning of the number of results counter was incorrect
Fixes#2739
Note that this requires a new dependency be added to the
"bbb-playback-presentation" format; the "gnuplot" package is now
required (it's used to actually generate the chart images)
In 0.9.0, the slide clear events changed from using 1-based page numbers to
using 0-based page numbers.
Add 1 to the page number for recordings generated on a 0.9.0+ server to
fix the issue; at this point it's too late in the release to change the value,
and there's too big of a body of existing recordings out there.
If the video EDL merge function is applied to an EDL that has already
been edited to apply recording marks, the merge function will change the
video start times to incorrect values on edit points during the timestamp
recalculation.
The fix is pretty simple; just pull in the timestamps from the entry that's
being merged in and apply them to the relevant videos.
This bug doesn't currently cause any issues in the BigBlueButton recording
scripts, since the existing code does the merge before the start/stop marks
are applied. But to avoid surprises later, it would be good to fix this.
It had some leftover debug code that caused it to only convert the
first 10 recordings instead of all of them.
The name of the '.done' file is changed so the update will be re-run
automatically.
This allows them to be preserved for a period of time, rather than be
deleted immediately. Useful for recovering recordings when someone forgot
to press the record button during the session.
The slides processing scripts have never been updated for 0.9.0 events,
and probably never will be. They're still using older video/audio
processing apis that have poor sync, too. Just remove them.
The playback support files will still be installed, to allow recordings
from old BigBlueButton servers to be copied to a 0.9.0 server.
This adds the version number to the playback links so that
recordings select the correct version-specific playback support
files.
This script may be run automatically during upgrade; in that
case it should be run like
.../bbb-0.9-beta-recording-update --quiet
After copying recordings from an old BigBlueButton server, you
may want to manually re-run the script, and it takes the option
--force to recheck all recordings even if it has previously been
run.
Right now there is a possibility that the rap-worker process might
see the recording.done file (written by bbb-web) prior to Red5 having
completed writing the video files to disk.
This happens most often when a meeting end api request is sent while a
webcam is visible.
Add a delay (currently 2 minutes) before the archive scripts are run
to work around the issue. Real fix is far more complicated...
