C Sources and Destinations Guide

This appendix describes Source and Destination configuration guidelines for each type of DIVArchive supported content server. See the Oracle DIVArchive Supported Environments Guide documentation in the Oracle DIVArchive Core documentation library for detailed and up-to-date lists of supported content servers, formats, and related DIVArchive platforms.

See Object Storage Destinations and EMC ECS (Elastic Cloud Storage) Integration for information on configuring Oracle Cloud Source/Destinations.

The following information is included:

• General Parameters

  • Files Path Root Parameter

  • Root Path Parameter

    • UNIX Style Paths

    • Windows Style Paths

  • Metasource Parameter

  • Connect Options Parameter

    • Quality of Service (qos=)

    • Source/Destination FTP User Log In (-login)

    • Source/Destination CIFS User Log In (-user)

    • Source/Destination Password (-pass)

    • Source/Destination Connection Port (-port)

    • Deleting Source Content after Archiving (-allow_delete_on_source)

    • Archiving and Restoring File Renaming Rules (-arch_renaming, -rest_renaming)

    • Skipping Files During Restore (-rest_ignoring)

    • Archiving Files in a Specific Order (-file_order)

    • Specifying the Transcode Format (-tr_archive_format, -tr_restore_format)

    • Specifying a Transcoder Name (-tr_names)

    • Restoring Metadata (-rest_metadata, -rm)

    • Restricting the Number of Actors to Retry (-num_actors_to_retry)

    • MSS Source/Destination in MXF Mode (-mxf)

    • FTP Socket Window Size (-socket_window_size)

    • FTP Socket Block Size (-socket_block_size)

    • FTP Passive Mode Transfers (-pasv)

    • Restoring in AXF Mode (-axf)

    • Specifying Connection Timeouts (-list_timeout, -transfer_timeout, -control_timeout)

• Avid MSS (Program Stream) Servers

• Avid Airspace Servers

• Avid Transfer Manager DHM Interface

• Avid Transfer Manager DET Interface

• SeaChange BMS and BMC Servers

• SeaChange BML Servers

• SeaChange BMLe and BMLex Servers

• Leitch vR Series Servers

• Leitch Nexio Servers

• Grass Valley Profile Servers

• Grass Valley UIM Gateway

• Grass Valley K2 Servers

• Grass Valley M-Series iVDR Servers

• Sony MAV70 Servers

• Omneon Spectrum MediaDirector Servers (QuickTime)

• Omneon MediaGrid Content Storage System

• Quantel Power Portal Gateway

• Sony Hyper Agent Servers

• Standard FTP and SFTP Servers

• Local Sources

• Disk and CIFS Sources

• Metasources

• Expedat Servers

General Parameters

this section introduces general items that may apply to any, or most, Sources or Destinations including features, configuration attributes, and connection options.

Files Path Root Parameter

The Files Path Root (FPR) parameter is for Archive and Restore requests. This parameter specifies the root folder for data transfers and applies to any type of Source/Destination.

You can enter an absolute or relative path in the Files Path Root field. This parameter is limited to 260 characters.

Each content server section of this appendix specifies the expected format of the Files Path Root and related File Names parameters for Archive requests.

For Partial File Restore requests, the file names on the destination are those specified when archiving. If no Files Path Root is entered, DIVArchive uses the one specified during archiving.

Root Path Parameter

The Root Path is a Source/Destination attribute you can use as a default path for FTP-like Sources/Destinations, or as a disk mount point for disk and local sources. This applies to any type of Source/Destination. The path is appended before any Files Path Root specified in requests, unless the path specified in a request is an absolute path.

This approach provides better Source/Destination abstraction. You specify the server directories used by DIVArchive at the configuration level, not at the request level. They can be changed at any time without requiring a change to DIVArchive clients.

The Root Path value is always an absolute path defined by the operating system. An Omneon Path is the player name and always considered an absolute path.

Absolute path names are supported on both Windows and Linux to a maximum of 4000 characters. Relative path names are limited to 256 characters on Windows systems (only).

If you leave the Root Path field empty, DIVArchive ignores the parameter. However, if you do specify a Root Path its value is combined with the Files Path Root you specified in a request to give the final Source/Destination path. This process is performed according to the following rules:

• Relative paths are added to the absolute path, absolute paths override preceding absolute paths (standard Path Arithmetic).

• If the Root Path and Files Path Root have different operating system types, the second path (Files Path Root) is converted to the operating system type specified by the first path (Root Path) by replacing \ with / (and vice versa). The converted path is then considered the relative path.

• If the Root Path ends with a > character, the Files Path Root is always considered to be a relative path, and the > character is omitted during concatenation.

Table C-1 Root Path Definitions

Source/Destination ROOT_PATH	Object: Original_FPR recorded in database & metadata	Request Type	Files Path Root (FPR)	Resulting rule applied to create actual path for the transfer	Resulting path considered for the transfer	Resulting original Files Path Root (FPR) recorded in database and metadata
Null		Archive	Null	ROOT_PATH+FPR	Null	Null
Null		Archive	Set	ROOT_PATH+FPR	FPR	FPR
Set		Archive	Null	ROOT_PATH+FPR	ROOT_PATH	Null
Set		Archive	Set	ROOT_PATH+FPR	ROOT_PATH+FPR	FPR
Null		Archive with tr_arch format	Null	ROOT_PATH+FPR	Null	Null
Null		Archive with tr_arch format	Set	ROOT_PATH+FPR	FPR	Null
Set		Archive with tr_arch format	Null	ROOT_PATH+FPR	ROOT_PATH	Null
Set		Archive with tr_arch format	Set	ROOT_PATH+FPR	ROOT_PATH+FPR	Null
Null	Null	Restore	Null	(ROOT_PATH+FPR) | Original_FPR	Null
Null	Null	Restore	Set	(ROOT_PATH+FPR) | Original_FPR	FPR
Set	Null	Restore	Null	(ROOT_PATH+FPR) | Original_FPR	ROOT_PATH
Set	Null		Set		ROOT_PATH+FPR
Null	Set		Null		Original FPR
Null	Set		Set		FPR
Set	Set		Null		ROOT_PATH
Set	Set		Set		ROOT_PATH+FPR
	Null	Transcode Archive				Null
	Set	Transcode Archive				Null

UNIX Style Paths

The following table describes UNIX style paths for the Root Path, File Path Root, and the actual path to the files.

Table C-2 UNIX Style Paths

Root Path (Source/Destination)	File Path Root (Request)	Actual Path to Files
/diva/upload	tmp	/diva/upload/tmp
/diva/upload	/tmp	/tmp
/diva/upload		/diva/upload
/diva/upload	C:\tmp	/diva/upload/C:/tmp (!!!)
/diva/upload>	/tmp	/diva/upload/tmp
/diva/upload>	\tmp	/diva/upload/tmp
/diva/upload>		/diva/upload

Windows Style Paths

The following table describes Windows style paths for the Root Path, File Path Root, and the actual path to the files.

Table C-3 Windows Style Paths

Root Path (Source/Destination)	File Path Root (Request)	Actual Path to Files
D:\diva\upload	tmp	D:\diva\upload\tmp
D:\diva\upload	C:\tmp	C:\tmp
D:\diva\upload		D:\diva\upload
D:\diva\upload>	/tmp	D:\diva\upload\tmp
D:\diva\upload>	C:\tmp	D:\diva\upload\tmp
D:\diva\upload>	C:/tmp	D:\diva\upload\C:\tmp
D:\diva\upload>		D:\diva\upload

Metasource Parameter

The Metasource parameter is a specific type of Source/Destination to manage several Sources/Destinations sharing the same online storage as one (or multiple Drop Folder Monitors) with failover and load-balancing features. This applies to any type of Source/Destination. See Metasources for more information on the Metasource Source/Destination types.

Connect Options Parameter

Connect Options are a Source/Destination parameter used to specify the communication protocol with the Source/Destination or to modify the protocol's defaults.

Some options exclusively apply to a specific Source/Destination type, and are documented as part of that specific Source/Destination type later in this appendix. Others options are for general use and are documented in this section.

Some Connect Options (explicitly or implicitly) specified for the Source/Destination may be superseded by those specified in requests. This section also specifies, for each Connect Option, whether it can be superseded at the request level.

Quality of Service (qos=)

This option specifies the transfer mode used when transferring from this specific Source/Destination when the archive initiator sets the QualityOfService parameter in Archive or Restore parameters to DEFAULT.

This parameter applies to any type of Source/Destination, and cannot be superseded by the request option.

If the archive initiator sets the QualityOfService to something other than DEFAULT, DIVArchive ignores the qos= Connect Option.

The format for the parameter is qos=[DIRECT_AND_CACHE|CACHE_AND_DIRECT].

Note:

This option must be the first one in place in the Source/Destination Connect Options field, and must always be specified in lowercase.

The valid values for Quality of Service are as follows:

DIRECT_AND_CACHE

Direct transfers from (or to) a Source/Destination to (or from) DIVArchive are preferred, but cache transfers will occur if processing the request in direct mode is not possible.

CACHE_AND_DIRECT

Cache transfers from (or to) a Source/Destination to (or from) DIVArchive are preferred, but direct transfers will occur if processing the request in cache mode is not possible.

The following table describes sample Quality of Service connections:

Table C-4 Sample Quality of Service Connections

