The way the checksum is calculated now is more similar to the other API calls,
specially setConfigXML. It uses the content type 'application/x-www-form-urlencoded'
so the information in the post body doesn't have to be converted from/to
js/string, preventing possible checksum errors in different programming
languages.
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.
It changes less than the internal meeting ID. An application can subscribe
to an external ID and use the hook for several different meetings that will
have the same external ID but different internal IDs.
Will try again a number of times for about 5min and then give up. On giving
up, the hook is removed.
And a few fixes for saving and loading data on redis.
Save hooks and meetingID mappings to redis and get them back when the
application starts.
Still missing a way to remove old data in case the app loses events (e.g.
a hook for a specific meeting might stay on redis forever if the app
lost the meeting_destroyed event).
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...
Hooks can be global, to receive events from all meetings, or can receive
events for a single meeting. Depends on whether the meetingID parameter is
informed or not in the hooks/subscribe API call.
Also improved the log messages a bit.
