...

• Publicly available renditions: The migration scripts relies on profiles to migrate no-security renditions. This means that renditions must be publicly available through an active profile setup to remain publicly available after the migration. In particular, be aware of the following:

  • Deleted profiles: If a profile has been deleted but renditions created via this profile are still publicly available, the renditions will stop being publicly available.

  • Asset type configurations: If a rendition is only made publicly available by storing it on a LaxSecurity destination via an asset type configuration, the rendition will stop being publicly available.

• Unsupported media format type: The new transcode system supports a limited set of format types. All old media formats that do not have a corresponding format type in the new transcode system can not be automatically migrated to a new format. If a media format is used and has not been migrated, consider if one of the supported format types in the new transcode system can be used instead. Otherwise, reach out to R&D to share your use case.

  • All non-migrated media formats can be identified by running the following SQL query against the database after upgrading:

    View file
    name identify_non_migrated_formats.sql

    .

• Special ImageMagick commands: If an old media format is defined with an ImageMagick command that refers to a local file on the server, renditions of the corresponding migrated format can not be generated with the new transcode system. This can e.g. be the case if a custom profile or a special watermark is used. An example of such an ImageMagick command is: %infile%[0] -profile "D:\my\local\file\path\custom_profile.icc" %outfile%. If a local file is referenced, the corresponding migrated format must be edited manually.

  1. The media formats for which this potentially is an issue can be identified by running the following SQL query against the database after upgrading:

     View file
     name identify_problematic_conversion_commands.sql

     .

• Video thumbnails: If the OOBE configuration layer is not used, please be aware that selecting a custom video thumbnail in MM will not work without setting up an automation that force generates thumbnails when the FrameAccurateThumbnail metafield changes. An example of an automation that does this can be found here: https://github.com/Digizuite/configurations/blob/master/OOBE/5.10.0/automations/oobe_republish_on_frameaccurate_thumbnail_changed.dcl.

PROD environment migration guide

In some cases, new formats might be created and mapped to old media formats without running the migration script in the previous section.

This might e.g. be the case when upgrading a PROD environment, where configuration management is used to create and map formats.

In this case, the renditions need to be migrated from the database table asset_filetable, used by the old transcode system, to the database table Renditions, used by the new transcode system. If this is not done, existing renditions will not be re-used. Renditions will therefore be generated when they are requested the first time.

To migrate the renditions based on existing formats and their mapped media formats, please run the following script: https://github.com/Digizuite/scripts/blob/main/migrate_renditions.sql.

LaxSecurity destinations

In the old transcode system, it was possible to generate renditions and make them available at specific destinations via asset type configurations or profiles. If a destination was configured with LaxSecurity set to true, the renditions stored in this destination would be publicly available.

...