Another question for you! Any chance there will be support for recording on the fly? It's my understanding that when you specify isRecording = false the archive gets packed and delivered. Would this be possible to specify from another side of the connection to make sure the session is recorded? Right now, I have one side of the connection that records, while the other just connects and allows collaboration. If the recorder loses connection, I don't get to see an archive created.
The problem we are trying to overcome is coming from the minute possibility of the recording client losing its internet and/or power, and not being able to upload the recording, or send the signal to stop the recording. If it's at all realistic 99-100% on catching archives from the sessions is my goal.
Thanks for listening,
I was able to implement a solution for handling when the browser window closes. This doesn't take care of losing internet connectivity though. Is it possible to set the recording on more than one client to make sure there is a copy sent to the archive manager?
First, thank you for banging on the recording feature as it is in beta and customer feedback is the best way to identify what needs to be fixed/improved as we make a push toward the release. Second, it is in beta
You basically hit a bug in the beta implementation and this is definitely NOT how we intended things to work. To clarify:
1/ A recording should belong to a room session rather than any particular client connection. A client with proper permissions can start and stop a recording, but the fact that things break once the client that started a recording closes his browser is a bug. That room should still be recorded in that case.
2/ As mentioned above, a recording client could be written in such a way that it explicitly stops a recording according to some condition (or button push), but this should NOT be the only way for the recording to be created and published. This is also a bug. Recording should be created and published upon room session end if it hasn't been stopped explicitly by the client app before that point.
Hope I managed to clarify how things are supposed to work.
It's been great to work with you guys on this. Recording and Playback are the main focus with what we're trying to accomplish over here. I'm going to set up a separate application that controls recording that will hopefully be able to be run on a super reliable connection/power supply for now.
In the end the solution may have capabilities that involve both the recording application running on a recording control computer or the client computer if it's necessary. I look forward to future updates to the way you guys implement the collaboration features! Keep me up to date.
I believe I have a working solution that coordinates video calls and records them for playback. It's ready for implementation and testing in a beta production environment, but I would like to make sure that functionality will stay relatively stable in the future. Is there any way I can get a timeframe on when the recording and playback will come to a stable release, or have contact with someone there who may be able to advise of when and how severe updates to the functionality are expected?
Thanks again everyone,
We'd love to be able to tell you exactly when everything will be done, but
unfortunately it isn't realistic. We still have at least one more release to
go to completely finish recording and playback, and because we're in beta,
we may need to make changes that force you to recompile. I can tell you
we're getting pretty close to the end though - the final features (security
and metering) are being worked on as we speak.
hope that helps,
Thanks for the reply Nigel:
By metering do you mean how much it will charge the account for playback? I would be very interested if you have a chart available explaining the current fee structure. If this information is up, where can I find it?