Sofie Core: A Part of the Sofie TV Studio Automation System
Home Page: https://github.com/nrkno/Sofie-TV-automation/
License: MIT License
This is the Core application of the Sofie TV Automation System.
The Core is a Meteor/Node.JS-based web server that serves the web GUIs as well as handling the business logic for the Sofie system.
The NRK logo is a registered trademark of Norsk rikskringkasting AS. The license does not grant any right to use, in any way, any trademarks, service marks or logos of Norsk rikskringkasting AS.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
This RFC is posted by SuperFly.tv on behalf of the BBC.
Traditionally, the end users have not been able to modify or override any aspects of the rundown data. On behalf of the BBC, SuperFly.tv would like to add the ability for the GUI to modify aspects of the data coming from the NRCS. The initial set of features that we would like to add to Sofie can be described by the following four use cases, but we believe these need to be discussed with vested parties in order to find an optimal implementation strategy.
For this discussion, the term "override" will be used to indicate any data that doesn't have it's origin in the NRCS.
As a user I want to be able to interact with pieces/parts/segments in the GUI and override the following parameters:
Source Layer parameters
Timing parameters:
Start or end (the piece boundaries, editable by grabbing and dragging handles on either end of the piece).
Both start and end at the same time (preferably with a drag handle on the actual pieces).
In/out (for VT's and other types where the piece boundaries might not be identical to the content's in/outpoints). One UX idea here is to be able to set in/out point of a VT by marking them while hover-scrubbing.
Source Layer type (example: from a Camera to an AUX)
Mapping (example: Change Camera 1 to Camera 3). For certain types such as VTs, this will need to include a browser with search and filtering of some sort.
Setting the piece as one of Sofie's infinite types.
Deletion of a piece and possible even a part or segment.
Move piece to another part (either within the same segment, or freely using drag-handle).
The GUI for this will most likely be handles on the pieces in the views, in combination with some sort of Inspector panel that should probably live in the right Side Bar.
Upon push of MOS data from NRCS (e.g. due to the user saving the story) GUI-modified pieces and parts should revert to the NRCS version.
Options per source layer type should be configured via blueprints and be customisable per part / piece.
How does Sofie connect to and display the sources for parameters such as VTs which might be a list of thousands of results?
Should it be possible to multi-select and edit parameters of multiple items at once?
The current model for the Sofie GUI interaction is that you can't really change anything, so how do we avoid that a user inadvertently changes order and placement of pieces just by scrolling or moving the cursor of the GUI?
Could Duplication be a useful operation?
As a user I want to be able to prevent NRCS updates to selected pieces/parts/segments.
Where updates have been made to pieces or parts by manipulating them on the GUI, they should revert to the NRCS version upon a push of MOS data. This is desired behaviour, except sometimes during busy moments where the Sofie operator may have updated elements on the GUI, whilst the journalist is also resaving presenter scripts. We need a way for the operator to 'lock this element from NRCS update' and in doing this for the locked piece, part or segment to hold it's new/updated status, and to not revert to reflect the NRCS page upon a push of MOS data.
Locked items need to have their locked status displayed somehow, and their lock state needs to be editable in the GUI, most likely via the aforementioned Inspector panel.
As a user I want to be able to add a new piece in a Sofie playlist/rundown by dragging it from a MOS-plugin directly into the Sofie GUI.
As the GUI needs to give the user a good understanding of where the new piece will be created -- possibly including giving a preview of the duration of the new piece influences the existing parts.
Just like with the other use cases; how are updates from the NRCS handled when the segment is floated/unfloated?
Should it be possible to create new parts and/or segments, or only to add to an existing part?
What about replacing one piece with the new piece? If that is possible, are there any parameters of the old piece that should be retained, for example duration?
Where would these overrides be stored in Sofie, and how would the data model need to be changed?
What current assumptions in Sofie need to be revisited if we abandon the "NRCS is King" model?
Could overrides be limited to Sofie instances, and could/should we instance the entire playlist? If implemented for only the current and Next part, the implications and development time might be significantly lower.
How are overrides they persisted?
Is write-back to the NRCS something to consider, either short-term or long-term?
Could copy/cut/paste be an alternative to drag-and-drop?
How to handle dragging items where the target is not visible within the current viewport?
Should there be a way for a user to see if any overrides have been applied to a playlist? If so, would that be shown in the Lobby view, too?
How does a user cancel/remove all overrides to go back to a playlist that reflects only the data originating from the NRCS?
We would like to initiate a discussion around these topics in order to be able to assess the amount of work required.
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
On behalf of the BBC, SuperFly.tv would like to replace the current Sofie looping functionality with an implementation that retains the current features while, at the same time, extending the looping feature set.
We're proposing a new Sofie Core feature (not relying on the need to individually implement any new Blueprint logic), available to the users through the Rundown View. This work will replace and extend the existing playlist looping functionality, leaving the existing behaviour unchanged but adding ways of defining a partial rundown loop directly in the Sofie GUI. The plan is to allow the user of the Sofie GUI to set a start and end marker within a playlist in order to automatically loop between these markers, auto-taking the part(s).
We intend to target Sofie Release 51 with a PR for this feature.
A Rundown Playlist can contain a single Start and a single End marker at most, making it possible for only one looping section to exist in a Rundown Playlist.
Setting and clearing the markers via the Sofie GUI will only be enabled in playlists that do not already have looping enabled by the NRCS.
Setting the Start marker after the End marker should not be allowed.
Four kinds of start/end markers are possible to implement: Part, Segment, Rundown, and Playlist.
Playlists that are set to be looping from the NRCS will use the Playlist markers which will mimic the look of the current looping functionality.
Loops set by the user in the Sofie GUI will only use the Part markers which will need to be designed as part of this task.
Segment markers and Rundown markers will only be made available in the backend, but not exposed in any user-facing functionality. Doing so in the future will have to solve the UI/UX issue of how to present this to the end users.
Users should be able to right-click on a Part (but not an Invalid one) and set it as the Start/End of the loop. The context menu should also let the user remove the Start and/or End marker that has already been set on the Part.
Setting the Start and the End marker on the same Part is allowed and will create a one-part loop.
The Loop Mode is triggered when any of the Parts between the Start and End marker is taken (by an Auto Take, or by the user performing a Take manually).
While the Loop Mode is enabled:
Parts will progress automatically, as if each of them had Auto Take enabled from the NRCS. If this is not expected as the default behaviour, a setting may be added.
Parts within the loop that will progress automatically, will have the AUTO indicator shown as a GUI override, but they will not be altered in the database.
When the end of the loop is reached, Sofie sets the first item in the loop as Next and then does an Auto Take.
The Loop Mode can be exited via a dedicated hotkey, an AdLib Action or a context menu item, which continues to play the current part and deletes both the Start and the End markers.
The user should be able to adlib, and the GUI should reflect those adlibs, but all played adlibs should be removed every time the loop starts over.
A dynamic part (inserted by playing an adlib) while currently playing out the End part of the loop will not cause exiting the Loop Mode, and the End will be temporarily moved to that part.
If a Part with a duration of 0 seconds or undefined (set in the NRCS and/or by the Blueprints) is found within the looping section, the default behaviour will match the existing playlist looping functionality, but settings will be made available to treat those parts differently while in the loop (e.g. to indicate them as invalid and skip, or to applying a default duration).
All Parts (but not any Segment headers) outside of the loop are dimmed (black overlay with 20% opacity) but still have all the functionality (e.g. Setting as Next).
Counters in the Top Bar will work normally, and will not be affected by the Loop Mode.
There might be GUI indication showing that the Loop Mode is currently active. TBD later.
Sofie will act "normally" while looping -- no regular Sofie feature will be disabled in this mode.
Infinite piece logic will be respected and the intention is to make it behave normally.
Setting the Start/End markers on different Parts to modify the looping section is allowed, as long as the currently playing Part is contained within the desired section.
Setting a Part outside of the looping section as Next and letting the Auto Take to perform a Take, as well as performing a Take manually, will exit the Loop Mode and delete the Start/End markers.
Parts between the markers might get a visual indicator showing that they are within the loop.
It's up to the user to set the Start/End markers at sensible places. Besides Invalid Parts, Sofie will not evaluate the containing parts and prevent the user from creating a bad situation.
Activating and Deactivating the Rundown Playlist should delete the Part markers, except of going to the On Air Mode from Rehearsal Mode.
Ingest operations altering the order of Segments and Parts so that the Start marker is after the End marker will stop the Loop Mode and delete the markers.
Ingest operations removing the Part(s) containing a Start/End marker will stop the Loop Mode and delete the markers. (This might be revised in the future to allow a reattachment of the marker to a preceding/following Part.)
Ingest operations hiding the Segment in which part(s) containing a Start/End marker exist will stop the Loop Mode.
The Start and End markers may be deleted when source Rundowns of the Parts where they were set are moved between Playlists.
This feature will be a replacement and an extension of the existing Playlist looping. Playlist looping enabled by the NRCS (and/or Blueprints) will use the new Loop Mode implementation, with Start and End markers locked to the Playlist start and end. No changes to the Blueprints will be necessary to continue using Playlist looping. Some additional information may be exposed to blueprint callbacks like executeAction, to make them aware of the state of the loop mode. References to the Start and End Parts (optionally Segments, and Rundowns) will be stored as properties of the Playlist.
This is an RFC - Request for comments (see our
Contribution guidelines ).
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
I am new to the Sofie core system.
I follow the Documentation "https://sofie.gitbook.io/sofie-tv-automation/documentation" But every time I got the following error. Kindly anyone help me.
Where I put the credential for google spreedsheet. I don't find it in UI ?
How can I update the Sofie core.
How can I resolve the following issue
There are no rundowns ingested into Sofie.
Sofie Automation version: 1.17.0
System Status: FAIL / BAD
Status Messages:
check blueprintCompability_kxu7tyKGeaL78K5SL: Integration version: Version mismatch: blueprint.integrationVersion version: "0.24.1" does not satisfy expected version range of core.@sofie-automation/blueprints-integration: ">=1.17.0 <1.18.0-0" (Blueprint has to be updated)
check blueprintCompability_s87zxttpnnecZARhm: Integration version: Version mismatch: blueprint.integrationVersion version: "0.24.1" does not satisfy expected version range of core.@sofie-automation/blueprints-integration: ">=1.17.0 <1.18.0-0" (Blueprint has to be updated)
check blueprintCompability_RWzdovMd8gPJrCXTT: Integration version: Version mismatch: blueprint.integrationVersion version: "0.24.1" does not satisfy expected version range of core.@sofie-automation/blueprints-integration: ">=1.17.0 <1.18.0-0" (Blueprint has to be updated)
device0 (CasparCG device0 192.168.100.2:5250): CasparCG disconnected
Spreadsheet Gateway: Not set up: Credentials missing
This has been opened to share some ideas on how this could be approached
In some deployments of Sofie, it is required to exercise good network security practises. As Sofie is typically an important piece of any studio where it has been deployed, it can be necessary to have it hardened to protect against either malicious or curious users.
Some groundwork was laid to support authentication in #237, but this was never put into production and is likely full of holes by now.
There are a few main areas that will need considering differently.
For these we currently have a basic token based system in place. This will stop or make it hard for a PeripheralDevice to impersonate another.
To make this secure, we should reverse the generation of the token, so that you have to generate a token in core first, and give it to the device before running it for the first time.
Additionally, this would be good to expand to support certificates as well as tokens.
At the same time, It would be good to look at limiting the methods which a device is able to call, so that they only do things which makes sense for them (eg, playout-gateway shouldn't be able to call an ingest method)
Often in the studio or gallery, there will be a screen always showing the prompter or presenter screen.
To support these will need some system of persistent credentials which only allow access to the specific view they are supposed to be showing.
I have not thought about this API.
As this is primarily a system to system api, it should be pretty easy to use an off the shelf approach for api authentication.
I think this area becomes quite complex to handle, as every environment will want something different. Company A might want to use LDAP, and Company B want to use Google. Building support for everything into Sofie will introduce a lot of complexity that could be done elsewhere. I think it is important that we keep the scope small, and support running with either one provider or with user authentication disabled
I propose that we make Sofie be able to talk to a generic OAuth provider. I don't know if OAuth is the best fit, I am open to other suggestions.
If your provider needs something different/special, it could be approached by making a small application to translate that system to oauth.
I don't know how user permissions fit into OAuth, but we will need the provider to report the permissions/access of a user.
This should give a pretty compatible and flexible system, pushing the burden of supporting each provider into their own small projects.
Additionally, with the current architecture, it is recommended to have one Studio per Sofie installation. This means that each installation has its own domain/subdomain, that users must remember and navigate to manually.
It would be ideal if there was a service that Sofie could use to do 'installation switching'. I am envisioning something like the account switching you see with google, with either a dropdown menu showing other installations you have permissions to, or a link which takes you to a page which shows them all.
This switching service will rely on the OAuth provider reporting what servers a user is allowed to access, and will facilitate redirecting the browser to the correct sofie url.
The result of this will be that users can go to https://sofie.example.com, and once authenticated they will be able to choose which Sofie they want to control, and be redirected there. And then easily switch to another installation, without needing to remember anything other than the 'home' url.
Internally, some parts of Sofie are written to ensure good isolation of concerns, and thinking about data ownership. Other areas are less good (eg the settings ui).
Some work will be needed to ensure that user levels are possible and are implemented correctly.
This is solely my own thoughts, with no investigation into practicality of anything. I am open to suggestions on anything, and I am not aware of any plans to implement any of this currently.
This RFC is posted on behalf of CBC/Radio-Canada
In ENPS, it's possible to group multiple stories together to form a segment. The MOS Gateway sends the stories to Sofie with a slug value with the format "SEGMENT NAME; STORY NAME". The Sofie Core then merges the stories together to form the segments and keeps track of the changes coming from ENPS.
In iNews, there is no such thing as a « segment ». We can force individual story slugs to use the format "SEGMENT NAME; STORY NAME", but that means we have to duplicate the segment name in each story. There is no way to assign a single value to multiple stories.
So the two challenges are : first, how can we define a segment coming from iNews and second, how can we name it using a single value in one of the stories of the segment ?
I've noticed that Sofie uses the "SEGMENT NAME;" to name the segment, but the segment grouping is not entirely done using the segment name as an id. For example, two groups of stories separated by an empty story will form two segments in the rundown, even if they use the same segment id.
This is a great behavior, and that means there is already a notion of « separator », an empty story being the separator in that case. So one way of creating a segment would be to use an empty story as a separator, even for stories with no segment name like the one coming in from iNews. One step further would be to define in the blueprint which characters in the slug should identify the story acting as a separator. For example, the separator could be a story with an empty slug "" or with the slug characters "=====================".
As for the naming of the segment, we coud define in the blueprint a pattern to extract the name from the story slugs. For exemple, we could define a start character "[" and an end character "]" so if the string "[SEGMENT 1]" is found in one of the story slugs of the segment, it will be identified and parsed as the segment name "SEGMENT 1".
There are probably a lot of ways to do that, so I'm open to suggestions !
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
This RFC is posted on behalf of the NRK.
At NRK, we are planning to do some refactoring of the Ingest logic to match the Playout change #1035.
We have found one feature whose current implementation will not easily translate across to this new structure. Before putting in the time to rewrite it, we want to be sure there are users of this feature. If there are no users interested in this feature, then we would like to remove it.
If your requirements change in the future, we will welcome an RFC to re-implement the feature
If you are interested in using this feature, please reply to this issue. If we do not hear anything by early January, then we shall mark the feature as deprecated and proceed with removing the functionality soon after.
The 'Preserve contents of playing segment when unsynced' functionality is a contribution received a few year ago. At NRK we have never used this, so any knowledge about how it works it from reading the code and remembering prior discussions (I cannot find the PR for this, and it has survived a couple of large refactorings so git history will be hard to follow). We are also unsure if it works fully in current releases, and we believe the original contributor no longer uses this feature.
This setting changes what happens when the currently playing Segment is removed from the NRCS.
The default Sofie behaviour is that when a Segment is deleted from the NRCS, all the Parts will get removed from Sofie, leaving just the current and next PartInstance. Once the playhead leaves the Segment it will finish being removed.
With this setting enabled, the Segment will instead remain with all its Parts and other contents. I am unsure when these will eventually be removed (perhaps also when the playhead leaves the Segment?)
The proposal is simply to remove this feature, as we are not aware of any users of this feature.
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
As we planned to do many months ago, this repository has now been reformatted using prettier.
This can cause large and painful merge conflicts in pull requests unless handled carefully. This issue aims to outline advice and steps to mitigate any pain that may be felt because of this.
The best process for handling this, is to merge the formatted branch into yours.
Firstly, you need to identify the 2 important commits from the branch you want to merge in. These are the commit just before the merge, and the commit of the merge. To identify these, look in the git history for the merge commit adding the prettier config, and a merge commit soon after which applies this formatting. Github does not make the correct commits very clear, some desktop tools show it a lot better.
For the release21 branch, these are 4864ff5 and 6314c74.
For the master branch, these are d7a403c and 16cf61d.
Note: the remaining steps will assume you are working with master, and will use the commit ids as shown above
checkout your branch to update
Pull in any changes git merge d7a403c6
IMPORTANT: any merge conflicts need to be committed with git commit --no-verify to avoid premature formatting of the changes
If you are on windows, you will need to cherry-pick in 761f927 and d36db2a to get the scripts to work properly
Pull in the format change git merge 16cf61da
Discard any changes, and delete any 'new' files
meteor npm run quickformat
meteor npm run lint -- --fix
Note: Ensure no errors are reported by this. any which are need to be fixed before continuing
Commit all changed files. This should be done as a normal commit again, and will verify the lint is ok
Pull in any newer changes git merge master
This bug report is posted on behalf of the BBC
Package statuses are correct up until the point that the part is set as next at which point they randomly change to Package can't be found on the playout system
Example piece instance:
{
"_id": "mNgEokWWIJwY32qYhGhrTuxroKM__RfnonXJmh65jasFGu_Kmlv798JrW1M__zPuol3jSJ0yHk_",
"isTemporary": false,
"rundownId": "AE3WNBwGLHsbQteS6iZzeMYwPwc_",
"playlistActivationId": "YC8fQTM5cWhyKoZE6",
"partInstanceId": "mNgEokWWIJwY32qYhGhrTuxroKM__RfnonXJmh65jasFGu",
"piece": {
"_id": "Kmlv798JrW1M__zPuol3jSJ0yHk_",
"pieceType": "normal",
"externalId": "someID",
"name": "BLIP/NEWS/PRES///",
"lifespan": "part-only",
"sourceLayerId": "package",
"outputLayerId": "pgm",
"enable": {
"start": 0
},
"prerollDuration": 250,
"abSessions": [
{
"poolName": "clip",
"sessionName": "someID"
}
],
"expectedPackages": [
{
"_id": "BLIP~fNEWS~fPRES~f~f~f.mxf",
"layers": [
"clip_server_A",
"clip_server_B"
],
"type": "media_file",
"version": {},
"contentVersionHash": "",
"content": {
"filePath": "BLIP~fNEWS~fPRES~f~f~f.mxf"
},
"sources": [],
"sideEffect": {}
}
],
"content": {
"path": "",
"fileName": "BLIP~fNEWS~fPRES~f~f~f.mxf",
"sourceDuration": 4640
},
"startRundownId": "AE3WNBwGLHsbQteS6iZzeMYwPwc_",
"startSegmentId": "CG6PpZpderq1ppsF65aNoSEysmc_",
"startPartId": "mNgEokWWIJwY32qYhGhrTuxroKM_",
"invalid": false
}
}Package manager shows that it is correctly processing the package and thumbnail / clip analysis data is generated as expected.
{
_id: "studio0_casparcgContainer_mNgEokWWIJwY32qYhGhrTuxroKM__q4Xv7F9W3GS8opMQN_Kmlv798JrW1M__zPuol3jSJ0yHk__BLIP~fNEWS~fPRES~f~f~f.mxf",
containerId: "casparcgContainer",
deviceId: "packageManagerPackageManager",
modified: 1707918872384,
packageId:
"mNgEokWWIJwY32qYhGhrTuxroKM__q4Xv7F9W3GS8opMQN_Kmlv798JrW1M__zPuol3jSJ0yHk__BLIP~fNEWS~fPRES~f~f~f.mxf",
status: {
status: "ready",
progress: 0,
statusChanged: 1707918871435,
statusReason: {
user: "2 workers available, about to start...",
tech: "Found 2 workers who supports this Expectation",
},
contentVersionHash: "",
priority: 1011,
isPlaceholder: false,
},
studioId: "studio0",
},
{
_id: "studio0___corePackageInfo_mNgEokWWIJwY32qYhGhrTuxroKM__q4Xv7F9W3GS8opMQN_Kmlv798JrW1M__zPuol3jSJ0yHk__BLIP~fNEWS~fPRES~f~f~f.mxf",
containerId: "__corePackageInfo",
deviceId: "packageManagerPackageManager",
modified: 1707918872728,
packageId:
"mNgEokWWIJwY32qYhGhrTuxroKM__q4Xv7F9W3GS8opMQN_Kmlv798JrW1M__zPuol3jSJ0yHk__BLIP~fNEWS~fPRES~f~f~f.mxf",
status: {
status: "ready",
progress: 1,
statusChanged: 1707918871512,
statusReason: {
user: "Scan completed in 0.3s",
tech: "Completed at 1707918871787",
},
contentVersionHash: "1c66ab5fcb4b7d3e10a7596085b790a503258fa9",
priority: 1013,
isPlaceholder: false,
},
studioId: "studio0",
}Packages should retain the correct status
release51
Not a big issue at this time but disconcerting for the users
Just raising awareness at the moment due to lack of time to investigate further
If port 3000 is in use when yarn start is executed, server-core appears to hang indefinitely at some point during its startup process. However, running just the meteor command from the meteor directory reveals the actual "port is in use" error message.
If you set up four levels of font styles, I'll add the styling.
Hey folks,
thanks for sharing this project as OpenSource!!!
I hardly try to install the server-core and fail. I run into different failures like dependencys, configure errors and permission denies warnings.
Is there an option you describe all steps/packages needed starting with a clean installation of ubuntu-server or debian, eg.?
Thanks a lot.
On Windows, it appears that meteor version 2.1 is required. Installing a newer version results in errors about NODE_MODULE_VERSION incompatibilities with native addons. The documentation should mention this and explain how to install a specific version of meteor.
It may be desirable to modify the next part right before a take, for example to change or remove a transition based on some conditional logic.
Whilst this can all be achieved via onTimelineGenerate it means the users do not get any visual feedback on this change.
At first glance I can see two different approaches to this:
IActionExecutionContextI feel like the second one makes more sense, although I'm not sure how that would work if you called a different adLib action that then performs a take, should that then result in the new take action being called or is it safe to assume that part of the logic of the adLib is that it implements the conditional logic?
A draft PR has been opened with some minimal changes to core to implement this #1014
This would be an optional feature so 'should' have no impact on Blueprints which don't implement this method.
Hi,
I'm testing the system through docker-compose and I'm having the following error at the Rundowns page:
check systemTime: Error message: Error: Too few NTP-responses
I saw a NTP_SERVERS env variable but I would need to install manually rather than trough docker-compose, correct ?
Thanks in advance
This RFC is posted by SuperFly.tv on behalf of the BBC.
Improving the accessibility of the Sofie GUI in order to comply with regulatory requirements. Recommendations for changes are outlined in the attached report.
Public Summary of Accessibility Audit report Sofie.pdf
We propose to modify the GUI in order to better cater to accessibility tools. We intend to target Release 51.
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
This Bug report is posted on behalf of NRK
The Diff in the Presenters' Screen and Rundown View is different
The Diff in the Presenters' Screen and Rundown View is the same
Sofie Core 1.50.0
Happened after the first "scramble time" debug function.
1: When using the Acer touchscreen on Windows 10 the shelf resize button does not work.
To use it I need to reach out for the mouse.
This bug report is posted on behalf of SuperFly.tv
When dealing with a sequence of auto-nexting parts, which is usually the case in a looping Playlist, Playout Gateway going online after a period of its downtime causes all the parts that would have been played during that period to be ran through as fast as possible in a sequence of quick auto-nexts. When the parts are short and the downtime was long, it may take a considerable amount of time before Core catches up, which results in an unnecessary load on Core and the Gateway. I have not verified if it also causes flooding of controlled devices with lots of commands, possibly causing visual glitches, but I think it might.
The chain of events looks like this:
Not auto-nexting through all the Parts that would have played during downtime.
When the Playout Gateway goes back online, the Part that is set as Next and gets auto-nexted immediately could be treated as having started now. Alternatively a recovery step could be added, to perform necessary calculations and skip directly to the Part that would be playing if downtime didn't occur.
Release51 of Sofie Core and Playout Gateway
No response
Scenario
On a source layer "Graphic", play a piece "A" of type onSegmentEnd. Some seconds into the first part of the segment, adib a piece "B" with duration X seconds.
What happens
What should happen
The Timeline View should aim to be WYSIWYG and show what the output (correctly) does. Meaning, when B gets inserted, you should see A continue trailing it for the remainder of the current part. Perhaps even with a new/repeated label for A.
Notes
Have not tried how this behaves or looks with a timed non-adlib piece doing B's job here.
This issue has been opened by SuperFly.tv on behalf of EVS Broadcast Equipment (henceforth EVS).
We propose to extend the Sofie API to present an ingest API to allow ingest data to be sent to Sofie from external sources via HTTP rather than DDP.
There is a desire for an external system to be able to "push" data to Sofie via an API. As the HTTP API has been used in other areas of EVS work, it is desirable to also have this external system use the HTTP API.
A draft of the shape of the API has been published and a PR has been opened.
There are a couple of patterns to point out in this draft. The first is the use of ETags and If-None-Match, the second is that the proposed API allows for external Ids to be used interchangeably with Sofie-internal Ids. Both patterns are explored below.
The ETag and If-None-Match HTTP headers have been included as part of this proposal as a way of identifying the version of each ingest item (e.g. Rundown, Segment) when it is pushed to Sofie. Using these headers means that an external system can provide us a version string for some ingest data via the ETag and tell us to only update an existing item if it has a different ETag to the one provided. This means that we have a chance of defending against too many updates being sent by an external system, so long as the external system provides us with a sensible ETag to use as the version of the data (e.g. timestamp that the data was last modified).
Using this method also allows the entire API to be expressed as PUTs while still allowing for "forced" updates - e.g. in the case of re-syncing data. We achieve this by specifying that any update that is not accompanied by an If-None-Match header is always treated as a "create" event rather than an update, meaning that we will overwrite any existing data in this case.
This approach also allows for some performance improvements to be made in some cases, as we will be able to discard an update without performing any costly work within blueprints if we have received data that has the same version string as the object already in the database.
However, to use this version information we will need to store it somewhere which means that this proposed change does mean a change to the data present in the ingest data collections in the form of an optional version: string property. Also of note is the fact that bulk updates (e.g. a PUT for a list of Rundowns) will use If-None-Match to optimize bulk updates, but will not accept an ETag for these updates, so the next update to each individual element within a collection will be treated as a create. This is in-line with the recommended usage of ETag. The effect of this is likely to be that we will be able to optimize the initial ingest of data at the expense of unnecessary updates in the future when script edits are carried out on individual elements of the show.
In the current proposal, external systems can make calls to the Ingest API using either the Id internal to Sofie's database, or using an arbitrary external Id (so long as this Id is sufficiently unique). This allows the external system to interact with Sofie purely through its own Ids, without having to perform lookups to Sofie's API to maintain its own map between Ids. This also means that we can express the entire API as a series of PUTs rather than needing data to be created via a POST initially, which reduces the need for the external system to have an awareness of the data that is currently held within Sofie and by extension reduces the amount of knowledge the external system needs to have about the lifecycle of Sofie.
The cost of this approach should be minimal as it can be implemented using the $or operator in Mongo queries. Also, Ingest operations are generally not so time-sensitive that this lookup will cause excessive delay.
It may be useful to extend this approach to other areas of the API but that is outside the scope of this RFC.
The design of this API is such that the ingest objects contain a generic payload object, the exact shape of which is left to be agreed between the blueprints authors and the authors of the system that is pushing data to Sofie - in much the same way that the existing ingest gateways work. This also follows the pattern established by the Studio and ShowStyle config APIs, so anything that is developed in terms of validation and schema discovery for those methods can be shared with this API.
As part of the Playlist ingest objects, a resyncURL can optionally be provided that will be used by the "Reload data" action within the Rundown UI. This URL will receive a POST with an empty body to prompt an external system to resync data with Sofie, which is described as a request for all data for a Playlist to be re-sent to Sofie without the If-None-Match header present.
This is Johan's secondary test account.
This is a test to test NRK's internal JIRA workflows.
This is an RFC - Request for comments (see our
Contribution guidelines ).
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
Hi,
I have just installed Sofie on a new machine.
I have the Playout Gateway and the MOS Gateway running.
But when I try to run Sofie (using "meteor") I get this error.
client/ui/Prompter/PrompterView.tsx (85, 3): Type '{ mirror: boolean; mirrorv: boolean; restrictMode: string | string[] | undefined; followTake: boo...' is not assignable to type 'PrompterConfig'
Have tried both Master and Develop branch.
As the title says. This issue is present in at least R49 and R50, possibly earlier. It happens in the following scenario:
displayDurationGroup called 'foo'.'foo'.Without displayDurationGroup = 'foo':
With displayDurationGroup = 'foo':
The root question here is: what should happen when Parts in different Segments re-use a displayDurationGroup name? If that behavior is undefined, should Sofie show a warning when it occurs?
This is Johan's secondary test account.
This is a test to test NRK's internal JIRA workflows.
This is an RFC - Request for comments (see our
Contribution guidelines ).
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
This RFC in on the behalf of NRK
For quite some time now, there have been discussions in the NRK Sofie team as well as with other contributors to Sofie on whether we should move away from (parts of) the current technology stack and libraries. We think that now is a good time to initiate those discussions.
We're not really looking at replacing the whole of Sofie with something completely different, but rather look at the individual components that Sofie consists of and evaluate whether they should be replaced with something else.
It is of our opinion that we should move away from the Meteor framework, due to it’s stalling development and it no longer being a good fit for us (tooling is scarce, attaching a debugger works different to regular Node, bundling is slow and Hot Module Reloading support is poor, it makes too many decisions for us and picks libraries that we don’t like).
We invite all Sofie contributors to a series of workshops where we share our thoughts and experiences with various technologies/libraries.
When discussing technologies, we think that it'll be important to consider
I've listed various technology areas/components that we might want to discuss below, feel free to suggest other areas as well and I’ll add them to the list.
Currently, we're using Meteor's built in dev server. We'd like something that offers a better developer experience, most notably hot module replacement.
During the transition, we could eject the GUI from Meteor into another mono-repo package and serve it from there during dev. Then, after bundling for production, let Meteor serve in prod.
Possible options are Vite (seems to be the go-to solution for new projects in 2024), Webpack (established option, lot’s of documentation and tooling), others...?
Currently, we’re using Meteor’s minimongo pseudo-mongodb.
During the transition, we could implement the state management and let minimongo feed it with input data and rewrite the React components independently.
Examples of libraries: mobx, redux, xstate, zustand, others…?
Currently, we’re using React. We’re happy with it.
Examples of libraries: Vue, Angular, preact…
Currently, we’re mainly using Meteor’s DDP-protocol for pub/sub, for our GUI and Gateways. Then there’s also websocket with asyncapi in the Live Status Gateway and REST with openapi for the “stable API”.
Examples of libraries: GraphQL, Feather.js, >>Koa/feathers/raw implementation<<
We don’t have a messaging service at all the moment, our job-workers talk directly with the main process.
Perhaps we should consider moving the job-workers to separate containers and use a backend messaging service?
Examples of technologies: RabbitMQ, Kafka, NATS..
Currently, the backend consists of 4 processes:
Should we change this setup, the number of processes/apps and/or their responsibilities?
Currently we’re relying on threadedClass library, which is sometimes fiddly to use.
Alternatives to using threadedClass?
We’re currently using MongoDB as backend, we’re pretty happy with that.
If you’re interested in joining the discussion, please add a reply to this thread or send me a message at [email protected] . Let me know which areas you are particularly interested in discussing.
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
This bug report is posted on behalf of the BBC
Pieces that are stopped either via stopPiecesOnLayers or stopPieceInstances don't always stop.
They continue to show in the GUI as playing and the timeline objects continue to exist but the database shows them as stopped and thus they cannot be stopped without inserting another piece on the same layer.
{
"_id": "_OPGI0kSC8f98MBOHDY3zSJOXHc__s7G93nXmWcvFivTbe_jv33kKaXSuNunW5AG",
"rundownId": "2kgghfTRYjAlP5g9OHExeWfRfz0_",
"playlistActivationId": "u6hBjd8Gxcbb3tK6F",
"partInstanceId": "_OPGI0kSC8f98MBOHDY3zSJOXHc__s7G93nXmWcvFivTbe",
"piece": {
"pieceType": "normal",
"externalId": "4QKGx03_lgcT8d2RPgoWwncw7Ec__audio",
"enable": {
"start": 39290
},
"name": "OS 2 Audio",
"sourceLayerId": "audio_os_2",
"outputLayerId": "pgm_audio",
"content": {},
"lifespan": "part-only",
"_id": "jv33kKaXSuNunW5AG",
"startPartId": "_OPGI0kSC8f98MBOHDY3zSJOXHc_",
"invalid": false
},
"dynamicallyInserted": 1707217468628,
"reportedStartedPlayback": 1707217468743.5,
"plannedStartedPlayback": 1707217468743.5,
"reportedStoppedPlayback": 1707217468818.5,
"plannedStoppedPlayback": 1707217468818.5
}For example stopping 5 layers using stopPiecesOnLayers results in core reporting the cropping of only 4 layers
{"level":"info","message":"Blueprint action: Cropping PieceInstance \"_OPGI0kSC8f98MBOHDY3zSJOXHc__sYbadkxf8fXn4bLg8_CypP6SRsfsTQeRfnq\" to 1707223033540","source":"studio:studio0"}
{"level":"info","message":"Blueprint action: Cropping PieceInstance \"_OPGI0kSC8f98MBOHDY3zSJOXHc__sYbadkxf8fXn4bLg8_jtRBkGh2DCFDe2STu\" to 1707223033540","source":"studio:studio0"}
{"level":"info","message":"Blueprint action: Cropping PieceInstance \"_OPGI0kSC8f98MBOHDY3zSJOXHc__sYbadkxf8fXn4bLg8_8tSjLkceoeaDq8ZRT\" to 1707223033540","source":"studio:studio0"}
{"level":"info","message":"Blueprint action: Cropping PieceInstance \"_OPGI0kSC8f98MBOHDY3zSJOXHc__sYbadkxf8fXn4bLg8_6xoYTX85PWTMqXpGo\" to 1707223033540","source":"studio:studio0"}Pieces should stop when requested
release51
Not currently an issue as enabling multi-gateway mode 'fixes' this issue
Multi-gateway mode also appears to fix #1118
Just raising awareness
It appears that winston is now a required type in the server-core-integration package as of R50. However, winston (or its types) is not published as a dependency of server-core-integration, so the result is build errors like this:
The issue has been opened by SuperFly.tv on behalf of EVS Broadcast Equipment (henceforth EVS).
As part of a project being developed by EVS there is a desire to execute AdLib Actions with data provided by an external system. This requires the external system to understand the parameters of an AdLib Action and to have some way of modifying these parameters.
This comes in two parts: How to expose data, and how to execute an action with some data from an external system.
Currently, the IBlueprintActionManifest interface has the userDataManifest property which contains an editableFields property. This looks like exactly the property that an external system should be inspecting to know what can and can't be modified and what constitutes valid data.
However, this currently uses the ConfigManifestEntry type, which is an "internal" Sofie type, and would require a 1:1 implementation in an external system. As such, we propose that the editableFields property instead use JSON-schema to represent the editable data. This follows nicely from recent work that has moved device config and mappings to use JSON-schema.
This would allow the Live-status Gateway from the API PR to expose this JSON-schema on AdLib Actions, providing external systems with a description of the "arguments" to an AdLib Action in a more widely-understood format than the ConfigManifestEntry format that Sofie uses.
This work follows naturally from the Stable API discussions and would be a change made after the merging of the open PR (we promise!) to modify the executeAdLib method to optionally take a JSON object as an argument. For AdLib Pieces, providing a JSON object would result in the rejection of the request. For AdLib Actions, the object could be validated against the schema and used to extend/override the userData property passed to StudioJobs.ExecuteAction.
As far as we can tell, the editableFields property is currently only used within the ShelfInspector component, which we believe is deprecated, or in the very least rarely used. We do not fully understand this aspect of Sofie, but if it is still in use then the UI components developed by #837 should be sufficient as drop-in replacements for the existing ConfigManifestEntryComponent used inside of ActionItemRenderer.tsx.
The proposed change to the API would be non-breaking, as it would add an optional property to the body of the request, therefore impact to users of the API would be minimal.
Small Integrator
So running into an issue with a Sofie-core demo setup. I am unable to setup persistent storage directory, regardless of what file path I pick. Just gives me a file does not exists error. This is after the inital server migration.
File directory is set and ability to continue with the guide
Current / Stable
No response
No response
All right, but...
About Google Drive Integration
and Slack webhook...
I uploaded it to Google Drive in the Sofie folder that was set up but nothing happened
I was very excited about the project, but I couldn't evolve at some points, could you create a map between where I am and get to your video demo environment?
If I can run the project I want to contribute in some way to future beginners.
This bug report is posted on behalf of the BBC
Clicking 'Reload NRCS Data' from the Sofie timings bar results in an error message appearing and an error being logged in Core.
Doesn't matter if the rundown is active or inactive in Sofie.
This is with MOS Gateway, unknown if this affects other ingest methods.
{"level":"info","message":"UserAction \"resyncRundownPlaylist\" failed: UserError: {\"rawError\":\"errorClass: Error: Rundown \\\"kneAzthqifY_ezDsJvNosujBCcY_\\\" does not have a peripheralDeviceId [500], Error: Rundown \\\"kneAzthqifY_ezDsJvNosujBCcY_\\\" does not have a peripheralDeviceId [500]\\n at server/api/ingest/lib.ts:120:9\\n at /opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40\\n => awaited here:\\n at Function.Promise.await (/opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:56:12)\\n at server/api/ingest/actions.ts:19:15\\n at /opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40\\n => awaited here:\\n at Function.Promise.await (/opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:56:12)\\n at server/api/rundown.ts:46:14\\n at /opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40\\n => awaited here:\\n at Function.Promise.await (/opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:56:12)\\n at server/api/rundown.ts:42:18\\n at /opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40\\n => awaited here:\\n at Function.Promise.await (/opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:56:12)\\n at server/api/client.ts:242:18\\n at /opt/core/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40\",\"message\":{\"key\":\"An internal error occured!\"},\"key\":0,\"errorCode\":500}"}
A suitable MOS message should be sent (E.G. roReq) to re-request the RO.
release51
Not a significant issue at this time
I am getting this error when I am trying to add sub components to the playout gateway.
ypeError: e is undefined
renderConfigFields https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:129
renderDevices https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:129
collect https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
renderDevices https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:129
renderSubdeviceConfig https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:129
renderConfigFields https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:129
render https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:129
ua https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
la https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
ma https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
Ua https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
Wa https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
Lo https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
So https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
Do https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
Yn https://mvdjs.visualicandy.com/96a6e833540f7ad61232542ef3937eaa12bae6e3.js?meteor_js_resource=true:13
96a6e833540f7ad61232542ef3937eaa12bae6e3.js:129:61818
This RFC is being opened on behalf of TV 2 Norge.
With the adoption of the Live Status Gateway, which allows external systems to get an overview of the state of the Playlist and its contents, a need arose to expose ancillary information about Segments, Parts, Pieces, AdLib Pieces and AdLib Actions beyond what the data model of Sofie covers.
Some documents currently feature a metaData field, which was proposed to be exposed by the Live Status Gateway in #1059, however this property is commonly used to store blueprint-centric information meant to be primarily used by blueprint methods.
AdLib Actions currently only feature the userData property, that the executeAction blueprint method can make use of. In many cases it contains lots of data that would be completely irrelevant for an external system.
Some information can be already exposed using the tags, but being an array of strings, they are not suitable for more advanced use cases where a properly structured object would be much easier to process.
We're proposing the following properties to be allowed to be set by the blueprints on the documents representing Rundowns, Segments, Parts, Pieces, AdLib Pieces and Adlib Actions:
metaData - the public-facing metadata that has some meaning to the outside world, and the external systems will have access to, through means like the Live Status Gateway's topicsblueprintsData - data available only to the blueprints, where the blueprints can store any internal information for their own access later, e.g. to be used in methods like executeAction and getEndStateForPartAdditionally, Adlib Actions would still have the existing userData property, defined as the public-facing, editable data that can be supplied (overridden) by the external systems when executing the action, optionally described by schema (#1005) allowing for GUI auto-generation.
This is an RFC - Request for comments (see our
Contribution guidelines ).
Followed upon by PR: #1077
DBRundownPlaylist has a property called rundownIdsInOrder, that references ids of rundowns that belong to the playlist. When restoring a snapshot, ids are replaced with randomly generated values on rundowns, segments, and so on, however it seems that rundownIdsInOrder array stays unchanged, and references old rundown ids.
This is Johan's secondary test account.
This is a test to test NRK's internal JIRA workflows.
This is an RFC - Request for comments (see our
Contribution guidelines ).
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
This is a PSA about a fairly large upcoming code-change that are planned for Core.
Code formatting
PR: #146
We will start using Prettier as code formatter for the project.
This will result in a lot of code that will be changed (formatted differently), which might affect how easy it is to make PR:s and commits from external repos.
It is therefore recommended that any contributions made by external contributors be presented at the latest 2020-02-10.
The Code formatting will be applied 2020-02-18, so expect to have to rebase any changes done after that.
Note: The formatting have not been applied yet, we're wrapping some things internally and hope to get around to it asap.
i.e. collapsable folders of layers in timeline, these should have a hand cursor on hover to indicate clickable.
This RFC is being opened on behalf of TV 2 Norge.
Buckets are a place where we are planning to store Adlib Actions created by the users, through an external application that uses the HTTP API (#1070). Currently there is a limitation that we would like to lift: Buckets and their AdLibs are global to a Studio, which makes all Adlibs within a Bucket visible next to any Rundown Playlist in that Studio. We would like to implement a solution making it possible for a Bucket Adlib (Piece or Action) to optionally be associated with a specific Rundown Playlist, so that it is available only in the context of that Playlist.
Bucket Adlibs (Pieces and Actions) will have an optional rundownPlaylistId property. The Bucket API will allow for specifying this Id when importing an Adlib.
The Bucket representation in the Rundown View will be able to display those Adlibs and make them visually distinct. The initial idea is to display the global and per-Playlist Adlibs inside a Bucket in two groups separated by a divider saying something along the lines of "Local to this Rundown Playlist". Besides this change we don't initially plan any other changes in the Sofie GUI.
The Live Status Gateway, when in context of a particular Playlist, will filter the Bucket Adlibs to expose only those that have a matching or undefined rundownPlaylistId.
Logic will be added to automatically remove Bucket AdLibs that belong to a Playlist when that Playlist is removed.
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
Hello,
I don't really understand how make a connection to a lawo mixer?
Is server core capable of emberplus connection as this or does it require anything else?
Getting the following console errors running commit 2d73397:
I20180516-10:43:43.420(2)? at Promise.then (server/timesync.ts:116:37)
I20180516-10:43:43.420(2)? at /Users/jonashummelstrand/.meteor/packages/promise/.0.10.2.5g5mso.orhhi++os+web.browser+web.cordova/npm/node_modules/meteor-promise/fiber_pool.js:43:40
I20180516-10:44:03.424(2)? Updating systemTime...```
This bug report is posted on behalf of SuperFly.tv
Sometimes the Playhead in the Timeline View goes past the end of the current Part and even past any subsequent Parts. The current Part refuses to visually extend its width. Refreshing the browser tab doesn't solve the issue. Performing a Take usually solves the issue, however then the previous (problematic) part shows as having 0 width.
This happens randomly on various Parts, without clear steps for reproduction.
1:
2:
3: (After taking out of the problematic Part - 6th in the Intro segment, it displays with no duration and a "flag")
While playing, the current Part should keep extending its width until another Part is taken, and retain its as-played duration until reset
Release50 and Release51 of Sofie Core, with the Demo Blueprints (https://github.com/SuperFlyTV/sofie-demo-blueprints)
No response
The issue has been opened by SuperFly.tv on behalf of EVS Broadcast Equipment.
As part of a project being developed by EVS there is a desire to control Sofie from an external system via a REST API.
Currently, Sofie auto-exposes some API methods, however, this auto-generated API comes with no stability guarantees nor any documentation. Therefore, we propose to develop a stable API that is documented by the OpenAPI standard and does not rely on exposing internal Sofie APIs.
We propose a system whereby an OpenAPI schema is used to generate a REST API using the Koa framework which will call a new RestAPI meteor API. This new meteor API will follow the patterns established for the UserActionsAPI, ServerPlayoutAPI etc. APIs. The RestAPI will then make whatever calls into the existing worker APIs (e.g. the StudioJobs API) that are needed in order to fulfill the API request.
We believe this approach follows established patterns within Sofie, meaning that the code changes should be reasonably self-contained. It also establishes a decoupling point at which internal changes to Sofie's APIs can be handled so as not to modify the REST API, and vice-versa.
As the OpenAPI schema will be the source of truth for the behaviour of the API, a strong contract will be established between Sofie and users of its API. The API route handlers inside Core will be generated automatically from this definition, meaning that a published specification is guaranteed to be reflective of the actual implementation. This definition will also be used to publish an auto-generated typescript client library, so external applications are provided with a library that is guaranteed to work for a given version of the Sofie API. Further, the specification can be used to auto-generate an API section for the Sofie documentation.
Due to much of the API being auto-generated, we believe that the maintenance overhead for this work will be relatively low, as work should only be required either when the API definition changes, or when there is a change internal to Sofie that requires the RestAPI to modify how API requests translate to Sofie internal API calls. We believe that both of these categories of changes should be relatively small.
For the initial implementation, we propose to create an OpenAPI definition that covers the UserActionsAPI, following the current implementation as closely as possible, as well as methods to retrieve some stable-api versions of the RundownPlaylist, Rundown, Segment, Part, Piece, Studio and ShowStyle collections, which will again follow the existing collections structure but with internal-only fields removed - and with querying by Id being the only supported query mode in this initial work.
We will also set up the required build steps to auto-generate the API handler inside Sofie and an auto-generated Typescript client library. The server stub will then be connected to the RestAPI as described, forming a working first version of this stable API.
As part of this work, no existing API methods will be removed or modified in order to preserve compatibility with any existing systems currently consuming these APIs.
There is not an ETA on when this work would be completed as we need just parts of the User Actions API before an upcoming deadline. We may prioritize getting the 50% of this work we need done for that particular deadline, and revisit the rest after said deadline before opening a PR for review, but a draft PR may be opened as a work in progress.
What we are looking for is:
When the viewport is about 1000px wide, the Edit and Delete buttons for each layer become hidden. This is on R49.
Currently, these performance-critical settings default to off. I've personally been running with them off this whole time, because they sound so dangerous to touch. If they are safe and performant, I think they should default to being on.
While we're at it, are there any other performance settings that default to off?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.