Yes, well, there's no way of doing that directly. You can get all the recordings but you cannot know which agent recorded them, at least not until you process the recording. The capture-admin service has an endpoint to get the recordings by ID, but not by capture agent because the Recording updates do NOT contain the agent name.
I think something like GET http://address/capture-admin/agents/<agent_id>/recordings/<recording_id> would be a good way of organizing it. GET http://address/capture-admin/recordings/<recording_id>/agent doesn't seem like a bad idea either. 2011/9/27 Shane Phelan <[email protected]> > I think this is what you are saying, but yes based on what Greg said it > appears there should be UI on the Core for each CA. It should list the > recordings and their status at a minimum. > > > On Mon, Sep 26, 2011 at 4:43 PM, Judy Stern <[email protected]> wrote: > >> Taking this to the level of the admin UI, there seem to be a number of use >> cases that call for users being able to see what capture agents were >> used/are being used/will be used for what recordings (and vice-versa). >> At this point (in the UI) one can see the capture agents listed for >> recordings in upcoming or capturing phases, but even there we can't yet sort >> the capture agents column or search for specific capture agents. And, of >> course, the Capture Agents tab should provide this information. >> >> Related jira tickets: MH-2580, MH-7992, MH-2673, MH-3511 >> >> Judy >> >> >> >> On Sep 26, 2011, at 10:39 AM, Greg Logan 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. >> > >> > G >> > >> >> Thanks again! >> >> >> >> -Shane >> >> >> >> On Mon, Sep 26, 2011 at 12:56 PM, Greg Logan <[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]>>> 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]>> >> >>>> >> >> 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 >> > >> > >> > _______________________________________________ >> > Matterhorn-users mailing list >> > [email protected] >> > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >> >> Judy Stern >> Educational Technology Services, UC Berkeley >> [email protected] >> >> >> >> _______________________________________________ >> Matterhorn-users mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >> > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
