Hello!
Thank you for opening this RFC! If you haven’t already, please give our contribution guidelines a read.
We are evaluating this proposal in the team and will soon reach out to you if further discussion is needed.

Thanks for your patience and your detailed RFC!

We are considering this RFC and are in general positive towards the described changes. We ask you to pay particular notice of the following:

• Currently NRK needs to support a workflow where a looping rundown is combined with parts that are not auto taken. These parts, in general, have no duration. So either a way to prevent the described behaviour of doing auto takes on all parts needs to be included, or parts without a duration should not be auto-taken (can also be an optional thing). Either solution is acceptable to NRK.
• We expect there to be issues when parts with a duration of 0 or a very short duration have an auto take. Currently there is a mechanism to prevent doing a take very quickly after another. The implementation needs to take this in to account somehow.

So long as the first point is taken care of, NRK would be happy to accept a pull request containing this functionality (given the PR is of sufficient quality of course)

If you feel there is further need to discuss this or if you would like pointers on the implementation we would be more than happy to host a workshop. In that case, please contact me at mint.de.wit@nrk.no

Hey, I would just like to ask: do you have any plans for what the implementation for this feature is going to look like? One specific thing that might be a pain-point is the implementation of

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.

This sounds like a context-based switch, which means that Parts will be rendered, and treated differently, based on the context of the loop mode (I suppose a property on the playlist object, or something like that?). So far, my experience with that has been relatively poor. Having that be consistent across all of the different views, view-modes and consumers of the data (say, Live Status Gateway) might be a big pain? Might be also quite difficult to implement automated testing to ensure that this behavior isn't broken at any point in any of these consumers?

I'm curious about your thoughts here.

Workshop planned for Friday 13:00 CET.

Thank you, @mint-dewit and @jstarpl, for your time and consideration!

These parts, in general, have no duration. So either a way to prevent the described behaviour of doing auto takes on all parts needs to be included, or parts without a duration should not be auto-taken (can also be an optional thing).

We're thinking of making a Force Auto in a Loop setting in the Studio Setting, that would have three options:

• Disabled (Parts will auto-next only when explicitly set by the NRCS/Blueprints) - default and consistent with the current behavior of the Playlist looping
• Enabled when Part Duration is defined and higher than 0
• Enabled on all Parts, applying the Minimum Display Duration if needed

Exact wording is subject to change.
Minimum Display Duration is currently set through the core-settings.json, however since we already have the Minimum Take Span available in the Studio Settings, perhaps Minimum Display Duration should also be available there or in some other place visible to the admins?

We expect there to be issues when parts with a duration of 0 or a very short duration have an auto take.

Considering that zero-duration parts will not be auto-taken or will have their duration overridden - depending on the settings, this is probably less severe, but I have yet to verify how very short parts (especially multiple in a row) behave. Perhaps we could introduce a specific threshold for auto-nextable part durations?

This sounds like a context-based switch, which means that Parts will be rendered, and treated differently, based on the context of the loop mode [...]

After an internal workshop, we think this would be best solved by a custom publication which would deliver Parts with autoNext, expectedDuration and expectedDurationWithPreroll properties overridden based on the state of the loop and the aforementioned setting(s). This way, consistent data could be delivered to the GUI and potentially other consumers, like the LSG, without them having to implement any extra logic for supporting the override. Current and Next Part Instances will have those overrides applied on the actual documents, but the original values will be preserved and reverted when those parts end up outside of the looping range as a result of user actions or ingest operations. We're aware that extra care is needed to handle the override when those instances are modified by Adlib Actions or syncIngestUpdateToPartInstance.
Whether a Part (Instance) is in the looping section, will have to be computed in the GUI (possibly in the tracker of RundownTimingProvider, where all Parts and PartInstances are already processes in order) to implement presentation-specific features like dimming the parts outside of the loop. This will make it easier to dim the already-played and non-reset Part Instances. A custom Parts publication, however, opens a world of possibilities to how pre-processed Part data could be delivered to the GUI and the LSG, potentially allowing Parts and PartInstances to be combined by the backend in the future.

How do you feel about those solutions?

The described Force Auto in a Loop setting sounds good and should work fine for NRK's use case.

We're thinking of making a Force Auto in a Loop setting in the Studio Setting, that would have three options:

* _Disabled (Parts will auto-next only when explicitly set by the NRCS/Blueprints)_ - default and consistent with the current behavior of the Playlist looping

* _Enabled when Part Duration is defined and higher than 0_

* _Enabled on all Parts, applying the Minimum Display Duration if needed_

My only comment here would be to consider if this should be "applying the Minimum Display Duration", or if it should be "applying a Fallback Duration", with a specific "Fallback Duration" to be set within the Studio. The "Minimum Display Duration" is a quirk of the Timeline view, necessitated by it's characteristics and it doesn't really translate to anything else. I'm unsure if it makes sense to promote something that is essentially a stylistic choice to a system-wide property, or if that should be a separate value, that one can choose to configure to be the same. I appreciate that the use of "Minimum Display Duration" is supposed to allow for visual consistency in the UI when using the timeline view, but for someone using the Segment List view, this will set an arbitrary duration value and will ultimately be inconsistent. What's more, to change this arbitrary value, you'll need to modify a setting that supposedly doesn't affect the Segment List view at all.

Come to think of it, maybe it just makes sense to rename "Minimum Display Duration" to "Fallback Duration", refactor it to be a property of the Studio - like you suggested - and change the power dynamic: no longer would it be a "Minimum Display Duration" value owned by the Timeline, but rather a generic "Fallback Duration", and it would just so happen that the Timeline would use that "Fallback Duration" when it can't render a Part any other way.

There's now a PR for this functionality: #1112

Since there is now a PR for this RFC I am closing this issue.