** Notice: all internal pipelines have been restricted to 30 minute timeouts, if your CI/CD runs take longer, either use your own runners or read below **
We would remind everyone that the CI/CD services provided by the university Gitlab servers are intended for CI/CD use only (ie. delivering new versions of your software to your production servers, etc).They are not intended for data analysis or -production use, or creating, building and running servers to do heavy data calculation or visualization.
As a general guideline; if your jobs take more than 15 minutes, you might be running something that is better suited for a dedicated system or a virtual server - in this case, please contact the helpdesk for a solution to your needs.
The recorder service is responsible only for recording streams to files. These recordings can be configured, started and stopped through API endpoints or events.
A stream recording service. When a recording is initiated it captures all stream packets to a file on disk. It is not responsible for playback, and instead generates Redis events that inform other services of the existence of a recording.
* select which stream and framesets to record.
* select which channels to include in the recording.
* give a name, description or other information about a recording
* once complete, it must generate an event informing about the new file location (to be consumed by another service).
\ No newline at end of file
* Specify which channels, framesets and frames to record.
* Give a name to the recording, and tags, descriptions etc... all optional initially.
* Create a database entry recording the file and stream association.
* Stop Recording.
* Provides a temporary ID for active recordings, this allows those active recordings to be controlled (ie. stopped or monitored).
# API Endpoints
## POST /v1/recorder
Create a new recording of a stream. Body includes:
* Stream URIs to record, including optional frameset and frame
* Channel listing or wild cards?
* Optional: title, description, tags
* Optional: duration
## GET /v1/recorder
List all active recordings (that the token has permission to see).
* Status
* Start time and time now / duration so far.
* Stream URIs
* Channels
* Owner
## GET /v1/recorder/:id
Retrieve more detail on a specific active recording.
* Status
* Start time and time now / duration so far.
* Stream URIs
* Channels
* Owner
* Statistics: Amount of data recorded
## PUT /v1/recorder/:id
Only allows modification of certain properties:
* Status: allow the stream to be stopped.
* Channels: allow selected channels to be changed.
* Streams: allow streams to be added or removed?
## DELETE /v1/recorder/:id
Cancels a recording, all data will be deleted.
## Questions
A key question is, can the same file be played back in multiple streams at the same time? If yes, then the idea of a collection being the same as an active stream is weakened. However, a collection could be played back under a temporary stream. Therefore the collections list and streams list in the UI are actually different things. The streams service may need modification to account for this.