QOS Connect Option	QOS Set by the Archive Initiator	Actual Transfer Mode Applied by the DIVArchive Manager
DIRECT_AND_CACHE	DEFAULT	DIRECT_AND_CACHE
DIRECT_AND_CACHE	DIRECT_ONLY	DIRECT_ONLY
DIRECT_AND_CACHE	CACHE_ONLY	CACHE_ONLY
CACHE_AND_DIRECT	DEFAULT	CACHE_AND_DIRECT
CACHE_AND_DIRECT	DIRECT_ONLY	DIRECT_ONLY
CACHE_AND_DIRECT	CACHE_ONLY	CACHE_ONLY
	DEFAULT	DEFAULT (that is, DIRECT_AND_CACHE)
	DIRECT_ONLY	DIRECT_ONLY
	CACHE_ONLY	CACHE_ONLY

Source/Destination FTP User Log In (-login)

This option is generally used to specify a user name to connect to a Source/Destination when the transfer protocol is FTP or FTP-like, and is in the format -login {user_name}.

This option applies when specified in Source/Destination type description, and can be superseded by the request option.

Possible values applicable to a specific Source/Destination type are detailed in the related section later in this appendix.

Source/Destination Swift (-oracle_storage_class)

This option is generally used to specify the class of storage to connect to a SWIFT Source/Destination and is in the format oracle_storage_class={ARCHIVE|STANDARD}.

Source/Destination CIFS User Log In (-user)

This option is generally used to specify a user name to connect to a CIFS Source/Destination, and is in the format -user {user_name@domain}.

This option applies when specified in Source/Destination type description, and can be superseded by the request option.

Possible values applicable to a specific Source/Destination type are detailed in the related section later in this appendix.

Source/Destination Password (-pass)

This option is generally used in combination with the -login option, and is in the format -pass [password].

This option applies when specified in Source/Destination type description, and can be superseded by the request option.

Possible values applicable to a specific Source/Destination type are detailed in the related section later in this appendix.

Source/Destination Connection Port (-port)

This option is used when a port parameter is required to connect to a Source/Destination, and specifies the port number in the format -port [port_number].

This is an integer value that applies when specified in Source/Destination type description, and can be superseded by the request option.

Possible values applicable to a specific Source/Destination type are detailed in the related section later in this appendix.

Deleting Source Content after Archiving (-allow_delete_on_source)

This parameter specifies if an Archive request can use the Delete on Source QOS option, and is in the format -allow_delete_on_source.

The Archive request optional parameter delete_on_source instructs DIVArchive to delete the original asset on the source after the archive of the object is successfully completed.

If this option is specified in an Archive request and the Source Type is not LOCAL, DISK or CIFS, DIVArchive automatically terminates the request.

This parameter applies to the FTP_STANDARD Source Type. you can change this behavior so that requests will not fail when delete_on_source is specified in an Archive request.

If the -allow_delete_on_source option is specified, and the delete_on_source parameter is specified in an Archive request, DIVArchive will attempt to delete the asset from the source after the archive has been completed successfully.

This option cannot be superseded by the request option.

Archiving and Restoring File Renaming Rules (-arch_renaming, -rest_renaming)

This feature is available for Archive and Restore requests. There are no pre-defined set of values for these options. Option values are based on regular expressions. Possible values for these options are infinite and fully customizable.

Renaming rules are associated with Source/Destination. You configure file renaming during archive or restore using the Configuration Utility. The configuration can be superseded by the request option.

You use these parameters when a workflow implementation requires automatic file renaming during object archiving, when the object is (partially) restored, or when a transcoded object is rearchived or restored.

Rename files at archive time (-arch_renaming) or at restore time (-rest_renaming). The format for these parameters are as follows:

-arch_renaming [renaming_rule]+
-rest_renaming [renaming_rule]+

renaming_rule = [activation_format:expression_patterns:output_format]

The -arch_renaming option enables renaming files during the archive process. You typically use this option for the following example cases:

• You must add a file extension to archived files.

• When associated to a transcoder cache (Local Source/Destination), you can set archive renaming rules to rename the files of a transcoded clip. This is useful when files created by the transcoder do not have the expected names.

The -rest_renaming option enables renaming of files during the restore process. You typically use it when the Source/Destination requires strict naming of files, and the files being transferred do not follow these rules.

This option is available for Restore, Partial File Restore (this is an alternate way to rename partially restored files), and N-Restore. If multiple renaming rules are defined, DIVArchive will process the rule for each Source/Destination independently.

You must specify at least one renaming_rule for the option. All renaming rules are located in the Configuration Utility except the Service Name and Port parameters. DIVArchive goes through each renaming_rule for each file on the list to be transferred starting with the first one:

• The rule is applied if the file name matches this rule's activation_format.

• The condition is satisfied if the beginning of a file name matches the evaluation condition of the first rule.

  For example, a condition such as .*\.track will be satisfied by all of the following file names - audio.track1, audio.track2, video.track.

• As soon as a rule is applied for a given file, other rules from the list are no longer considered.

• If none of the rules can be applied, the file is not renamed.

An activation_format is a regular expression (regexp).

The expression_patterns parse the file name. It is a regular expression, which will include up to nine special symbols to identify different parts of the file name: \1 \2 \3 \4 \5 \6 \7 \8 \9.

The output_format is an expression that qualifies the format of a renamed file, based on atomic items (\1 through \9) previously identified when applying expression_patterns to the original file name. Two additional specific symbols can be used:

• \o indicates the object name

• \c indicates the object category

Note:

Describing how regular expression pattern matching works is beyond the scope of this document. There are many web sites on this subject such as http://www.regular-expressions.info/.

The following examples describe different possible scenarios and their associated outcomes using these parameters.

Example One

To add the .gxf extension to all files archived from GVG Profile (by default, these files do not have an extension). If a file does have an extension, the .gxf extension will not be added. To achieve this you use the following statement:

-arch_renaming <.*\..*:(.*)\.(.*):\1.\2><.*:(.*):\1.gxf>

This statement will process the file names as follows:

Input file Name	Output File Name
Star Wars	Star Wars.gxf
Readme.txt	Readme.txt
Jaws.gxf	Jaws.gxf

Example Two

To remove the .gxf extension (if any) at archive time you use the following statement:

-arch_renaming <.*\.gxf:(.*)\.(.*):\1>

This statement will process the file names as follows:

Input File Name	Output File Name
Star Wars.gxf	Star Wars
Readme.txt	Readme.txt
Jaws.avi	Jaws.avi

Example Three

When Flip Factory transcodes clip FOO to Pinnacle MSS, the resulting files are named FOO.MSS.header, FOO.MSS.ft, FOO.MSS.info, and FOO.MSS. These names are not those expected by Pinnacle MSS Servers, and this option fixes these discrepancies. You use the following statement:

-arch_renaming <.*\.header:(.*):header><.*\.ft:(.*):ft><.*\.info:(.*):info><.*MSS:(.*):std>

This option will process the file names as follows:

Input File Name	Output File Name
FOO.MSS.header	header
FOO.MSS.ft	ft
FOO.MSS.info	info
FOO.MSS	std

To help regular expression development, regular expression exercisers are available online at http://regexone.com/ and http://www.lornajane.net/posts/2011/simple-regular-expressions-by-example.

To use this feature, you must know the basic regular expression syntax. You can find Regular Expression introductory information online at http://www.hathitrust.org/, http://books.google.com/, and http://www.gutenberg.org/.

Skipping Files During Restore (-rest_ignoring)

This option is available for Restore, Partial File Restore, and N-Restore requests. It ignores some files during restore based on one or more regular expression rules. The possibilities offered by regular expressions are versatile and enable many different types of filtering.

Files matching one of the regular expressions are ignored by the Source/Destination. The rule supports Unicode characters to offer maximum flexibility. You use the following statement to ignore files during restore:

-rest_ignoring {<rule>} [<rule>|<rule>|<rule>]

You can continue to add <rules> as necessary in the previous statement.

There are no predefined set of values for these options. Possible values for this option are infinite and fully customizable.

The files being ignored are still read from the disk or tape instance. If the set of rules is designed to ignore all the files of an object, then no file is restored and the request will be complete.

During an N-Restore, if multiple renaming rules are defined, DIVArchive will process the rule for each Source/Destination independently.

Example

A typical use case is restoring a SeaChange clip to a destination that does not support SeaChange special files (private data and video index files). The following statement prevents a Source/Destination from restoring files with .pd or .vix extension:

-rest_ignoring <.*\.pd><.*\.vix>

The results if the previous statement are as follows:

DIVArchive Object	Destination Server
Clipname.pd
Clipname.vix
Clipname	Clipname

Archiving Files in a Specific Order (-file_order)

You use this option archiving or restoring files that are MSS files (Omneon QuickTime files), but the source of archiving is not an AVID (Pinnacle) MSS Server (an Omneon server).

This option is not limited to specific Source/Destination types, but it is only meaningful for LOCAL, DISK, CIFS, and FTP_STANDARD Source/Destinations. This option can be superseded by the request option.

You specify the file sequence during archiving or restoring using the following statement:

-file_order {MSS|OMNEON|DIFWAV|SEACHANGE DIRS_FIRST|FILES_FIRST}

The following list identifies the archive sequence for specific formats:

MSS

The sequence is header, ft, info, and then std.

OMNEON

The sequence is clip.mov, and then essence files (.wav, .aiff, .m2v, .mpeg, .diff, and so on).

DIFWAV

The sequence is clip.dif, and then .wav files.

SEACHANGE

The sequence is clip.pd, clip.vix, and then clip.

DIRS_FIRST

The sequence places directories first and is as follows:

Folder test_1;
Folder test_1\test_2;
File test_1\test_2\1.txt;
File test_1\test_2\_A2.txt;
File test_1\test_2\test.txt;
File test_1\test_2\test1.txt;
File test_1\test_2\test2.txt;
File test_1\1.txt;
File test_1\_A2.txt;
File test_1\test.txt;
File test_1\test1.txt;
File test_1\test2.txt;
File 1.txt;
File _A2.txt;
File test.txt;
File test1.txt;
File test2.txt;

