Profiles
Last updated
Last updated
In contrast to FX, where streams can be executed by a client or server directly for various short-lived workflows (taking into account the stream timeout after 60 seconds), streams within the IO, CO & HK environment typically have a longer runtime and may require assignment to other render nodes with higher priority.
To address this scenario, profiles can be generated to meet all these requirements:
Attach a Metadata Set
Set job priority
Assign a profile/stream to specific group(s)
Hide it from users
Assign the job to dedicated user(s) or render node(s)
Profiles are used to describe connections between workflows, metadata, user groups, and render nodes/users.
They help define who can see and execute a specific profile, what information is sent when a job is carried out, and which render nodes in the pool can handle the job.
In this section, we will provide explanations for all relevant functions and fields related to profile management.
Displays the name assigned to the profile by its creator.
Shows the type of stream used in the selected profile. Clicking on the name opens the stream in the Stream Designer for further customization.
Indicates the name of the Prestream used in the selected profile. Clicking on the name opens the stream in the Stream Designer.
Presents the name of the stream used in the selected profile. Clicking on the name opens the stream in the Stream Designer.
Shows the name of the metadata set used in the selected profile. Clicking on the name switches the view to metadata.
Displays the default priority assigned to the profile.
Initiates a dialog for entering the name of a new group by using the FX - Create_Group trigger. Clicking "Cancel" ends the dialog, and clicking "Save" creates the group. The "Save" option is linked to the Streams trigger.
Enables the user to perform various actions on existing profiles, including deletion, duplication, and editing.
Displays all profiles created in the system.
Displays all profiles created in the system and filters the profiles displayed in the list view when selecting a group.
The profiles will be displayed in alphabetical order based on their profile names whenever they appear in a list or dropdown view.
The only way to modify the listing is by renaming a profile or by adding a prefix (numeric or character-based).
Jobs created by a profile are executed based on their priority. Lower numerical values (e.g., 1) indicate higher priority and are processed before higher values (e.g., 9).
This rule applies to all profiles (within IO, CO, and HK) that have only a "main" stream assigned to any actively connected client.
When a profile includes both a pre-stream and a main stream, an additional scheduling layer is introduced. In this case, pre-streams are always executed before the main stream. This means that if multiple jobs are created simultaneously with priorities ranging, for example, from 1 to 10, all pre-streams will be executed in order of their priority before any main streams are processed.
Example 1: Adding 100 streams to a watch folder triggers a profile that includes both a pre-stream and a main stream, each assigned a priority of 5.
When the watch folder begins processing, another profile is triggered that contains only a main stream with a priority of 1.
The main stream with priority 1 will execute only after all 100 pre-streams (each with a priority of 5) have been completed, after which the 100 watch folder jobs will be processed.
Example 2: Adding 200 streams to a watch folder triggers a profile that includes both a pre-stream and a main stream, each assigned a priority of 5.
When the watch folder begins processing, another profile is triggered that contains both a pre-stream and a main stream with a priority of 1.
The pre-stream with priority 1 will be executed immediately upon being added to the queue; afterward, the pending pre-streams with priority 5 will be processed.
Once all the pre-streams are finished, the main stream with priority 1 will be executed, followed by the 200 watch folder jobs with priority 5.
Disclaimer: Pre-streams are designed to perform quick checks or verifications that typically last only a few milliseconds, or at most a few seconds. If a pre-stream is implemented in a way that takes around 20 seconds, it can significantly stall the job queue.
