On 11-09-26 02:41 PM, Shane Phelan wrote: > > > On Mon, Sep 26, 2011 at 1:39 PM, Greg Logan <[email protected] > <mailto:[email protected]>> wrote: > > On 11-09-26 11:25 AM, Shane Phelan wrote: > > Is there somewhere on the core then that you can see a list of > > recordings for a particular agent? And what the status is? > > Not on a per-agent basis, at least not on the core. On the agent you > can see this information at /state/recordings, but the core does not > keep track of which recording comes from which agent. > > > I'm not sure if there is a problem at this point or not, but it is a > > concern. Is there documentation somewhere of the capture agent > workflow > > and the endpoints it uses? > > This is something that we need to work on. I know as a developer which > endpoints are in use, but there is no documentation that I know of which > lists them explicitly. In terms of the workflow this is somewhat > deliberately vague. The core does not care how the recording is > captured, only that it is. It presents a set of endpoints which any > agent can integrate with, but the actual sequence of actions inside the > CA is left up to the implementation. > > > I understand that the CA can be implemented in different ways because > it's simply communicating to the Core rest endpoints, but the core does > care. For example I scheduled a mock recording for 1-2 minutes from > current date/time. The Core put a warning that the capture agent may > not be recording the video because it hadn't received the > status=capturing message. I know(pretty sure) it happened because the > CA hadn't requested the schedule yet, so hadn't started capturing etc. > but my .02$ is that it would seem that there is a basic( or default > workflow) that needs to be followed and could be documented.
One of the very basic design decisions we made when starting the CA was that it is *never* contacted by the core, specifically because the CA may be inaccessible from the core (private network, for example). The lag you experienced is an unfortunate byproduct of this, and a known issue. We hope to have support for ad-hoc captures in a future release, however we do not have a timeline for this support. G > Anyway...thanks for your help today...I appreciate it. > > -Shane > > > > G > > > Thanks again! > > > > -Shane > > > > On Mon, Sep 26, 2011 at 12:56 PM, Greg Logan <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > On 11-09-26 10:43 AM, Shane Phelan wrote: > > > Thanks Greg... but doesn't that become a resource issue that > every CA > > > continues to send upload_finished to the Core for every > video that it > > > has captured. Is there a mechanism that clears these out > after some > > > amount of time? Also what's the purpose it doesn't appear that > > the Core > > > does anything with the message because the video has already > been > > > ingested an processed. > > > > The agent stops sending the state for a given recording once > one of two > > things happens: > > > > 1) If the agent runs low on disk space it begins removing the > oldest > > ingested lectures, which also removes the state updates. > > 2) If the recording is over a certain age (check > > > > felix/conf/services/org.opencastproject.capture.ConfigurationManager.properties > > for this value) the CA deletes its local cached copy, which > also removes > > the state updates. > > > > We keep the recordings around on the CA so that (worst case) > you have > > some leeway to recover lectures which somehow get lost or > damaged on the > > core. Part of keeping them around, however, is keeping their > state up > > to date. If this is causing issues please file a > bug/community feature > > request. > > > > G > > > > > Thanks again, > > > > > > Shane > > > > > > On Mon, Sep 26, 2011 at 11:54 AM, Greg Logan > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > > > > > > On 11-09-26 08:19 AM, Shane Phelan wrote: > > > > I've done a few test captures with my CA and I'm > curious why it > > > > continues to send the following message over and over > to the > > Core. > > > This > > > > doesn't seem necessary. Is there a part of the > process that is > > > failing > > > > that makes the CA think the Core doesn't know about the > > uploaded file? > > > > > > Those are the normal state updates that the CA sends to the > > core. Your > > > logging level is set to debug which is why you are seeing so > > many of > > > these. You can either turn down the frequency of the > updates (in > > > > > > > felix/conf/services/org.opencastproject.capture.impl.ConfigurationManager.properties) > > > or change the logging level. > > > > > > G > > > > > > > 10:14:06 DEBUG (AgentStateJob:158) - #443 - Sending > > recording 51's > > > > state: upload_finished. > > > > 10:14:06 DEBUG (AgentStateJob:193) - #443 - State push > > > > > org.opencastproject.capture.impl.jobs.AgentStateJob@6ae05134 to > > > > http://10.8.104.89:8080/capture-admin/recordings/51 was > > successful. > > > > 10:14:06 DEBUG (AgentStateJob:158) - #443 - Sending > > recording 25's > > > > state: upload_finished. > > > > 10:14:07 DEBUG (AgentStateJob:193) - #443 - State push > > > > > org.opencastproject.capture.impl.jobs.AgentStateJob@6ae05134 to > > > > http://10.8.104.89:8080/capture-admin/recordings/25 was > > successful. > > > > 10:14:07 DEBUG (AgentStateJob:158) - #443 - Sending > > recording 101's > > > > state: upload_finished. > > > > 10:14:07 DEBUG (AgentStateJob:193) - #443 - State push > > > > > org.opencastproject.capture.impl.jobs.AgentStateJob@6ae05134 to > > > > http://10.8.104.89:8080/capture-admin/recordings/101 was > > successful. > > > > > > > > > > > > > > > > _______________________________________________ > > > > Matterhorn-users mailing list > > > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > > > > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > > > > > > > > _______________________________________________ > > > Matterhorn-users mailing list > > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > > > > > > > > > > > _______________________________________________ > > > Matterhorn-users mailing list > > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > > > > _______________________________________________ > > Matterhorn-users mailing list > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > > > > > > _______________________________________________ > > Matterhorn-users mailing list > > [email protected] > <mailto:[email protected]> > > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > <mailto:[email protected]> > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
