It used to print:
Failed to download file: undefined local variable or method `respose' for BigBlueButton:Module
Did you mean? response
because the incorrect variable name was used in the error message.
There was no effect other than the message in the log, since the shared notes
couldn't be archived anyways, and the only thing the exception did was ...
prevent the shared notes from being archived.
FFmpeg has pretty good format autodetection even if the filename has the
'.txt' extension, so just rely on that. It'll even pull subtitles out of
video files - although I expect we'll have size limits so that doesn't
happen.
Rather than running the tool in a loop, I'm using inotify to watch for
new files being created (ideally, the other rap workers will be migrated
to this style in the future). The trigger for processing is the creation
of the .json index file for the uploaded track.
Sometimes when text is pasted into the whiteboard text tool from
external apps, it'll include control characters that mess up later
recording processing scripts.
Run the same cleanup as already used for chat messages on the whiteboard
text as well.
The cleanup has been adjusted to allow newline and tab characters. They
won't really cause issues in chat, and newlines (at a minimum) are
required for the whiteboard.
This is a workaround for #7356
This was added to workaround for red5 taking a while to rewrite the
serialized (.ser) data that it streams to disk back to the .flv format.
The workaround is no longer needed, for two reasons:
* The sanity scripts run the red5 code to generate the .flv from the .ser
if needed, and
* We're expecting more people to be using WebRTC media in the future anyways
This makes recordings available up to 2 minutes earlier than they would have
been otherwise.
BigBlueButton can sometimes write events out of order - this particularly
seems to affect the final RecordStatusEvent in a meeting which was ended
while recording was still running. This breaks the recording processing
scripts.
As a workaround, sort the events as they're being written into the events.xml
file. We have the following properties:
* The input data is already mostly sorted
* Items in the wrong position will be no more than a couple spots off from where
they should be
* We should not change the relative order of events with the same timestamp.
The best algorithm to use here is a simple insertion sort. When adding each new
event to the XML structure, it scans backwards through existing events until it
finds the correct position.
For #6035
At some point, BigBlueButton switched from using `"` to `'` in the link tags in
chat messages, which caused the regular expression that was supposed to remove
the `event:` prefix to not match.
I've replaced the error-prone regular expression with an actual HTML parser,
using the "Loofah" HTML transformation/sanitization library based on Nokogiri.
I've removed the code that detected unlinked URLs, since it was broken - and
not needed: current BigBlueButton versions do the link detection in the client.
If someone reprocesses a really old BBB recording with these scripts, URLs in
chat might not be linked in the result. But they wouldn't have been linked in the
client in the original meeting either, so I figure that's ok.
Fixes#6475
In some cases, ffmpeg will be able to read the file, but the video itself
can't be decoded (missing/corrupt stream headers, for example). In this case,
some of the properties on the stream object will be nil.
Make sure that pix_fmt is present in the probed info, since that's a required
property.
