Adjusting EVENT_MINIMUM_SEPARATION_MILLISECONDS

[itz.feli...@gmail.com]

Hi,

we have an issue with our lecture recording planning this year. Before COVID19, we had a buffer of 60s set in our Stud.IP Opencast Plugin to avoid scheduling conflicts.

This was not a big issue as most lectures were created for the full two hours while they only lasted 90 min.

During the pandemic, rooms were not allowed to be booked for more than the lecture's length. Some lecturers complained about the 60s loss of their presentation so we decreased the buffer time in the plugin to 10s, which is usually enough for our scheduling equipment (ncast and extron boxes) not realizing that Opencast would not allow less than 60s between scheduled events without raising a conflict.

Now, lecturers sometimes booked a 90min slot and sometimes a 2h slot. With the 2h slot, they are now hitting Opencast's conflict detection.

EVENT_MINIMUM_SEPARATION_MILLISECONDS appears to be hardcoded and not adjustable through config files. Is there any reason for it to be hardcoded 60s? Can the buffer time used for conflict detection be changend by an administrator without recompiling Opencast?

Kind regards

Felix

[Greg Logan]

Hi Felix, 

It's an artifact of how fast many hardware CAs can cycle between recordings. The original purpose was to let the reference CA reset between recordings (60s was as fast as we could make it go) and many hardware CAs have been observed to need that kind of interval as well.

That being said, on Opencast's end there's no need for any kind of separation so feel free to patch that out. Or better yet, file a pr to make it adjustable. 

G

--
To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@opencast.org.

[Lars Kiesow]

Hi Felix,
hi Greg,
there is something missing from that explanation. The new scheduler did
not have this check and the new scheduler was introduced long after the
reference capture agent was abandoned.

Greg, you introduced this in 2018 as part of another pull request (#112)
and later declined my patch removing this again.

I don't know of any capture agent having problems with this and no one
could ever name a specific hardware except for the abandoned reference
capture agent. I also don't understand this concept and think it's a
huge usability issue since Opencast claims non-conflicting events have
conflicts with no further explanation.

I'm all for removing this.


Greg, since you make this claim again:

> […] and many hardware CAs have been observed to need that kind of
> interval as well.

…let me ask again, if you now can name a specific device with such a
problem? ;-p


Best regards,
Lars

[Greg Logan]

Hi Lars,

IIRC, the Echo hardware of the day had issues with short turnaround times.  Or something like that - it wasn't *just* the reference CA. That being said, more information can be found at the bottom of https://github.com/opencast/opencast/pull/1370

G