FILES_FIRST

The sequence places files first and is as follows:

File 1.txt;
File _A2.txt;
File test.txt;
File test1.txt;
File test2.txt;
Folder test_1;
File test_1\1.txt;
File test_1\_A2.txt;
File test_1\test.txt;
File test_1\test1.txt;
File test_1\test2.txt;
Folder test_1\test_2;
File test_1\test_2\1.txt;
File test_1\test_2\_A2.txt;
File test_1\test_2\test.txt;
File test_1\test_2\test1.txt;
File test_1\test_2\test2.txt;

This ensures that files are archived in the correct sequence so that they are restored in the correct sequence when restoring them to a real Pinnacle MSS Server (a real Omneon server).

DPX Partial File Restore does not examine the file name or the DPX header information to determine which file is assigned to which frame. The assignment is based purely on the sequence in which the .dpx files appear within the archive. By default this sequence is based on ordering established by the source, and is typically alphanumeric. For example, NTFS DISK Source/Destinations order files and folders are not case-sensitive as a general rule (but not where diacritical marks, such as ', `, ^, and so on are applied). By default, when DIVArchive encounters a subfolder it recursively processes all of the children of that folder (including subfolders) before continuing with other files. If a folder appears in the alphanumeric folder listing, it is archived recursively in the order it appears.

However, this can create some issues. You may want all of the subdirectories of a given directory processed first, followed by the files in the directory. Or, you might want all files processed first, then subdirectories. In DIVArchive 7.0 and later, the Actor allows the archive options -file_order DIRS_FIRST or -file_order FILES_FIRST to address these issues as previously described.

Example

An archive contains SeaChange SAF files. These files must be transcoded, and then restored to a Pinnacle MSS Server. In this case, the LOCAL source used by the transcoding process is defined with the -file_order MSS option (among others).

This ensures the files coming out of the transcoder are archived and restored in the correct sequence. That is, header, ft, info and then std.

Specifying the Transcode Format (-tr_archive_format, -tr_restore_format)

Each factory in a transcoder determines the format of the output file. These options allow you to define the factory and output format.

They apply to any Source/Destination type, and have no fixed list of values. This option cannot be superseded by the request option unless used in a TranscodeArchived request.

These options specify the transcode operation to apply to essence files during archive (-tr_archive_format) or restore (-tr_restore_format).

-tr_archive_format {factory_name}
-tr_restore_format {factory_name}

The {factory_name} is the name of a Flip Factory factory, or the name of a Bitscream output format.

Specifying a Transcoder Name (-tr_names)

You use this option to specify the transcoder to use for transcode operations. It applies to any Source/Destination type and cannot be superseded by the request option, unless used in a TranscodeArchived request.

You must always use either the -tr_archive_format or the -tr_restore_format option with -tr_names. When transcoding is applied, one of the transcoders defined by -tr_names is selected by DIVArchive according to the transcoders defined in the DIVArchive configuration based on the availability, configured queue size, and configured performance of the transcoder.

The format for this option is as follows:

-tr_names {transcoder_name} [transcoder_name]

The {transcoder_name} is the name of a DIVArchive Transcoder defined in the Transcoders frame of the Systems tab of the Configuration Utility.

If this option is not present, DIVArchive will select one of the transcoders defined in the DIVArchive Configuration based on the availability, configured queue size, and configured performance of the transcoder.

Restoring Metadata (-rest_metadata, -rm)

This option specifies that a metadata file must be generated and restored on every Restore request. This option applies to any Source/Destination type. Because video servers may reject the metadata file, this option actually applies mainly to LOCAL, DISK and FTP_STANDARD types.

Either form of the option can be used as follows:

-rest_metadata
-rm

When and object is restored, the object is first restored normally. After the regular restore has completed, a metadata file is generated and restored on the specified destination in the specified (or implicit) FilePathRoot of the related Restore request.

The metadata file format is compliant with the DIVArchive File Set Drop Folder Metadata File specification. The metadata file name is objectname.mdf.

Restricting the Number of Actors to Retry (-num_actors_to_retry)

You use this option to limit the number of Actors that an Archive, Restore, or Partial File Restore request will be retried on. By default, this option is not specified and there is no limit. Therefore, all Actors will be tried in case the request constantly fails.

This option applies to any Source/Destination type and cannot be superseded by the request option.

This option uses the following statement:

-num_actors_to_retry {number}

The {number} is the number of retries to attempt and can include zero.

Example

The option -num_actors_to_retry 3 means that the DIVArchive Manager will perform no more than four operations (total) with different Actors, even if there are more than four Actors configured. That is, the initial request plus three retries for a total of four attempts.

MSS Source/Destination in MXF Mode (-mxf)

This option specifically applies only to MSS Source/Destination types, otherwise DIVArchive ignores it. You use this option to indicate when a MSS Source/Destination is configured to import and export MXF wrapped clips.

There are no additional parameters for this option and you include it in the following format:

-mxf

FTP Socket Window Size (-socket_window_size)

This option specifies the total buffer space per data socket reserved for send and receive. This option applies to some Source/Destination types using FTP protocol, such as FTP_STANDARD, OMNEON, PDR, MSS, and so on.

This parameter has a direct effect on transfer performance. Its value depends on the operating system and is usually set between 2048 and 65536 bytes. When this option is not set DIVArchive uses the default value set at the operating system level. Oracle recommends increasing this value to 32768 or more on fast networks. You must run some performance tests to identify the best setting.

The TCP Window Scale option increases the TCP receive window size above its maximum 65536 bytes value. This option is recommended when dealing with Long-Fat Networks, or LFN.

You use the following statement for this option:

-socket_window_size {number}
-socket_bufsize {number}

The {number} is the buffer size in bytes.

Note:

The -socket_bufsize syntax deprecated but still available. Oracle recommends not using it in DIVArchive releases later than 6.2.2 because it may conflict with the -socket_block_size parameter.

FTP Socket Block Size (-socket_block_size)

This option defines how much data (in kilobytes) the Actor tries to send and receive in a single system call during FTP transfers. For example, if the internal buffer size of the Actor is set to 2 Mb and -socket_block_size is set to 64 KB, 32 system calls are required to write a single buffer to a data socket.

This option applies to some Source/Destination types using FTP, such as FTP_STANDARD, OMNEON, PDR, MSS, and so on.

You use the following statement for this option:

-socket_block_size {number}

The {number} is the buffer size in kilobytes, ranging from 32 to 2048 kilobytes.

FTP Passive Mode Transfers (-pasv)

This option specifies that the FTP data connection must be opened in passive mode (as opposed to active mode) for the associated Source/Destination. This may be necessary if a firewall is between the Actor and the Source/Destination.

This option applies to some Source/Destination types using FTP, such as FTP_STANDARD, OMNEON, PDR, MSS, and so on.

You use one of the following statements for this option (not case-sensitive):

-pasv
-PASV

Restoring in AXF Mode (-axf)

The -axf parameter is optional for Restore requests and instructs DIVArchive to restore the original asset into an AXF File. Instead of purely restoring the content of an object to the destination, DIVArchive restores the content into a new AXF File.

Combined with the -rm or -rmxl parameters, you can use this option to export an object with metadata information and then drop it into a DFM Watch Folder.

This option applies to FTP_STANDARD, SFTP, LOCAL, DISK, and EXPEDAT Source/Destination types.

You use the following statement to restore an asset in AXF mode:

-axf

Specifying Connection Timeouts (-list_timeout, -transfer_timeout, -control_timeout)

These options specify the maximum timeout values allowed for different FTP connection operations, and override the default timeout settings. You can set the timeout value for directory and file listings (-list_timeout), file transfers (-transfer_timeout), and control port connections (-control_timeout).

If an operation exceeds the set timeout value the operation is terminated.

The default value is used if a timeout parameter is not specified, or if the timeout value is set to zero.

You use the following statement for each of these options:

-list_timeout {number}
-transfer_timeout {number}
-control_timeout {number}

The {number} is the maximum allowed timeout in seconds.

The default timeout values for each FTP connect operation are as follows:

Statement	Default Timeout
-list_timeout	120 seconds
-transfer_timeout	180 seconds
-control_timeout	120 second

Avid MSS (Program Stream) Servers

Avid (previously Pinnacle) MSS Video Servers can be installed in one of the following configurations:

Independent Storage

The video server (itself) includes its own fault tolerant disk storage.

Shared Storage

The video servers are connected to a SAN where the fault tolerant disk storage is based.

In both cases, external connectivity is provided by one (or several) Connect+ gateways supporting the FTP protocol over a Gigabit Ethernet Network. A clip on the MSS storage is always comprised of three files as listed below (or four if the optional information file is present). They are always archived and restored in the following sequence:

header

This is the first file and the clip's header.

ft

This is the second file and the frame table.

std

This is the third file and the video and audio essence.

info

When present, this is the fourth file. It is an optional information file.

All files are located in a folder that matches the name of the clip (that is, if the clip name is FOO, the files are located in a folder also named FOO).

Newer MediaStream servers can export and import clips with a MXF wrapper. When configured for MXF, the server generates a single file (std) which is the MXF file. DIVArchive only archives one file (std) in MXF Mode. The file is automatically renamed to {clipname}.mxf. This mode is not supported by independent storage servers.

See Appendix A for Oracle DIVArchive options and licensing information.

MSS with Independent Storage

One record is created for each MSS that DIVArchive must move data to and from.

Table C-5 MSS with Independent Storage Parameters

Attribute	Value	Example
IP Address	MSS IP address	10.80.114.21
Source Type	MSS	MSS
Connect Options for Systems with One Gateway	-login {gw_host_name} -pass .video_fs	-login fcgate1 -pass .video_fs
Connect Options for Systems with Two Gateways	-login {gw1_host_name}[, gw2_host_name] -pass .video_fs	-login fcgate1,fcgate2 -pass .video_fs

In a system with two gateways, fcgate1 and fcgate2, DIVArchive manages failover between the two when a connect option such as -login fcgate1, fcgate2 is specified. If the initial FTP connection fails with fcgate1, it will be retried on fcgate2.

This feature has been deprecated and is now implemented using the METASOURCE Source Type.

MSS with Shared Storage

One record is created for each gateway connected to the storage network that DIVArchive must move data to and from.

Table C-6 MSS with Shared Storage Parameters

Attribute	Value	Example
IP Address	IP Address of the gateway through which DIVArchive accesses the shared storage.	10.80.114.28
Source Type	MSS	MSS
Connect Options	-login video_fs -pass .video_fs	-login video_fs -pass .video_fs

MSS with Shared Storage in MXF Mode

One record is created for each gateway connected to the storage network DIVArchive has to move data to and from.

Table C-7 MSS with Shared Storage in MXF Mode Parameters

Attribute	Value	Example
IP Address	IP Address of the gateway through which DIVArchive accesses the shared storage.	10.80.114.28
Source Type	MSS	MSS
Connect Options	-login video_fs (or -login mxf_fs) -pass .video_fs (or -pass .mxf_fs) -mxf	-login video_fs -pass .video_fs

Using MSS with DIVA_archiveObject

The following table describes typical Source/Destination example parameters.

Table C-8 DIVA_archiveObject Source/Destination Use Example

Parameter	Value	Example
FilesPathRoot	The name of the clip.	CITIZENKANE
FileNames	*	*

Avid Airspace Servers

Avid Airspace (previously known as Pluto) is a video server with independent storage. Each clip deals with a single essence file located on the storage root. Airspace uses standard FTP protocol to transfer files to and from the video server internal storage over a Gigabit Ethernet Network.

One record is created for each video server DIVArchive has to move data to and from.

Table C-9 Avid Airspace Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the video server.	10.80.114.28
Source Type	FTP_STANDARD	FTP_STANDARD
Connect Options	-login {FTP_user_name} -pass {FTP_password} -port {FTP_port_number}	-login ftpuser -pass Pa$$word -port 6530

The following table describes an Avid Airspace Source/Destination use example:

Table C-10 Avid Airspace DIVA_archiveObject Source/Destination Use Example

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	Enter the name of the clip in this field.	TRAFFIC

Avid Transfer Manager DHM Interface

The Avid Transfer Manager is the Avid Unity Outer Gateway, which you can address using two different interfaces. One interface is called the Data Handler Module (DHM) and the other called Dynamically Extensible Transfer (DET). Each interface has a specific purpose.

For this Source Type the DHM interface is used for transfer of video and audio content to and from external devices (for example, an archive system).

See the Oracle DIVArchive Avid Connectivity User's Guide in the Oracle DIVArchive Additional Features documentation library for detailed information.

One record is created for each video server DIVArchive has to move data to and from.

Table C-11 Avid DHM Source/Destination Attributes

Attributes	Value	Example
IP Address	PI address of the Avid Transfer Manager	10.80.114.28
Source Type	AVID_DHM	AVID_DHM
Connect Options	-port {FTP_port_number} -login {FTP_user_name} -pass {FTP_password}	-port 6021 -login diva -pass diva

The Connect Option values indicated in the previous table are as follows:

-port

This is the TM Communicator FTP service port number.

-login

This is the TM Communicator FTP service user log in.

-pass

This is the TM Communicator FTP service user password associated with the log in.

Archive requests are initiated from Avid Edit Stations using Send to Playback. The TM Communicator supports setting custom titles for ingested (restored) clips. If the -title option is specified with a title name in a DIVArchive Restore or Partial File Restore request, this option's value is used as the clip title, otherwise the original clip name is used. The original clip name is stored in the Video ID field of the Avid metadata.

The following rules apply to custom title settings:

• Custom titles can consist of one or more words separated by spaces and (or) tabulation characters.

• Oracle strongly recommends single word titles, and absolutely requires that multiple word titles are enclosed in double quotes to ensure proper processing.

• New line (\x0A) and carriage return (\x0D) characters are not allowed in titles.

• Single quote, ampersand, dash, slash, asterisk, and other special characters are supported.

• Double quote characters must be escaped with a backslash to be included in the title.

• Titles composed of one or more spaces enclosed in double quotes are not considered empty.

The following table describes a Source/Destination use example:

Table C-12 Avid DHM Source/Destination Use Example

Restore Option Values	Ingested Clip Title
-title Clip	Clip
-title "Clip"	Clip
-title "My clip"	My clip
-title "My \"special\" clip"	My "special" clip

Avid Transfer Manager DET Interface

Avid Transfer Manager is the Avid Unity Outer Gateway. It can be addressed through two different interfaces called the Data Handler Module (DHM) and Dynamically Extensible Transfer (DET). Each interface has a specific purpose.

For this source type, the DET interface is used for transfer of Metadata and Media Files to Unity Workgroups (or an archive system, seen as an external workgroup / Unity storage extender).

See the Oracle DIVArchive Avid Connectivity User's Guide in the Oracle DIVArchive Additional Features documentation library for detailed information.

One record is created for each video server DIVArchive has to move data to and from.

Table C-13 Avid DET Source/Destination Attributes

Attributes	Value	Example
IP Address	IP address of the Avid Transfer Manager	10.80.114.28
Source Type	AVID_DET	AVID_DET
Connect Options	-port {FTP_port_number} -login {FTP_user_name} -pass {FTP_password}	-port 6021 -login det -pass diva

The Connect Option values indicated in the previous table are as follows:

-port

This is the TM Communicator FTP service port number.

-login

This is the TM Communicator FTP service user log in.

-pass

This is the TM Communicator FTP service user password associated with the log in.

Archive requests are initiated from Avid Edit Stations using Send to Workgroup.

SeaChange BMS and BMC Servers

A SeaChange BMS (Broadcast Media Server) is a standalone video server equipped with a fast-Ethernet Interface and its own storage.

A SeaChange BMC (Broadcast Media Cluster) is a cluster of video servers providing unified storage based on SeaChange RAID² technology. Each server of the BMC can deliver files stored on RAID² to DIVArchive using the FTP protocol. The file transfer format is SAF (SeaChange Archive Format) only.

Note:

The SeaChange FTP servers do not support directories. All files must be listed under the FTP root directory.

By default, a SeaChange BMC node offers Automatic Load Balancing management for data transfer across all nodes of the cluster.

If you want to use this feature, you must only declare the last node of the BMC in the DIVArchive configuration. In this case, DIVArchive will always connect to the same node of the cluster. This node will transparently redirect transfers to other nodes as required.

This feature can be disabled by using a special IP address setting in the DIVArchive configuration (see the following table). In this case, all nodes of the BMC must be declared in the DIVArchive configuration.

You can also add a Metasource that encompasses all nodes of the cluster to enable load balancing and failover from within DIVArchive.

Table C-14 SeaChange BMS and BMC Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the BMS or BMC node. You can disable the SeaChange Automatic Load Balancing by placing a $ in front of the IP address of all BMC nodes. The syntax for this is $IP_Address.	10.80.114.26 $10.80.114.26
Source Type	SEACHANGE_BMC	SEACHANGE_BMC
DIVAACTOR_SEACHANGECHECKDELAY	Identifies the delay before checking if a video was not deleted by SeaChange just after a restore service. The default value is 1000.	DIVAACTOR_SEACHANGECHECKDELAY=1000

SeaChange uses a flat file system. You must specify the parameters as shown in the following table when archiving a clip.

Table C-15 SeaChange BMS and BMC Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilePathRoot	Leave this field empty
FileNames	Enter the name of the clip in this field.	POKEMON

SeaChange BML Servers

The SeaChange BML (Broadcast Media Library) is a large storage system for SeaChange Archive Format (SAF) files and is based on the RAID² technology of the SeaChange BMC platform.

A SeaChange BMC (Broadcast Media Cluster) is a cluster of video servers providing unified storage based on SeaChange RAID² technology. Each server of the BMC can deliver files stored on RAID² to DIVArchive using the FTP protocol.

DIVArchive uses the FTP protocol to communicate with either a BMS or BMC. You can only overwrite the files when the Actor service is stopped. The file transfer format is SAF (SeaChange Archive Format) only.

Note:

The SeaChange FTP servers do not support directories. All files must be listed under the FTP root directory.

The Automatic Load Balancing feature as described for BMC also exists for BML and operates in a similar fashion.

Table C-16 SeaChange BML Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the BML Node. You can disable the SeaChange Automatic Load Balancing by placing a $ in front of the IP address of all BMC nodes. The syntax for this is $IP_Address.	10.80.114.26 $10.80.114.26
Source Type	SEACHANGE_BML	SEACHANGE_BML
DIVAACTOR_SEACHANGECHECKDELAY	Identifies the delay before checking if a video was not deleted by SeaChange just after a restore service. The default value is 1000.	DIVAACTOR_SEACHANGECHECKDELAY=1000
DIRECTORY_SERVER_ENABLED	Identifies whether the BML directory server is enabled or disabled.	Valid values are 1 (enabled) and 0 (disabled). The default value is 1 (enabled).

SeaChange BML clip storage is flat. You must specify the parameters as follows when archiving a clip:

Table C-17 SeaChange BML Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	Enter the name of the clip in this field.	OFFICESPACE

SeaChange BMLe and BMLex Servers

The SeaChange BMLe is the storage subsystem of the latest SeaChange MediaClient architecture. SeaChange BMLe is superseded by the BMLex series.

Both the BMLe and BMLex servers are based on the BML architecture. However Infiniband is used for the cluster interconnect rather than the earlier IOP interfaces. Each node of the cluster is equipped with four FSI ports to provide high speed transfers to and from the BMLe and BMLex.

DIVArchive uses CIFS or FTP protocols to communicate with BMLe and BMLex.

File transfer format is the native format of the files stored on the BMLe and BMLex. Each asset consists of:

MPEG2 Files

MPEG essence, private data (.pd) and video index (.vix) files.

MXF Files

MXF file (.mxf), private data (.pd) and video index (.vix) if the MXF essence is MPEG2.

When the clip consists of three files (that is, the essence file, .vix, and .pd), the files are always archived and restored by DIVArchive in the following sequence:

.pd

This is the private data file and the first file archived or restored.

.vix

This is the index file and the second file archived or restored.

Essence File

There is no extension on this file and it is the last one archived or restored.

DIVArchive can restore SAF (SeaChange Archive Format) files from the archive to the BMLe or BMLex. When a SAF clip is restored to a BMLe or BMLex, the SAF file is automatically unwrapped by DIVArchive and the three files are restored to BMLe or BMLex (that is, the essence file, .pd file, and .vix file). This Source/Destination can also restore SAF files from an archived SAF Object to BMLe.

This feature is transparent to you because DIVArchive automatically detects SAF and unwraps it in real time. When a SAF clip is restored to the BMLe, the SAF file is unwrapped by DIVArchive and the name of each file is extracted from the SAF file header. The content is restored to BMLe in the separate files previously described.

BMLe and BMLex generated files support SAF releases SAF 0.1, SAF 1.0, and SAF. SAF may contain two consecutive private data files including a 12 byte .pd file, and a 28 byte .pd file. In this case, DIVArchive will only restore the 28 byte file while ignoring the 12 byte file.

You must declare one Source/Destination for each FSI of each node:

Table C-18 SeaChange BMLe and BMLex Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address FSI	10.80.114.26
Source Type	SEACHANGE_BML	SEACHANGE_BML
Connect Options	-ftp or -cifs -login {FTP_user_name} -user {cifs_user_name@domain} -pass {password} -nometadata	-cifs -user [e-mail] -pass Pa$$word
DIVAACTOR_SEACHANGECHECKDELAY	Identifies the delay before checking if a video was not deleted by SeaChange just after a restore service. The default value is 1000.	DIVAACTOR_SEACHANGECHECKDELAY=1000

-ftp or -cifs

One of these two options must be specified. Otherwise, Streaming API protocol is assumed, which is not supported by DIVArchive for BMLe and BMLex. This option cannot be superseded by the request option.

-ftp

FTP protocol is used for data transfer to and from BMLe and BMLex.

-cifs

CIFS protocol is used for data transfer to and from the BMLe and BMLex FSI cards. The implicit CIFS path to BMLe is \\fsi_ip_address\vstrm.

-nometadata

This option prevents DIVArchive from archiving the .vix and .pd files when the clip being transferred includes essence, .vix, and .pd files. This option cannot be superseded by the request option.

You must specify the parameters as follows when archiving a clip:

Table C-19 SeaChange BMLe and BMLex Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	Enter the name of the clip in this field.	HANNITY

Leitch vR Series Servers

The Leitch vR series video server is connected to external storage that is usually shared with other video servers of the same brand. Clips are stored on Leitch storage as flat files, one file per clip, without any folder structure.

To move clips in and out of the shared storage, Leitch provides a dedicated gateway called the Archive Streamer. The Archive Streamer offers standard FTP protocol over a Gigabit Ethernet network.

Note:

The Leitch vR Source Type is depreciated. It was initially created to follow the first Archive Streamer releases that did not correctly report the size of the file to be transferred.

You must create one record for each Archive Streamer DIVArchive must move data to and from.

Table C-20 Leitch vR Series Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of Leitch Archive Streamer	10.80.114.21
Source Type	FTP_STANDARD	FTP_STANDARD
Connect Options	-login {FTP_user_name} -pass {FTP_password} -port {FTP_port}	-login ftpuser -pass Pa$$word -port 6021

You must specify the parameters as follows when archiving a clip:

Table C-21 Leitch vR Series Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	Enter the name of the clip in this field.	FRIENDS

Leitch Nexio Servers

The Leitch Nexio video server is connected to external storage that is usually shared with other video servers of the same brand. Clips are stored on Leitch storage as flat files, one file per clip, without any folder structure.

To move clips in and out of the shared storage is possible directly from the video server using the standard FTP protocol over a Gigabit Ethernet network.

Note:

The Leitch Nexio Source Type is deprecated.

You must create one record for each video server DIVArchive must move data to and from.

Table C-22 Leitch Nexio Series Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of Leitch Nexio video server.	10.80.114.21
Source Type	FTP_STANDARD	FTP_STANDARD
Connect Options	-login {FTP_user_name} -pass {FTP_password} -port {FTP_port}	-login ftpuser -pass Pa$$word -port 6021

You must specify the parameters as follows when archiving a clip:

Table C-23 Leitch Nexio Series Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	Enter the name of the clip in this field.	ENEMIES

Grass Valley Profile Servers

Grass Valley Profile video servers are provided in one of two ways; with independent storage, where the video server includes its own fault tolerant disk storage, or as part of a MAN, where video servers are connected to a SAN where the fault tolerant disk storage resides.

Irrespective of the storage mechanism, the DIVArchive Actor always connects to a specific Profile server. The exchange format is GXF only.

Profile Storage consists of one master disk (for example, EXT: or INT1:), and one level of folders where one clip is seen as one file. One folder called default always exists.

The network infrastructure between GVG Profiles and DIVArchive Actors is an IP/FC network.

You must create one record for each video server DIVArchive must move data to and from.

Table C-24 Grass Valley Profile Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the video server.	10.80.114.21
Source Type	PDR	PDR
Name	Logical name for the video server.	GVG-Profile-1

The Actor configuration parameters are located in the Actor frame of the DIVArchive Configuration Utility. The two parameters in the following table directly influence transfer performance. Oracle recommends trying several value combinations on the target platform.

In addition to these two parameters, the MTU size setting for the HBA used for IP/FC traffic to the Profile servers may also have an influence on transfer performance.

Grass Valley does not provide any recommendation for MTU size. However, Oracle recommends setting the MTU size on the Actor HBA to the same value as the MTU size of the Profile HBA. This is only a recommended setting and not an absolute rule.

Table C-25 Grass Valley Profile Actor Attributes

Attribute	Description	Recommended Values
DIVAACTOR_PROFILEREADINGBS	The FTP block size (in bytes) used for transfers on Profile video servers in reading.	1500 16374 32768 (default)
DIVAACTOR_PROFILEWRITINGBS	FTP block size (in bytes) used for transfers on profile video servers in writing.	16374 32768 (default)

You must specify the parameters as described in the following table when archiving a clip:

Table C-26 Grass Valley Profile Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	/explodedFile/disk:/folder	/explodedFile/INT1:/default
FileNames	Enter the name of the clip in this field.	MyClip

Grass Valley UIM Gateway

UIM is a gateway to standalone or MAN Grass Valley Profile servers. It provides TCP/IP over Gigabit Ethernet connections to external systems (such as DIVArchive). For legacy purposes, the connection can also be IP/FC for regular profiles.

UIM also provides real-time format conversion (to MXF). The UIM exchange format is GXF (by default), or alternately MXF.

You must create one record for each UIM DIVArchive has to move data to and from.

Table C-27 Grass Valley UIM Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address for the UIM.	10.80.114.21
Source Type	PDR	PDR
Connect Options	-login {movie|mxfmovie} -format {?D10AES3} -extension {file_extension}	-login mxfmovie -format ?D10AES3 -extension .mxf

-login

Specifies the FTP user for logging onto the UIM to achieve transfers in the desired format. The two available logins are movie (for GXF exchange format), and mxfmovie (for MXF exchange format). The movie user is assumed if -login is not specified.

-format

The UIM supported options for some file formats. This depends on -login option. The only available option is ?D10AES3. The ?D10AES3 option is an e-VTR compliant file format used with the -login mxfmovie option. If this option is not specified, MXF files will be processed in Grass Valley OP1a format. This option is not specified by default.

This option can be superseded by the request option.

-extension

This option adds the specified extension to the original clip name in the archive. For example, if the original clip is clip1 and the -extension .mxf option is specified, then the archived file will be clip1.mxf.

You must suppress the specified extension before restoring to the destination if it already exists. For example, if the archived file is clip1.mxf and -extension .mxf option is specified, the restored file on the destination will be clip1.

This option is deprecated and replaced by the -arch_renaming and the-rest_renaming options. This option can be superseded by the request option.

UIM are gateways to the Profile server. You use this the same way for UIM and Profile servers regardless of the transfer format (GXF or MXF).

Table C-28 Grass Valley UIM Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	/explodedFile/disk:/folder	/explodedFile/INT1:/default
FileNames	Enter the name of the clip in this field.	MyClip

Grass Valley K2 Servers

From DIVArchive's standpoint, K2 servers are similar to Profiles and UIM combined. K2 servers offer Gigabit Ethernet connections to external systems, and the exchange format is GXF (default), and alternately MXF.

You must create one record for each K2 server DIVArchive must move data to and from.

Table C-29 Grass Valley K2 Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the K2 server.	10.80.114.21
Source Type	PDR	PDR
Connect Options	-k2 -login {movie|mxfmovie} -format {?D10AES3} -extension {file_extension}	-k2 -login mxfmovie -format ?D10AES3 -extension .mxf

-k2

This specifies the interface with the K2 servers. When this option is set, DIVArchive will retrieve the size of the file to be transferred before the actual archive transfer (K2 FTP does support the SIZE command). Correct transfer progress is reported by DIVArchive.

When this option is not set, DIVArchive will assume that servers are Profile, and will not retrieve the file size before archive transfers. Progress will then remain at 0% before suddenly jumping to 100% when the transfer is complete.

This option has no impact on transferred content, and can be superseded by the request option.

-login

This option specifies the FTP user for logging onto the K2 Server to achieve transfers in the desired format. The two available logins are movie (for GXF exchange format), and mxfmovie (for MXF exchange format). The movie user is assumed if -login is not specified.

-format

The K2 supported options for some file formats. This depends on -login option. The only available option is ?D10AES3. The ?D10AES3 option is an e-VTR compliant file format used with the -login mxfmovie option. If this option is not specified, MXF files will be processed in Grass Valley OP1a format. This option is not specified by default.

This option can be superseded by the request option.

-extension

This option adds the specified extension to the original clip name in the archive. For example, if the original clip is clip1 and the -extension .mxf option is specified, then the archived file will be clip1.mxf.

You must suppress the specified extension before restoring to the destination if it already exists. For example, if the archived file is clip1.mxf and -extension .mxf option is specified, the restored file on the destination will be clip1.

This option is deprecated and replaced by the -arch_renaming and the-rest_renaming options. This option can be superseded by the request option.

You use this the same way for K2 and Profile servers regardless of the transfer format (GXF or MXF).

Table C-30 Grass Valley K2 Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	/explodedFile/disk:/folder	/explodedFile/INT1:/default
FileNames	Enter the name of the clip in this field.	MyClip

Grass Valley M-Series iVDR Servers

Grass Valley iVDR is an analog and digital VTR that includes a Gigabit connection for material exchange of GXF files. The iVDR exchange protocol is similar to the exchange protocol for Profile servers.

you must create one record for each video server DIVArchive must move data to and from.

Table C-31 Grass Valley M-Series iVDR Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the iVDR.	10.80.114.21
Source Type	PDR	PDR
Name	Logical name for the iVDR.	GVG-iVDR

You must specify the parameters as follows when archiving a clip:

Table C-32 Grass Valley M-Series iVDR Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	/explodedFile/disk:/folder	/explodedFile/INT1:/default
FileNames	Enter the name of the clip in this field.	MyClip

Sony MAV70 Servers

The Sony MAV70 video server has its own independent storage. MAV70 storage organization is flat and all files reside in the storage root. A Linux computer in front of each MAV70 provides a standard FTP connection for moving data to and from the video server over a Gigabit Ethernet Network.

You must create one record for each MAV70 server DIVArchive must move data to and from.

Table C-33 Sony MAV70 Source/Destination Attributes

Attributes	Value	Example
IP Address	IP address of the MAV70 server.	10.80.114.21
Source Type	FTP_STANDARD	FTP_STANDARD
Connect Options	-login {user_name} -pass {password}	-login wing -pass mpegworld

You must specify the parameters as follows when archiving a clip:

Table C-34 Sony MAV70 Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	Enter the name of the clip in this field.	MyClipName

Omneon Spectrum MediaDirector Servers (QuickTime)

The Omneon MediaDirector is the heart of the Omneon Spectrum architecture. It is connected to MediaPorts or MultiPorts which handle isochronous ingest and playback, and to external storage that is usually shared with other Omneon MediaDirectors.

You can use either MediaStore or MediaGrid for external storage. This section describes connecting MediaDirector to MediaStore storage for MediaGrid support in DIVArchive.

Note:

MediaGrid is not supported in the Linux environment.

DIVArchive interfaces with an Omneon MediaDirector to move clips in and out of the shared storage, using standard FTP protocol, over a Gigabit Ethernet Network.

When Omneon Spectrum Servers are configured to ingest material in QuickTime format, essence files are stored in a specific folder structure. The DIVArchive Actors use unique FTP site commands for smart and transparent access to essence files (in particular, the automatic discovery of a folders structure and collision-avoidance at restore time).

You must create one record for each MediaDirector DIVArchive must move data to and from.

Table C-35 Omneon Spectrum MediaDirector Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of Omneon Director.	10.80.114.21
Source Type	OMNEON	OMNEON
Root Path	Either leave this field empty or enter an absolute clip directory.	/default/clip.dir
Connect Options	-streaming_mode -sm -tempdir_mode	-streaming_mode -sm -tempdir_mode

-streaming_mode or -sm

This option is QuickTime specific and has no effect on the MXF content. If this option is set, DIVArchive will restore the QuickTime reference file in the following sequence:

1. Audio Tracks

2. QuickTime File

3. Video track

The restore workflow is specific when this option is set. DIVArchive uses the temporary folder to cache the QuickTime file.

-tempdir_mode

This option performs a Partial File Restore of MXF files, and is applicable only to Omneon servers. The MXF Partial File Restore request will terminate if this option is not included in the request.

Table C-36 Omneon Spectrum MediaDirector Source/Destination Archive Parameters

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Enter the absolute clip directory in this field, or leave this field empty to use the configured Root Path.	/default/clip.dir
FileNames	Enter the name of the clip in this field.	MyClip

Table C-37 Omneon Spectrum MediaDirector Source/Destination Restore Parameters

DIVA_restoreObject Parameter	Value	Example
FilesPathRoot	Enter the absolute clip directory in this field, or you can leave this field empty to use the configured Root Path.	/default/clip.dir

Omneon MediaGrid Content Storage System

MediaGrid is the Content Storage System from Omneon to which Omneon Spectrum servers can be connected.

Note:

MediaGrid is not supported in the Linux environment.

The MediaGrid system consists of two major components; ContentServers that store and provide access to media, and ContentDirectors that act as overall file system controllers. ContentDirectors manage the distribution of data throughout the system.

Like any other client system, DIVArchive gets access to the media through a MediaGrid ContentDirector. DIVArchive interfaces with MediaGrid using the CIFS protocol exclusively over a Gigabit Ethernet Network.

The MediaGrid ContentDirector manages data access while the data transfer occurs directly to/from the ContentServers. The Omneon File System Driver (FSD), installed on MediaGrid clients hides this complexity to client systems.

Note:

The Omneon FSD must be installed on each Actor exchanging assets with MediaGrid.

The latest release of Omneon FSD for Windows is available for download at http://support.omneon.com/Updates/Omneon/Current/MediaGrid/WinFSD. The password for the site (if required) is alloyparka.

When material is wrapped in QuickTime format, the essence files are stored using a specific folder structure. DIVArchive also uses unique FTP site commands for smart and transparent access to the essence files (in particular, automatic discovery of folders structure and collision-avoidance at restore time).

When the Actor is running as a Windows service, MediaGrid shares are accessed through a UNC path because drive letters mapped to network drives are not accessible by Windows services. In this case ensure the following:

• Omneon MediaGrid folders being accessed by DIVArchive are properly shared for a given Windows user.

• The DIVArchive Actor service is configured to run under this user account.

• The user has local administrative rights on the DIVArchive Actor.

You must create one record for each ContentDirector DIVArchive must move data to and from.

Table C-38 Omneon MediaGrid ContentDirector Attributes

Attribute	Value	Example
IP Address	Leave this field empty.
Source Type	MEDIAGRID	MEDIAGRID
Root Path	\\ContentDirector\filesystem\clip.dir	\\10.30.0.200\cldev4\clip.dir \\mycontentdir\fs5\clip.dir

Table C-39 Omneon MediaGrid Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	enter the name of the clip in this field.	MyClip

In cases where the asset is wrapped as QuickTime, DIVArchive searches for files matching the format clipname.mov or clipname.MOV. DIVArchive automatically retrieves and processes all of the potentially referenced files.

In cases where the material is wrapped as MXF, DIVArchive will search for a file matching the format clipname.mxf or clipname.MXF. There is only one file per clip.

Quantel Power Portal Gateway

The Quantel Power Portal was previously called the ISA Gateway. An ISA system consists of the following components:

ISA Manager

The ISA Manager contains the Clip Database. Clips are identified using a unique FID (File Identifier) in the ISA System.

Q or sQ Servers

One or more Q or sQ servers. These servers contain video cards and disk arrays. Each disk array is associated to a POOL ID, and a single sQ Server can have several POOL IDs. For example, sQ Server ID 1 contains POOL ID 1 and POOL ID 2, sQ Server ID 2 contains POOL ID 3, and sQ Server 3 contains POOL ID 4.

ISA Gateway (Power Portal)

This gateway is a FTP server that imports and exports clips.

You must create one record for each Power Portal (ISA Gateway)

Table C-40 Quantel Power Portal Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the video server.	10.80.114.21
Source Type	QUANTEL_ISA	QUANTEL_ISA
Connect Options	-login {FTP_user_name} -pass {FTP_password}	-login ftpuser -pass Pa$$word

The Actor configuration parameters are located in the Actor frame of the DIVArchive Configuration Utility.

Table C-41 Quantel Power Portal Actor Configuration Parameters

Parameter	Description	Suggested Values
DIVAACTOR_QUANTELRENAMECLIPS	Enables and disables the file renaming feature.	0 indicates the renaming feature is disabled. 1 indicates the renaming feature is enabled.

DIVAACTOR_QUANTELRENAMECLIPS applies to Restore requests only. If this parameter is set to 1, and the Object Name format is clipName,UID (this is Omnibus naming), then object related files are renamed using clipName as the Name Root.

For example, if the object Superman,01AB45 is composed of files 8152.D10 and 8152.WAV, and is restored to a QUANTEL_ISA destination, the following is true:

• If DIVAACTOR_QUANTELRENAMECLIPS is set to 0 (disabled), DIVArchive transfers files called 8152.D10 and 8152.WAV to Power Portal.

• If DIVAACTOR_QUANTELRENAMECLIPS is set to 1 (enabled), DIVArchive transfers files called Superman.D10 and Superman.WAV to Power Portal.

Quantel storage is a flat structure. You must specify the parameters as follows when archiving a clip:

Table C-42 Quantel Power Portal Source/Destination Archive Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	FID1.ext1[,FID1.ext2,] and so on.	clip.mxf,clip1.tar

Files coming from Power Portal can be different file types including: D10+WAV (file names similar to 8152.D10 and 8152.WAV), MXF (TestClip.mxf), and TAR (FramesDifference.tar).

If a file is restored twice to Power Portal, the first file is not overwritten. The second restore creates a new file that is identified by a new FID. The DIVArchive Actor captures the new FID after the transfer and forwards it to the DIVArchive Manager.

You must call DIVA_GetRequestInfo to obtain the new FID using the DIVArchive API. If the request is completed, the new FID is in the request's ADDITIONAL_INFO field within ClipID tags. The ClipID tag is encapsulated in the ADDITIONAL_INFO tag.

<ADDITIONAL_INFO>
 <ClipID>8546</ClipID>
</ADDITIONAL_INFO>

Automation is also free to specify a POOL ID in the FilePathRoot Restore request parameter. If no POOL ID is specified, Power Portal will automatically assign one at restore time.

Sony Hyper Agent Servers

Hyper Agent is the name given to Newsbase's FTP server from Sony. The implementation of this FTP server is specific because the LIST command returns a proprietary formatted list of files. This list contains duration, and start and end time codes, but not the size of the file in bytes. The size of each clip is calculated by the Actor using three values; duration, frame rate and bitrate. The resultant size is not accurate, but it is enough for the Manager to allocate a tape for all Archive requests. The progress bar is not affected by the approximated size.

Duration, frame rate and bitrate are retrieved using the following two commands, which are set by the Actor at the beginning of each Archive request:

SITE FSIZ {Clip ID}

This SITE command returns the duration of the specified clip.

SITE GCNF

This SITE command returns the current system configuration of the server. This system configuration must remain the same to ensure that all of the clips on the server are the same.

The following example is a log entry of communications between Actor and the Hyper Agent FTP:

Note:

In the following log example the word configuration is misspelled; this is a bug in the FTP server and appears in logs as shown in the example.

SITE FSIZ 1444247

200 150 (the duration is 150 frames)

SITE GCNF

213-System configureation

PAL (the frame rate is 25 frames per second)

20

30.0 (the Bitrate is 30 Mbps)

D10

SD_IFRAMEONLY

213 End of system configuraion

You must create one record for each ClipBox DIVArchive must moved data to and from.

Table C-43 Sony Hyper Agent Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the Newsbase server.	10.80.114.21
Source Type	SONY_HYPER_AGENT	SONY_HYPER_AGENT
Connect Options	-login {user_name} -pass {password}	-login sony -pass sony

Table C-44 Sony Hyper Agent Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Leave this field empty.
FileNames	Enter the Clip ID in this field.	1444247

Standard FTP and SFTP Servers

DIVArchive running in a Windows environment can interface with any standard FTP server (Linux or Windows), and SFTP servers (known as SSH FTP or Secure FTP). Oracle only supports Linux-based FTP servers when operating in a Linux environment. The Windows-based FileZilla and IIS FTP servers are not supported in Linux because these servers are incapable of handling large numbers of files.

Video servers supporting a fully RFC-959 compliant FTP server are considered standard FTP servers. The only restriction that applies is that Linux-style directory listings are required. You set this parameter in the Home Directory section of the FTP Site Properties for Microsoft IIS FTP servers.

You must create one record for each video server DIVArchive must transfer data to and from.

Table C-45 Standard FTP and SFTP Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the FTP server.	10.80.114.21
Source Type	FTP_STANDARD or SFTP	FTP_STANDARD
Connect Options	-login {user_name} -pass {password} -port {port_number}	-login moon -pass mars -port 27

-login

This is the FTP or SFTP user name. The default value is anonymous.

-pass

This is the FTP or SFTP user's associated password. The default value is anonymous.

-port

This is the port number the FTP or SFTP server is listening on for connections. The default value for FTP_STANDARD is 21, and for SFTP is 22.

You can specify parameters three different ways for Archive requests as described in the following table:

Table C-46 Standard FTP and SFTP Servers Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Full path to files Partial path to files No path entry	/my_videos/movies /my_videos
FileNames	Names of files Partial path and names of files Full path and names of files	maniolia, matrix movies/maniolia, movies/matrix /my_videos/movies/maniolia, /my_videos/movies/matrix

DISK_FTP_PASSIVE_MODE

By default, data connections are created in active mode. In active mode, the DivaFtp client connects from a random, unprivileged port that is higher than port 1023. Then, it starts listening on the port and sends a PORT command to the FTP server. Valid values for this parameter are 0 (disabled) and 1 (enabled).

When you set DISK_FTP_PASSIVE_MODE to 1 (enabled), data connections are created in passive mode. In passive mode, DivaFtp sends a PASV command and the server (not the client) creates the socket.

DISK_FTP_BLOCK_SIZE

The DISK_FTP_BLOCK_SIZE parameter defines how much data Actor tries to send and receive with a single system call during FTP transfers. For example, if the internal buffer size of Actor is set to 2 MB and DISK_FTP_BLOCK_SIZE is set to 32768 bytes, 64 system calls are required to write a single buffer to a data socket. The default value is 32768 bytes.

DISK_FTP_SOCKET_WINDOW_SIZE

The DISK_FTP_SOCKET_WINDOW_SIZE parameter adjusts the normal buffer sizes allocated for output and input buffers. DISK_FTP_SOCKET_WINDOW_SIZE is internally used to set SO_SNDBUF and SO_RCVBUF for FTP managed disk types. The default value is 65536 bytes.

Local Sources

A local source represents a disk partition for a specific Actor (internal disks, NAS or SAN disks), and is tied to a specific Actor (versus a disk source not tied to any particular Actor).

You must create one record for each local source DIVArchive must transfer data to and from.

Table C-47 Local Source/Destination Attributes

Attribute	Value	Example
Name	Enter the same name as the Actor this source is bound to.	actor1
IP Address	Enter the same IP address as the Actor this source is bound to.	10.80.114.21
Source Type	LOCAL	LOCAL

You can specify parameters three different ways for Archive requests as described in the following table:

Table C-48 Local Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Full path to files Partial path to files No path entry	/my_videos/movies /my_videos
FileNames	Names of files Partial path and names of files Full path and names of files	maniolia, matrix movies/maniolia, movies/matrix /my_videos/movies/maniolia, /my_videos/movies/matrix

If NT drive letters (for example E:) are used, Oracle highly recommends leaving them in the FilesPathRoot section (that is, use scheme 1 or 2 in the previous table). Including them in the FileNames section prevents the request from replacing them with another path at restore time. Therefore, you cannot restore these objects on a different platform (for example a Linux-based FTP server) where drive letters are not considered valid paths.

Disk and CIFS Sources

A DISK or CIFS source represents a disk partition assumed to be visible from all Production System Actors. The only difference between DISK and CIFS is the way blocks of data are read and written:

• DISK instructs Actors to use (Windows) Direct I/O.

• CIFS instructs Actors to use (Windows) Buffered I/O.

• Both DISK and CIFS sources support UNC paths.

You must create one record for each DISK or CIFS source DIVArchive must move data from the source to the destination. You can also create a generic source to represent any type of DISK or CIFS source.

Table C-49 DISK and CIFS Source/Destination Attributes

Attribute	Value	Example
Name	Enter a nickname for the source.	generic-disk
IP Address	Enter the IP address for the source.	10.80.114.21
Source Type	DISK or CIFS	DISK

You can specify parameters three different ways for Archive requests as described in the following table:

Table C-50 DISK and CIFS Source/Destination Use

DIVA_archiveObject Parameter	Value	Example
FilesPathRoot	Full path to files Partial path to files No path entry	/my_videos/movies /my_videos
FileNames	Names of files Partial path and names of files Full path and names of files	maniolia, matrix movies/maniolia, movies/matrix /my_videos/movies/maniolia, /my_videos/movies/matrix

If NT drive letters (for example E:) are used, Oracle highly recommends leaving them in the FilesPathRoot section (that is, use scheme 1 or 2 in the previous table). Including them in the FileNames section prevents the request from replacing them with another path at restore time. Therefore, you cannot restore these objects on a different platform (for example a Linux-based FTP server) where drive letters are not considered valid paths. Oracle only supports Linux-based FTP servers when operating in a Linux environment. The Windows-based FileZilla and IIS FTP servers are not supported in Linux because these servers are incapable of handling large numbers of files.

Metasources

A Metasource is a collection of several (single) Sources of the same type. It is assumed that all Sources of the Metasource are sharing the same online storage. Each Source of the Metasource should be of the same regular type (that is, any type except METASOURCE), aka Metasource Base Type. A Metasource provides load-balancing and failover mechanisms across all single sources of the Metasource.

You must create one record for each Metasource DIVArchive must transfer data to and from.

Table C-51 Metasource Source/Destination Attributes

Attribute	Value	Example	Comments
Name	Name for video server's shared storage.	gvg-man-production
IP Address	server1 [,server2,server3] and so on	10.158.1.10,10.2.5.60,97.64.52.3	server1, server2,server3 must also be defined in the configuration as regular sources of the same type (all types except METASOURCE, LOCAL, and DISK are permitted, for example, OMNEON, PDR, and so on).
Source Type	METASOURCE	METASOURCE
Production System	Must be the same for Metasource and all single sources.		Manager will not start if there is no match.
Site	Either one or the other of the sites from Metasource single sources.		Site specified for Metasource is considered by Manager for resource selection.
Root Path	You can specify a Root Path at the Metasource level.		If the Metasource Root Path is null, the Root Path from the selected single source is considered.
Max Accesses Max Write Acc. Max Read Acc. Max Throughput	Actual value for Metasource does not matter.		The value from the selected single source is considered. You cannot leave these fields empty. Oracle suggests setting traffic regulation parameters to the sum of all single source's respective parameters. Oracle also recommends that you do not make any changes to this parameter while there are active requests being processed because it can lead to request termination.
Connect Options	-failover_time={time_in_milliseconds} -retry_actor={number_of_retries}	-failover_time=300 -retry_actor=3

-failover_time={time_in_milliseconds}

When you select a single source to process a request and it fails, the single source is temporarily not considered part of the Metasource for 600 milliseconds. You can change this default value using this option. This option cannot be superseded by the request option.

-retry_actor={number_of_retries}

You use this option to specify the number of Metasource single sources to be tried for each Actor that can be part of the request processing. The default, when this option is not specified, is 2.

For example, if the Metasource is defined as sd1, sd2, sd3, the set of possible Actors is a1, a2, and -retry_actor is set to 2, DIVArchive will try a maximum of four combinations; most likely a0-sd1, a0-sd2, a1-sd3, a1-sd1.

This option cannot be superseded by the request option.

You can also specify other single source connection options for the Metasource. The following table indicates the effects for each possible option when specified at the Metasource level:

Table C-52 Metasource Source/Destination Connect Options

Connect Option	Considered?	Comments
qos=	No	The qos value should be the same for all Metasource single sources, otherwise Manager will not start.
-login	No	Value from selected single source is considered. Applicable to FTP Source/Destinations.
-user	No	Value from selected single source is considered. Applicable to CIFS Source/Destinations.
-pass	No	Value from selected single source is considered.
-port	No	Value from selected single source is considered.
-allow_delete_on_source	No	Implicitly assumed to be true if all single sources (implicitly or explicitly) allow deleting on Source. Otherwise, assumed to be false.
-arch_renaming	No	Value from selected single source is considered.
-rest_renaming	No	Value from selected single source is considered.
-file_order	No	Value from selected single source is considered.
-tr_archive_format	Yes	Values specified for single sources do not matter.
-tr_restore_format	Yes	Values specified for single sources do not matter.
-tr_names	Yes	Values specified for single sources do not matter.
-rest_metadata	No	Value from selected single source is considered.
-num_actors_retry=	Yes	Values specified for single sources do not matter.
-ftp	No	Value from selected single source is considered.
-cifs	No	Value from selected single source is considered.
-nometadata	No	Value from selected single source is considered.
-format	No	Value from selected single source is considered.
-extension	No	Value from selected single source is considered.
-k2	No	Value from selected single source is considered.

You use a Metasource the same as any source of Metasource Base Type.

There are instances where it is required to delete content, and possibly the parent folder, on a server. To satisfy all possible scenarios there are two options available:

• -r deletes recursively

• -delete_fpr includes deletion of the parent folder

The two options, -r and -delete_fpr, work either separately or together, as described in the following workflow examples:

Table C-53 Examples for the -r and -delete_fpr Options

FilesPathRoot	Files	Options	Result
C:\source\root	*	-r	DIVArchive deletes the content of C:\source\root recursively.
C:\source\root	*	-r -delete_fpr	DIVArchive deletes the content of C:\source\root recursively, and then deletes root.
C:\source\root	*		DIVArchive deletes the content of C:\source\root (first level only).
C:\source\root	*	-delete_fpr	DIVArchive deletes the content of C:\source\root (first level only), and then eventually deletes root if it is empty.
C:\source\root	obj\*	-r	DIVArchive deletes the content of C:\source\root\obj recursively, and then deletes C:\source\root\obj.
C:\source\root	obj\*	-r -delete_fpr	DIVArchive deletes the content of C:\source\root\obj recursively, then deletes C:\source\root\obj, and finally deletes C:\source\root if it is empty.
C:\source\root	obj1\* obj2\*	-r	DIVArchive deletes the content of C:\source\root\obj1 recursively, then deletes C:\source\root\obj1, and then deletes the content of C:\source\root\obj2 recursively, and finally deletes C:\source\root\obj2.
C:\source\root	obj1\* obj2\*	-r -delete_fpr	DIVArchive deletes the content of C:\source\root\obj1 recursively, then deletes C:\source\root\obj1, then deletes the content of C:\source\root\obj2 recursively, then deletes C:\source\root\obj2, and finally deletes C:\source\root if it is empty.
C:\source\root	obj1\* obj2\subfolder\clip.mov	-r -delete_fpr	DIVArchive deletes the content of C:\source\root\obj1 recursively, then deletes C:\source\root\obj1, then deletes the content of C:\source\root\obj2\subfolder\clip.mov, then deletes C:\source\root\obj2\subfolder if it is empty, and then deletes C:\source\root\obj2 if it is empty, and finally deletes C:\source\root if it is empty.

Expedat Servers

DIVArchive can interface with DataExpedition Expedat servers (up to release 1.17), also known as servedat. This solution uses MTP, which is a high performance file transfer protocol. This WAN acceleration software can use 100 percent of the bandwidth of any long distance or high latency networks.

See the DataExpedition Expedat Server Installation Manual for detailed information on installation and configuration.

This Source/Destination works similar to the FTP_STANDARD Source/Destination in terms of the FilesPathRoot and list of files.

When Expedat Server is configured with folders having the RestrictHome setting enabled, the RootPath for the Data Expedition Source/Destination entry must not reference an absolute path. The RootPath may be interpreted as a path that is not accessible from the Expedat home directory. For example, the Root Path / is interpreted as C:\. However, if the Expedat home directory is D:\folder, Expedat will attempt to access the path D:\folder on C:\, which is not valid. If the home directory is C:\folder, using the Root Path / is acceptable.

Instead of using an absolute path, relative path addressing must be used to resolve this situation. You accomplish relative path addressing by leaving the Root Path field empty in the Configuration Utility, or specifying the relative path in the FilesPathRoot field of the GUI Manager or API request for the archive or restore operation.

To set up a default home location so that an API request can always use "" files path, the Expedat cv_password.txt file must contain a log in account assigned to a folder with the RestrictHome option set.

For example:

diva:diva:::S:\DFM:RestrictHome
diva1:diva:::S:\DFM1:RestrictHome
diva2:diva:::S:\some_other_folder:RestrictHome

The separate user log in and password accounts allow for the creation of more than one EXPEDAT Source/Destination entry with different home locations. The API request can then reference the EXPEDAT Source/Destination pointing to the desired home location.

When you use DFM to monitor an FTP folder in a Linux environment, it must be configured similar to the following example:

User: diva

User home directory: /ifs

Folder to be Monitored: /ifs/folder1

Correct DFM Configuration: ftp://diva:password@host_ip/folder1

Incorrect DFM Configuration: ftp://diva:password@host_ip/ifs/folder1

You must create one record for each Expedat server DIVArchive must transfer data to and from.

Table C-54 Expedat Server Source/Destination Attributes

Attribute	Value	Example
IP Address	IP address of the Expedat server.	10.80.114.21
Source Type	EXPEDAT	EXPEDAT
Connect Options	-login {user_name} -pass {password} -port {port_number} -license {license_code} -encryption -seq_buffer_size {size_in_megabytes} -exp_maxrate {size_in_kilobytes} -exp_mindatagram {size_in_bytes}	-login moon -pass mars -port 8080 -license 46FE464A98 -encryption -seq_buffer_size 16 -exp_maxrate 1024 -exp_mindatagram 2848

-login and -pass

These options are mandatory if the server is configured with authentication parameters.

-port

This option should always be present because there is no default value.

-license

This is a mandatory parameter to use the DIVArchive Expedat Client. Without the license code the EXPEDAT Source/Destination is unusable. You can only configure one Expedat license key per production system.

-encryption

This option works with the Expedat Source/Destination, is optional, and enables Expedat content encryption during transfers.

-seq_buffer_size {size_in_megabytes}

This option defines the size of the DataExpedition internal buffer for each transfer. The default value is 16 MB and should be sufficient for most transfers. A large buffer allows DataExpedition to continue moving data during times when the sender or receiver may not be able to process it. However, a small buffer consumes less memory.

-exp_maxrate {size_in_kilobytes}

This option sets an approximate limit on the number of kilobytes per second, per transfer. The default is unlimited, but can be used as an alternate method of controlling bandwidth.

-exp_mindatagram {size_in_bytes}

This transfer protocol is over UDP. This option defines a minimum size for each network datagram payload that DataExpedition sends. The purpose is to prevent DataExpedition from sending too small of a packet over the network. You may want to set this value between 2848 and 8544 when using a very fast network path (Gigabit or higher) and every device along the path supports Jumbo Frames (MTU 9000). Using large datagrams can greatly reduce CPU overhead. However, using this setting without Jumbo Frames being fully supported can cause severe performance issues or loss of connectivity.