ASC MHL

ASC MHL has been developed and is maintained by the Motion Imaging Technology Council (MITC) at the American Society of Cinematographers (ASC). The goal was to standardize and retain information about media data management. The complementary information is stored within so-called “ASC MHL manifests” and a “chain file” listing the manifests. Together, they form ASC MHL histories.

The Pomfort blog has a dedicated article on ASC MHL that explains the (technical) concept and idea.

Silverstack 8.4 introduced support for ASC MHL and since version 9.0 it is the default hash manifest. You can still choose your preferred hash manifest type via Silverstack’s settings. ASC MHL allows to create and continue histories of hash manifests for many generations of file backups and offers a lot of features.

1. Offload & backup#

When creating offloads or backups of files without existing ASC MHL history on the source volume (e.g., when offloading camera cards), Silverstack creates a new ASC MHL history on the destination volume. If an ASC MHL history is already available on the source volume, the history may be continued or started from scratch (view the backup activity options).

There are some cases where an existing ASC MHL history cannot be continued (for example, when registering files for the first time and the hash formats of source and destination don’t match). In this case, the fallback behavior is to start a new history.

You need to select the path that contains the ASC MHL history (the directory containing the ascmhl folder) so Silverstack can detect the (nested) history correctly in the workflow configuration window. When Silverstack detects an ASC MHL history on the source volume, you will be informed with an info message and Silverstack automatically compares the source with the ASC MHL history. If Silverstack finds issues like missing files or corrupted histories, you will be informed with a warning providing further details.

2. Sealing volumes#

With Silverstack 9.0, the sealing feature uses ASC MHL instead of Classic MHL. There are dedicated articles explaining the feature and workflow in detail:

Furthermore, the sealing wizard allows you to create flattened ASC MHL manifests as part of the sealing process that can be used to verify data. Since flattened manifests are quite small, they can be sent easily via email to other parties.

Sealed volumes and folders can be verified using MediaVerify.

3. Checksum creation#

It is possible to create hashes for files in-place without offloading them first. You can do this using the checksum creation activity that was introduced with Silverstack 9.0.

4. Ignore patterns#

Via Silverstack’s ASC MHL settings, you can define patterns to ignore/exclude specific files and folders from being processed by ASC MHL. This is useful for system files that have restricted permissions or files that change constantly.

Use this markdown file as cheat sheet to define ignore patterns for ASC MHL:

ASC MHL Ignore Patterns Cheat Sheet

Note: Ignore patterns can only be added to and not removed from ASC MHL histories. This means that once the file is ignored by ASC MHL, it cannot be undone.

5. Frequently asked questions (FAQ)#

I received the error: ASC MHL tool returned exit code verificationFailed. What does that mean?

This error is thrown when the ASC MHL tool detected a mismatch between the hash stored in the ASC MHL history and the newly calculated hash from Silverstack. Click on the associated workflow and within the right sidebar, click on Show State History… and then on Log File… to open the log files. When searching for “hash mismatch”, you will find the file that caused the error.

6. Current limitations#

When registering files with existing ASC MHL history for the first time, the source and destination hash formats must match
Silverstack does not create directory hashes (this can lead to empty folders being detected as new in MediaVerify)
Renaming on offload does not support continuing histories when the renaming needs to be executed for an already existing history

7. Nested ASC MHL histories explained#

A nested ASC MHL history consists of a top-level history which stores references to all child histories in the subdirectories. Nested histories allow you to verify multiple child histories at once and to detect missing subfolders that were previously registered in the history. Here is an example of a nested ASC MHL history:

Pomfort-ASCMHL-NestedHistory

Fig. 1: Nested ASC MHL history

Figure 1 shows an example of such a nested history: The red arrows indicate the manifests referencing the files. The orange arrows show the chain files referencing the manifests. The blue arrows are the references from the top-level history to the latest generations. Since the ascmhl folders in the subdirectories contain two manifests, the history contains two generations.