-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check if we need the capture agent state error #54
Comments
error is meaningful for capture agents that are aware of some issue preventing successful recording, in advance of the recording. As pyca doesn't continuously monitor inputs, it doesn't know if a source is available or not. It could possibly check for low disk space. If free disk space is less than a configured value, it would be appropriate to set status to error (running, but recording unlikely to be successful). |
I think an option for commands that are regularly run would be a good choice. This gives enough flexibility to say "check if capture card device is available", "check if IP camera is pingable", etc. Error state could then be triggered by return code. Implementation is up to the user. |
That would then be more or less a monitor service. Separate from the rest of pyCA, it would just check things and, if necessary, set the capture agent state to error. For that to happen, we would probably need to have a centralized global capture agent state (could easily be just a simple database table) so that the capturer would not just overwrite the error state. Going into that begs the question if we want to pick up other ca states again as well. For example, iirc uploading is never used at the moment since it could easily conflict with capturing and we would end up with a random state. Finally, there is the question if we want to suspend other services (capture?, upload?, schedule?) if an error state is set.It could be useful to not completely fill the disk or not fail uploads if there is no network, but it also means that it might stop the ca from doing certain tasks it still could do· or introducing a complex system with several error states and different handlers which I tend to avoid. |
A new capture agent state “error” is introduced with Opencast 2.4:
https://bitbucket.org/opencast-community/matterhorn/pull-requests/1297
The text was updated successfully, but these errors were encountered: