Update Live Publication in Archive on Capture Agent Change #4316
Conversation
The scheduler service updates this field in the index when the capture agent is changed, but doesn't actually make a snapshot, so this change is overwritten when the next snapshot is made. This is also relevant because this field is used in the live schedule service to generate the URLs for the live tracks.
...for easier understanding.
Before, any changes to the live tracks were only published to search, but not archived. This would result in the External API serving information that's no longer up-to-date.
KatrinIhler
added
bug
ELAN
Did we get bugs in our code, or code in our bugs? |
Technically, you don't need to have a capture agent at all to test this. It's enough if Opencast thinks there's a capture agent. I tested this by first configuring live streaming (add publishLive parameter to a workflow and configure some stuff in the LiveScheduleService.cfg) and then registering three fake capture agents via the /capture-admin rest endpoint. The changes in this PR only affect the live publication in Opencast, so you can just check if it contains the right URLs for its tracks before/after changing the capture agent by asking the asset manager and the search service respectively. No streaming necessary. :) Edit: |
|
@KatrinIhler back in previous versions of Opencast, a change to schedule/event metadata would make an archive snapshot prior to publishing the update. Is this not the case anymore with scheduled events? [EDIT] I'm not sure if I'm right, but before just the mediapackage top level and catalog metadata is updated when a live scheduled event updates. And now the updated live publication element in the archived mediapackage is also updated. |
...hedule-impl/src/main/java/org/opencastproject/liveschedule/impl/LiveScheduleServiceImpl.java
Show resolved
Hide resolved
|
|
||
| // update live publication in archive | ||
| MediaPackage updatedArchivedMp = updateLivePublication(snapshot.getMediaPackage(), liveTracks); | ||
| snapshotVersionCache.put(mpId, assetManager.takeSnapshot(updatedArchivedMp).getVersion()); | ||
| return true; | ||
| } |
There was a problem hiding this comment.
@KatrinIhler So, this new line 364 and 365 is the crux of the patch to update the publication element in the archive when the live publication track changes. Previously, just the mediapackage top level metadata and catalog is updated but not the publication element, and this updates the publication element as well. Does that sound right?
That snapshot is still happening. But the live schedule service also needs to take a snapshot when changing the live publication, and the scheduler service forgot to include some information when taking its snapshot. |
|
I have (finally) gotten a test harness working for this, and am confident that it does what it says on the tin. Happy to merge if @karendolan doesn't have any objections? |
|
Important: This is merged into |
Before I begin, I would like to apologize to whoever will review this, because you're now going to have to deal with this extremely complicated and messy code.
The problem this PR is trying to fix is the following: If someone changes the capture agent for a scheduled live event, the URLs of the live tracks (which usually contain the capture agent name) are updated for search, but not in the archive. This means that the External API still serves the old information, and the live stream cannot be played. Additionally, the URLs in the search service are only up-to-date temporarily, but can revert back to their old state on the next snapshot.
The reasons for this are two-fold:
When changing the capture agent, the scheduler service actually writes the CA id into that metadata field. This information is then put into the Elasticsearch index and handed over to the live schedule service. It is not, however, actually archived. Which means that on the next snapshot (unless we change metadata in the Admin UI, which will send all fields to the back-end on a change, including the location info from the index), that value is overwritten again.
So basically what I did here in both cases is to actually tell the asset manager what the hell is going on. Because I had a lot of problems understanding the code and was concerned that I could unintentionally break something, this also contains some refactoring. This is not supposed to change behavior, but simply make things clearer. I'm also fairly certain that there are more bugs in the affected code and that it could be simplified more, but this was out of scope for this work. I hope to be able to revisit this in the future, but for now, this will hopefully make things a little bit better.
Edit: I would also like to add that I still don't completely understand why the code does the things it does, so please don't ask me.