Ooyala Flex 5.1.13 Release Notes 2018-05-14

Purpose

Ooyala Flex 5.1.13 is a maintenance release to fix issues found in production. Aside from fixing a number of issues, we have also made the following changes:

  • Support for MPEG-DASH if “emit single file” has been set in Elemental Server.

What’s New

Support for MPEG-DASH if ‘emit single file’ has been set in Elemental Server

We have added support for MPEG-DASH format. This is used to produce segmented files. Elemental profiles include a setting called “emit single file”. If this is set, then regardless of the format, Elemental will produce a single output file that can be processed by Ooyala Flex.

In previous versions, Elemental transcodes were not able to handle transcoded files for HLS profiles, when multiple streams were specified in an Elemental profile. It would create a child file for the same .m3u8 file, up to the number of streams specified in the Elemental profile. We have now made the code generic, so that it can handle these profiles.

Ability to Add Elemental Profile Pass-through to Ooyala Flex 5.1.x

We have added the ability to manually update the transcode profile, using a script for certain users who are on Ooyala Flex version 5.1.x.

Issues Fixed

Random 500 errors in tabs for UDOs in the Production and Production Classification tabs

Users were receiving UI error messages when navigating to the “Productions” and “Production Classification” tabs for user defined objects.

Resolution: This issue has now been fixed and UI error messages no longer appear under the “Productions” and “Production Classification” tabs for user defined objects.

Performance issues when editing / saving large metadata instances

Users found that if they had very large metadata instances (with over 1500 fields), loading editing, and saving these metadata instances was very slow.

Resolution: We found that a method (compare metadata instance) was taking around 2400 milliseconds. We have made improvements so that it now takes approximately 80 milliseconds instead.

Changing the parent of a user defined object doesn’t work correctly

Some users found that when they tried to move an episode from one season to another using a Groovy script, the episode would no longer be displayed. If it was queried in the database, the parent of that episode had changed, but the root parent still referenced the old root season, and not the new root season.

Resolution: A number of issues were found and resolved. These are as follows:

Issue 1: An issue was found in relation to the addChildObject method. This method was only updating the root parent of the current object and not of all its downward children.

Solution: We have made changes to the code, so that it will set a new root parent for not only the object being added, but also for all the objects in its downward hierarchy.

Issue 2: An issue was found, in which some of the data was being duplicated and some of it was missing. This meant that some of the root parents were incorrect. It was also found that the index was incorrect.

Solution: We analysed the data and created a script which corrects the relationship instance ID, root parent, and index.

Issue 3: It was found that the “Find Matching Orphaned Seasons” Groovy script would start a workflow in order to move each child, but it would attempt to move all children at the same time, instead of moving each one individually.

Solution: In the future we will ensure that the “Unorphan Episode or Season” Groovy script is not executed at same time for each child. At present, we do not have a locking feature in the Groovy script when the asset is not present. This will be added in future releases. As a temporary measure, we will use sleep() in the “Unorphan Episode or Season” Groovy script so there is always a 3 second gap between each run of the “Unorphan Episode or Season” script.

Example: If there are 4 children, the first groovy script (Unorphan Episode or Season) will sleep for 0 seconds, the second will sleep for 3 seconds, the third will sleep for 6 seconds, and the fourth will sleep for 9 seconds before moving each child.

Elemental transcode with HLS profile is showing as “failed” even though it completes on Elemental Server

An Elemental Transcode with a HLS profile was failing in Enterprise. However, when the job was checked on Elemental Server, it was showing as “completed”, and all the generated streams were found in the correct target location.

Resolution: You must add a name modifier in the output file for the MPEG-Dash Transcoding type. However, in the case of a HLS file, this will already be present, so there is no need to add this name modifier in the output file.

Known Issues

Nativ Application Certificates Expired

On the 24th May 2018 the Nativ application certificates will expire. This will inhibit access to the Workflow Designer and Metadata Designer applications. We are continuing to work with our certificate providers to provide a permanent fix and renew the certificates, however, until this is available, any users requiring access to these applications can add the domains for their Ooyala Flex implementation, to the “Exception Site List” in the Java Control Panel.

In order to permanently stop this warning box appearing, you must add the domains for your Ooyala Flex implementation, to the “Exception Site List” in the Java Control Panel, highlighted below: