RFC: Configurable error messages from Package Statuses

[Julusian]

About Me

This RFC is posted on behalf of the BBC.

Use Case

Currently, the error messages from the Package Manager are quite limited and fail to provide useful information in setups where multiple playout servers are tied to a single timeline layer, such as studio screens.

For example, here’s a case where the current error messages fall short:

Proposal

Proposed solution allows error messages from Package Manager to be configurable with the goal to be able to show more helpful error messages to a user.

An example of a error message we would like to see is something like this:
MY_CLIP_NAME cannot be found on Caspar 01

This provides more helpful information as it details both the clip name and playout device, making troubleshooting easier.

Some possible solutions to this are:

Config fields

Add config fields to choose which messages are used. Perhaps to:

• Show clip names
• Include playout device name
• More might be needed, we haven't studied all the messages to figure out what they should become.

I suspect it will become very hard and messy to do this, to support every combination of functionality, especially when other broadcasters want something slightly different.

Blueprint driven

The blueprints could optionally provide something like Record<PackageStatusMessage, string> for any messages they want to override. Which core could utilise these instead of the default messages.

• Sofie can safely throw more arguments into the translations interpolator, if they aren't used they don't get shown.
• These notifications are generated in a publication for a specific bucket/rundown, so could safely use one of the blueprints to achieve this.
• This then keeps the new messages as part of the blueprint code, minimising complexity in the ui and implementation, while still giving flexibility for the messages (while retaining the ability to translate them for multi-language scenarios)

I think this is a better approach, it allows for granular overriding and gives more customisability.

For both solutions, is there a way we can get a 'nice' name for the playout device that is missing the clip?
Maybe this should be using the container name instead? The code knows what container it is missing from.

Process

The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.

• RFC created
• Sofie Team has evaluated the RFC
• A workshop has been planned
• RFC has been discussed in a workshop
• A conclusion has been reached, see comments in thread

[nytamin]

Thank you for submitting this RFC!
(If you haven’t already, please give our contribution guidelines a read.)

The NRK Sofie Team has discussed this internally and we think this could be a good addition. We're also leaning towards the Blueprint driven approach during our initial discussion.

We'd like to propose a short workshop on the topic of the technical implementation plan, just to align our ideas in terms of where and how this would be implemented. We propose to have the workshop Monday, January 20th at 14:00 CET (13:00 GMT).

If anyone else wishes to join the workshop, pleas email me at [email protected]

[nytamin]

Notes from workshop 2025-01-20:

We can assume that the Record<PackageStatusMessage, string> translations from the Blueprints are static, so we would query the Blueprints for translations upon upload/update of the Blueprints only. Then we'd store them on a new property in the Blueprint Mongo Collection. The translations would be of i18n-type type.

In the publication of the media status messages, the message would be matched against the BlueprintTranslatedMessage and replaced if matching.

We all agree that this will be performant and implementable.

[Julusian]

Handled by #1369