[
http://opencast.jira.com/browse/MH-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32355#comment-32355
]
John King edited comment on MH-8948 at 11/29/12 10:48 PM:
----------------------------------------------------------
I'm going to have to bail on this one as the time zone logic involved is too
tangled for me to fix in a reliable way in a reasonable amount of time.
The proximal cause of this bug is on lines 626 to 628 of oc.scheduler.js in the
method sched.checkForConflictingEvents.
if(sched.timezone == ''){
return false;
}
Note that this logic is only invoked if one is scheduling a group of recordings
not a single recording. This aspect, in and of itself, is a flaw. The bigger
flaw is that the lines mean that the method returns without ever asking the
server if there are any conflicts. That means the group of recordings will be
scheduled even though there may well be conflicts as the flag
sched.conflictingEvents will never be set to true.
The fundamental cause is a misconfigured or, in my case, unconfigured
demo_capture_agent. I had been using the demo_capture_agent without ever
having built the maven "capture" profile on my dev machine. That meant that
the default properties were never set on this agent and, hence, there was no
timezone config info returned from the the below call in handleAgentChange().
Actually, no config info at all is returned in this case from
$.get('/capture-admin/agents/' + agent + '/configuration.xml'.
For any agent that has been setup and configured correctly, this bug would not
occur. Still, I think it would be a good idea for the code to refuse to
schedule anything if the agent timezone is unknown. There is a cryptic comment
on line 430, in the handleAgentChange() method:
delete sched.dublinCore.components.agentTimeZone; //Being empty will end up
defaulting to the server's Timezone.
However, I don't see when this would take effect in downstream logic. The REST
endpoint method for finding conflicts
ScheduleRestService.getConflictinEventsJSON() claims the timezone param is
optional but the method actually returns an error if it is missing. This is
probably why the if(sched.timezone == '') check was put in,
So, I think the correct fix would be to refuse to schedule anything if the
timezone for the agent is unknown. After all, the scheduling admin server could
be in a different timezone from the agent being scheduled. And the browser
being used to set the schedule could even be in a third different timezone.
That would mean using the client side JavaScript Date.getTimezoneOffset()
method, which is used in several places in oc.scheduler.js, would be
unreliable. However that policy might be too draconian, particularly for
developers, such as myself, who use the demo_capture_agent without having
caused it to be configured by building and running the maven capture profile.
The potential side effects of doing this are too difficult for me to patch the
problem reliably without spending a lot more time on it which I don't have
currently. Perhaps another developer more familiar with the timezone
ramifications could take a look at it.
We should document the fact that the demo_capture_agent is not really usable
unless the developer has run the requisite maven capture profile. Note that,
after I did that, I could also see the Agent Tools and Confidence Monitoring
sections on the Matterhorn landing page on my machine. I think we should
recommend that all developers run that profile at least once to setup the
demo_capture_agent correctly.
Note also that it is easy to determine if the demo_capture_agent has been
configured by going to the Capture Agents tab in the Admin UI. If is has been
configured correctly, you will see three "Mock" capabilities; if it has not,
you will see no capabilities. If the capabilities are there, the timezone data
will also be present when GETting the agent configuation.xml.
was (Author: johnk):
I'm going to have to bail on this one as the time zone logic involved is
too tangled for me to fix in a reliable way in a reasonable amount of time.
The proximal cause of this bug is on lines 626 to 628 of oc.scheduler.js in the
method sched.checkForConflictingEvents.
if(sched.timezone == ''){
return false;
}
Note that this logic is only invoked if one is scheduling a group of recordings
not a single recording. This aspect, in and of itself, is a flaw. The bigger
flaw is that the lines mean that the method returns without ever asking the
server if there are any conflicts. That means the group of recordings will be
scheduled even though there may well be conflicts as the flag
sched.conflictingEvents will never be set to true.
The fundamental cause is a misconfigured or, in my case, unconfigured
demo_capture_agent. I had been using the demo_capture_agent without ever
having built the maven "capture" profile on my dev machine. That meant that
the default properties were never set on this agent and, hence, there was no
timezone config info returned from the the below call in handleAgentChange().
Actually, no config info at all is returned in this case from
$.get('/capture-admin/agents/' + agent + '/configuration.xml'.
For any agent that has been setup and configured correctly, this bug would not
occur. Still, I think it would be a good idea for the code to refuse to
schedule anything if the agent timezone is unknown. There is a cryptic comment
on line 430, in the handleAgentChange() method:
delete sched.dublinCore.components.agentTimeZone; //Being empty will end up
defaulting to the server's Timezone.
However, I don't see when this would take effect in downstream logic. The REST
endpoint method for finding conflicts
ScheduleRestService.getConflictinEventsJSON() claims the timezone param is
optional but the method actually returns an error if it is missing. This is
probably why the if(sched.timezone == '') check was put in,
So, I think the correct fix would be to refuse to schedule anything if the
timezone for the agent is unknown. After all, the scheduling admin server could
be in a different timezone from the agent being scheduled. However that
policy might be too draconian, particularly for developers, such as myself, who
use the demo_capture_agent without having caused it to be configured by
building and running the maven capture profile.
The potential side effects of doing this are too difficult for me to patch the
problem reliably without spending a lot more time on it which I don't have
currently. Perhaps another developer more familiar with the timezone
ramifications could take a look at it.
We should document the fact that the demo_capture_agent is not really usable
unless the developer has run the requisite maven capture profile. Note that,
after I did that, I could also see the Agent Tools and Confidence Monitoring
sections on the Matterhorn landing page on my machine. I think we should
recommend that all developers run that profile at least once to setup the
demo_capture_agent correctly.
Note that it is easy to determine if the demo_capture_agent has been configured
by going to the Capture Agents tab in the Admin UI. If is has been configured
correctly, you will see the "Mock" capabilities; if it has not, you will see no
capabilities. If the capabilities are there, the timezone data will also be
present when GETting the agent configuation.xml.
> Scheduling a series recording does not detect a conflict if a recording is
> completely within the time span of an existing recording.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MH-8948
> URL: http://opencast.jira.com/browse/MH-8948
> Project: Matterhorn Project
> Issue Type: Bug
> Components: Administrative Tools
> Affects Versions: 1.3.1
> Reporter: Jonathan Felder
> Assignee: John King
> Fix For: 1.4
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://opencast.jira.com/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
