System configuration [VC 21.3.1 GEN]

Indexing configuration

The indexing configuration contains the parameters that relate to search and indexing.

Where Vidispine can reach Solr or ZooKeeper.
When to commit or soft commit.
The Solr query request parameters.
The default field settings.

This configuration replaces the configuration properties listed under Search and indexing.

Example

Full text indexing could be disabled for all fields, unless explicitly specified for a field, using:

HTML/XML

<IndexingConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <solrPath>http://localhost:8088/solr</solrPath>
  <fieldDefault>
    <name>*</name>
    <fullText>false</fullText>
  </fieldDefault>
</IndexingConfigurationDocument>

Metrics configuration

See StatsD on how to configure how metrics are sent to StatsD. The configuration resource is described at Metrics settings.

By default jobs that need to read or write to an FTP server will establish, use and end separate connections to the server. By configuring a FTP connection pool you can change so that the jobs share and reuse FTP connections. This can reduce the time it takes to transfer files over high latency connections.

For example, to create a connection pool with the default settings:

NONE

PUT /configuration/ftp-pool
Content-Type: application/xml

<FtpPoolConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <pool/>
<FtpPoolConfigurationDocument/>

If no pool is specified then pooling will be disabled. Unless overridden, the pool will be unbounded, and connections will expire after 1 minute. That is, the above configuration is identical to:

NONE

PUT /configuration/ftp-pool
Content-Type: application/xml

<FtpPoolConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <pool>
    <minSize>0</minSize>
    <maxSize>-1</maxSize>
    <evictionInterval>30000</evictionInterval>
    <minIdleTime>60000</minIdleTime>
  </pool>
</FtpPoolConfigurationDocument>

The FTP pool configuration resource is described at FTP pool configuration.

Database purging

Vidispine supports mechanisms for purging old information in database tables. Especially four tables can grow quite large without purging enabled.

Updated method for purging configuration

The preferred way of updating the database purging configuration is by create a DatabasePurgingConfigurationDocument, see Database purging configuration.

Change-log table

The change-log table holds information about data that should be sent to other sites. If multi-site is disabled (disableSiteCrunching), this table grows forever.

To enable purging of the table, two configuration properties are used: changeLogPurgingTime and changeLogForcePurgingTime. The first one controls deletion of entries that have been processed, the other one controls deletion of entries regardless of state.

Sensible values are 43200 and 86400, corresponding to one and two months, respectively.

Configuration can also be controlled via DatabasePurgingConfigurationDocument. For example:

HTML/XML

<DatabasePurgingConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <changeLog>
    <age>43200</age>
    <forceAge>86400</forceAge>
  </changeLog>
</DatabasePurgingConfigurationDocument>

Audit trail table

The audit trail table contains all API requests, see Audit trails.

To enable purging of the table, two configuration properties are used: auditTrailPurgingTime and auditTrailPurgingDirectory. Both must be set in order for purging to take place.

When purging is enabled, entries that are older than auditTrailPurgingTime minutes will be removed and put in a file inside the auditTrailPurgingDirectory folder.

A sensible value is 43200 or higher, corresponding to one month.

Configuration can also be controlled via DatabasePurgingConfigurationDocument. For example:

HTML/XML

<DatabasePurgingConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <auditTrail>
    <age>43200</age>
    <uri>s3://key:secret@archival-bucket/requests/</uri>
  </auditTrail>
</DatabasePurgingConfigurationDocument>

By setting the compress element in the configuration document, entries will be stored using gzip compression. The default value is true.

The entries are stored in batches. The number of entries per batch is controlled by the batch element in the configuration document. The default value is 10000 entries. If there are less than 10000 entries that fulfill the time criteria, the purging of the audit trail table will pause.

By setting the body element in the configuration document, entries will also include the request bodies and response codes. The default value is false.

The directory can be a full URI, such as a S3 or FTP location.

Job table

To enable purging of the table, two configuration properties are used: jobPurgingTime and jobPurgingDirectory. Both must be set in order for purging to take place.

When purging is enabled, entries that are older than jobPurgingTime minutes will be removed and put in a file inside the jobPurgingDirectory folder.

Configuration can also be controlled via DatabasePurgingConfigurationDocument. For example:

HTML/XML

<DatabasePurgingConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <job>
    <age>43200</age>
    <uri>s3://key:secret@archival-bucket/job/</uri>
  </job>
</DatabasePurgingConfigurationDocument>

By setting the compress element in the configuration document, entries will be stored using gzip compression. The default value is true.

The directory can be a full URI, such as a S3 or FTP location.

Transfer log table

Configuration is controlled via DatabasePurgingConfigurationDocument. For example:

HTML/XML

<DatabasePurgingConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <transferLog>
    <age>1440</age>
    <uri>s3://key:secret@archival-bucket/transfers/</uri>
  </transferLog>
</DatabasePurgingConfigurationDocument>

Both the age and uri element has to be set. Entries than represents a finished transfer older than age minutes are exported to the destination.

The forceAge element controls exports of non-finished transfers - transfers that have disappeared for some reason. The default value of forceAge is the value of the age element.

By setting the compress element in the configuration document, entries will be stored using gzip compression. The default value is true.

The entries are stored in batches. The number of entries per batch is controlled by the batch element in the configuration document. The default value is 10000 entries. If there are less than 10000 entries that fulfill the time criteria, the purging of the transfer log table will pause.

Default job priority

New in version 5.2.1.

The default job priorities are configurable by type. For example, the following configuration document will make IMPORT jobs default to MEDIUM priority and EXPORT jobs default to HIGH priority:

HTML/XML

<JobPriorityConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <job type="IMPORT">MEDIUM</job>
  <job type="EXPORT">HIGH</job>
</JobPriorityConfigurationDocument>

If no default priority has been specified for a given job type, the job will default to MEDIUM priority.

CORS configuration

New in version 4.15.

Vidispine can be configured to emit Cross-Origin Resource Sharing (CORS) headers.

The CORS configuration is set using the CORS configuration resource. The configuration document consists of a number of entries, each of them are checked for CORS evaluation. If an entry condition matches the incoming request, the CORS headers set in the entry are outputted, and no other entries are matched. For example:

NONE

PUT /configuration/cors

HTML/XML

<CORSConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <entry>
    <request/>
    <response>
      <allowOrigin>*</allowOrigin>
    </response>
  </entry>
</CORSConfigurationDocument>

The conditions in each entry can match HTTP method, the request path, the CORS origin, or any other header. For example:

HTML/XML

<CORSConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <entry>
    <request>
      <pathRegex>API.*/item/.*</pathRegex>
      <headerRegex>
        <key>connection</key>
        <value>.*aliv.*</value>
      </headerRegex>
    </request>
    <response>
      <allowOrigin>*</allowOrigin>
      <allowMaxAge>86400</allowMaxAge>
    </response>
  </entry>
</CORSConfigurationDocument>

Semantics are as follows.

Multiple methods can be set per entry. If one entry method matches the request method, the entry matches as far as for method. If no methods are set on the entry, the entry matches.
Origins can be specified both exact or via regular expressions. If one entry origin matches the request origin, the entry matches as far as for origin. If no origins are set on the entry, the entry matches.
Request paths can be specified via regular expressions. If one entry path matches the request path, the entry matches as far as for path. If no paths are set on the entry, the entry matches.
Request headers can be specified via regular expressions. All specified headers for the entry must match the request. If the HTTP request does not contain a value for a specified header, the entry does not match. If the HTTP request contains multiple values for a specified header, it is sufficient that only one value matched the entry header condition.

When the entry matches, the entry may contain which origin that is allowed, the max age for the access, which methods that are allowed, which HTTP headers. The entry can also contain other, arbitrary, headers. If methods are not specified, the methods are automatically deduced from the API methods.

Configuration properties

Configuration properties are used in Vidispine to control system-wide parameters.

Since 5.3, configuration properties can be used to control some system property settings, see below.

General

apiUri

URI to Application Server. Used by transcoder(s), so need to be a proper host if transcoder(s) run on another machine.

Mandatory:	Yes
Example:	`http://localhost:8080/API/`

apiNoauthUri

URI to Application Server, to use to access the no-auth API. Used by transcoder(s), so need to be a proper host if transcoder(s) run on another machine.

Example:

http://localhost:8080

clusterName

Optional alphanumerical identifier for the Vidispine installation/cluster. Must be set (to a unique identifier) if multiple Vidispine installations are to share a common set of transcoders.

Example:

ABPRD, ABDEV, BCPRD

disableSiteCrunching

Do not build site replication packages. Recommended to be set to true for systems not running site replication.

Default:

true since 4.2.6. Previous versions: false

validatexml

Enable schema validation of the incoming and outgoing xml document.

Default:

false

slaveLicenseProxy

Use a proxy for Connection to Vidispine Online Licensing System. Format is

http://IP:port/ or
socks://IP:port/

Proxy authentication is not supported.

Default:

none

defaultTranscoder

Default transcoder resource to use. Valid values are:

vidinet - To use the first available transcoder from Vidinet.
A resource id - To use the transcoder with that id.

Example:	`VX-1`
Default:	none

Search and indexing

Deprecated since version 4.2: The Solr and ZooKeeper properties are deprecated. Use Indexing configuration instead.

solrPath

URI ( not path! ) to Solr.

Mandatory:	Yes (No for SolrCloud)
Example:	`http://localhost:8081/solr/`

elasticsearchPath

URI to Elasticsearch’s RESTful interface.

Mandatory:	Yes (if using Elasticsearch). Optional if `url` has already been configured in search backend
Example:	`http://localhost:9200/`

zkHost

For SolrCloud: A comma separated list of host:port pairs to the servers in the ZooKeeper ensemble.

Mandatory:	No (Yes for SolrCloud)
Example:	`localhost:3000,example.com:3001`

reindexFixedDelay

Normally, ReindexCruncher will be waked up immediately if an entity is marked for reindex, and work continuously until all pending entities has been processed. This is to make sure that changes to entities are indexed as soon as possible.

However, for use cases like migrating data from other system into VidiCore, many updates could be performed to an entity in a short amount of time, causing multiple reindex request and thus puts additional load on the search backend.

If the entities are not expected to be searchable ASAP, reindexFixedDelay can be used to set a fixed working delay (in seconds) in ReindexCruncher, allowing entity updates to be “buffered” and reducing load on the search backend.

New in version 21.3.1.

Default:	`empty`
Example:	`60`

solrCollection

For SolrCloud: The collection in Solr to be used by Vidispine.

Mandatory:	No (Yes for SolrCloud)
Example:	`collection1`

solrQueryTimeout

The request timeout in milliseconds to use when querying Solr.

Default:

60000

solrGroupLimit

The maximum number of timespans to return per item or collection.

Mandatory:	No
Example:	`10`

solrPingAttempts

The number of times to ping a Solr node before aborting an active request.

Default:

5

solrPingTimeout

The request timeout in milliseconds to use when checking if a Solr node. is alive

Default:

5000

solrCommitInterval

The interval (in milliseconds) of Vidispine sending hard commit to Solr.

Default:

10000

solrSoftCommitInterval

The interval (in milliseconds) of Vidispine sending soft commit to Solr.

Default:

-1 (disable)

solrAutoSoftCommit

If Vidispine should send soft commit to Solr automatically.

Default:

true

solrUpdateQueueSize

Number of documents Vidispine will send in batch to Solr.

Default:

100

solrDeleteMergeSize

The number of delete queries to merge into one before sending to Solr.

Changed in version 5.6: The default was changed from -1 (do not merge any delete queries) to 100.

Default:

100

elasticsearchWorkerCount

Number of worker threads to use when sending documents to Elasticsearch.

Default:	`1`
Since:	5.6

elasticsearchBulkBuffer

The document buffer size (in bytes) in the Elasticsearch worker thread.

Default:	`10000`
Since:	5.6

indexFieldGroups

If metadata field groups should be indexed in Solr. Setting this to false can reduce the load and the size of the index if items have a large number of groups in the metadata, but will mean that no results will be available when searching for field groups.

Default:

true

indexCollectionItemOrder

If the order of an item in a collection should be indexed in Solr. Settings this to false can greatly reduce the number of fields created in Solr and improve performance on systems with a lot of collections. This affects collection item retrieval. See also Retrieve the child-collections of a collection.

Recommended to be set to false for applications not relying on that feature. Requires a clean Solr index and a full re-index to take effect.

Default:

false

indexTimespans

If time coded metadata should be indexed in Solr. Setting this to false can reduce the load and the size of the index if items/collections have a large number of timespans in the metadata, but will mean that no time coded metadata can be found.

Default:

true

maxSearchResults

Maximum number of search results allowed to be returned (see Search items).

Default:

100

legacyTransientFieldTypes

This setting controls the datatype of the transient metadata fields. If true then all transient fields will be of type string. If false the *_size and *_count fields will be of type integer, and the rest will have type string.

Default:

true

skipLibraryIndexUpdates

If set to true, the auto-refreshing libraries won’t be updated after item metadata changes.

Default:

false

indexDocumentMetadata

If document metadata should be indexed. Setting this to false can reduce the load and size of the index. Document metadata is not searchable if this property is is set to false.

Default:	`false`
Since:	5.0

indexQueueLimit

This setting throttles indexing to a maximum number of messages in the ActiveMQ queue. In a system where indexing (Solr/Elastic) is slower than the database, this setting avoids that too many messages are stored on the queue. Set this value to 0 to specify no limit. See also activeMQAdminUrl.

Default:	`0`
Since:	5.7.1
Cached:	yes

Metadata

disableMetadataSchema

If a metadata schema has been defined (see Metadata schema), allows metadata that does not comply to the schema.

Default:

false

useAbsoluteSccTimeCode

If set to true Vidicore will not try to adjust the time codes in the SCC sidecar file to the usual relative (zero-based) timecodes for each item when imported.

Default:	`false`
Since:	5.6

Bulky Metadata

bulkyMetadataMigrationThreads

Number of threads to use for bulky metadata migration.

Default:	`1`
Since:	5.4.5

Authentication

passwordHashAlgorithm

The hash algorithm used to hash all user passwords. Note that changing this will make it impossible to authenticate with any existing user.

Default:

MD5

ldapAuthentication

If set to true, LDAP authenticated will be enabled.

Default:

false

userTokenMaxInterval

Maximum token time for token created by regular user, in seconds.

Default:

60

userTokenDefaultInterval

Default token expiration time, in seconds.

Default:

60

userTokenRefreshInterval

Minimum time between token refreshments, in seconds.

Default:

10

Jobs and imports

concurrentJobs

Number of jobs that are allowed to be started.

Default:

3

dedicatedJobPool

Enable/disable dedicated job pool configuration.

Default:

false

jobRetryCount

Number of retries for a job step before job continues with next step.

Default:

5

jobExclusiveStepMaxWait

The maximum number of seconds that a job step will wait before executing if there’s a job step running from another job for the same item or file. This exists to reduce the number of optimistic locking exceptions for job steps that are known to conflict.

Only applies to steps with the exclusive flag (0x0100000) set.

Default:

1

defaultIngestStorage

The default destination storage for imports and transcodes. Note that storages selected by storage rules will take priority over this.

Example:

VX-1

parseFileMetadata

If set to true, file metadata will be metadata parsed and inserted as Item metadata. Supported formats for this type of metadata include Office formats and PDF files.

Default:

false

maxFileMetadataLength

The max length of file content (in characters) that will be extracted as Item metadata. -1 means unlimited.

Default:

100000

parseXMP

If set to true, XMP metadata will be parsed and inserted as Item metadata.

Default:

false

xmpIgnoreElements

Contains comma-separated list of elements that are not read when parsing XMP data.

Default:

DocumentAncestors,Pantry,History

simpleImageProcessor

If false, use ImageMagick (must be installed, see Using ImageMagick for image handling). Otherwise, use built-in image handling.

Default:

true

disableThumbnailGeneration

Will disable thumbnail generation by default. Can be overridden on a per job basis.

Default:

false

alwaysGenerateThumbnails

When true, thumbnails will be generated on import even if no transcoding takes place.

Default:

false

disableThumbnailReindexing

When false, the thumbnail index will be rebuild when items are reindexed.

Default:

true

mediaCheckInterval

The retry interval of media check (seconds).

Default:

3

Storage and file

groupImportableFiles

When true, auto-import will only import one file for each file prefix as an item. Other non-sidecar files with the same prefix will be ignored. Set to false to import all files.

Default:

true

keepMissingFiles

If set to false then missing files that do not belong to any items will be removed from the database instead of being marked as lost.

Can be overridden on a per storage basis using the keepMissingFiles storage metadata property.

Default:

false

keepEmptyDirectories

Do not delete empty parent directories when deleting the last file in a directory, see Parent directory management.

Can be overridden on a per storage basis using the keepEmptyDirectories storage metadata property.

Default:

false

scanMethodAlgorithm

Set default scan method algorithm, see Storage scanning algorithm.

Can be overridden on a per storage basis using the scanMethodAlgorithm storage metadata property.

Default:	not set
Since:	5.5.2

storageActivationFile

Require a .storage file to be present in the storage method’s URI for storage to register as online.

Default:	`false`
Since:	4.17

fileHashAlgorithm

Hashing algorithm used. If changed, the c_hash column of the t_file table should probably be set to NULL.

Example:

SHA-1

enableTranscoderHash

Off-load file hash calculation available transcoder.

Default:

false

fileTempKeyDuration

Number of minutes a no-auth URI is valid (Auto method types).

New in version 4.16: This property also controls the valid duration of a VSA noauth URI.

Example:

10

useS3Proxy

When true, Vidispine will create S3 pre-signed URLs for reading during job.

Example:

false

s3ProxyValidTime

The validate time (in minutes) of S3 pre-signed URL.

Example:

60

s3ConcurrentParts

The number of threads used for each S3 file upload.

Default:

1

s3PartSize

The S3 chunk/part size. Note that multipart uploads are always performed regardless of file size. Each part that is uploaded will be larger than the previous part. To control the increase of the part size, use s3PartSizeIncrease.

Default:

5242880

s3PartSizeIncrease

The size increase of each S3 part that is uploaded.

The default is chosen so that the maximum part size is 2 GB. With S3 supporting a maximum of 10000 parts, and the default part size being 5 MB, this gives a maximum object size of 3.5 TB.

Default:

Automatically selected based on the part size.

s3ConnectionTimeout

The timeout (in milliseconds) when establishing a connection to S3.

Default:

50000

s3SocketTimeout

The timeout (in milliseconds) when reading from a connection to S3.

Default:

50000

s3MaxErrorRetry

The maximum number of times to retry a failed S3 request.

Default:

3

useAzureProxy

When true, Vidispine will create AZURE-SAS URLs for reading during job.

Example:

false

azureSasValidTime

Specifies for how many minutes an AZURE-SAS URI will be valid. See Retrieve a file.

Example:

60

stornextFileMetadata

Specifies which fields that should be stored on the Vidispine file entity from StorNext metadata. See StorNext Metadata.

Default:

location,class,existingCopies,targetCopies

useSegmentFiles

If true, files generated by the transcoder on storages that do not support partial modification are written as segment files on the storage, instead of local files on the application server. See Temporary storages for transcoder output.

Default:

false

useMutableRangeWrites

If true, use a writing pattern that is more efficient for S3 writes. The only reason for not have this set to true is in a clustered set-up with transcoders directly connected to Vidispine Server, i.e., not via VSA.

Default:

true

s3CredentialType

Controls the type of S3 credentials being sent to a VSA. Allowed values are none, temporary and secretkey. For more explanation, please check here.

Default:

temporary

stsCredentialDuration

The duration (in seconds) of any temporary AWS credentials generated for agents. The allowed range of values is [900, 129600]

Default:

129600

stsRegion

To generate temporary credentials Vidispine server will use the AWS Security Token Service (STS). Set this parameter to the region where you want Vidispine server to call the STS API. A good choice is the same region as your Vidispine server is running in.

Default:

us-west-2

stsAssumeRole

This is an optional configuration to use when generating credentials using the s3 scheme. The name of the role to use when generating assume role credentials to give direct access to a file using Generate temporary credentials.

Since:

4.15

defaultStorageRuleJobPriority

Controls which priority that should be assigned to jobs started as a result of storage rules, such as copy and delete jobs.

Default:	`MEDIUM`
Since:	5.1

Archival

trustArchivedFiles

A file needs to have a replica (another file with the same hash) before it can be removed by the storage rules.

If set to true, then archived files will be treated as valid replicas.

Default:

false

glacierArchiveDescription

Format the archive description according to the defined pattern:

{itemId} - Replaced by the item id.
{fileId} - Replaced by the id of the archived file.
{metadata-field:name} - Replaced by the value of the metadata field with the given name.
{sourceId} - Replaced by the id of the source file.
{sourcePath} - Replaced by the path of the source file.
{sourceUri} - Replaced by the URI of the source file.
{date} - Replaced by the archive date in ISO 8601 format.
{dateString} - Replaced by the archive date, in format dow mon dd hh:mm:ss zzz yyyy.

Example: Item:{itemId}, file:{fileId}, path:{sourcePath}, Archive date:{date}, Title:{metadata-field:title}

Default:

my archive {dateString}

File system

Since 4.1.1, several of the stat system calls that was made by the JRE has been migrated into call in the JNI code. This can be enabled using the localFSTimeData option. On systems where local file systems are sensitive to stat loads, it is recommended to enable this option, and possibly the statsPerSecond option.

fileHierarchy

See Using a tree structure for files.

Example:

0

fileSequenceStart

The starting number for file sequences.

Example:	`0`, `0001`
Default:	`1`

thumbnailHierarchy

See Using a tree structure for thumbnails.

Example:

0

Changing this property will cause old thumbnails to be lost. If you need to change the value on a system in production, please contact Vidispine.

statsPerSecond: Limit the total number of stats done on local file system. See also per-storage metadata ( Storages).

localFSTimeData

Use JNI methods for retrieving file modification time. See below.

Default:

false

firstLastModifiedAsCreationTime

Use the first reading of modification time as the creation time. Can be used on file systems which do not have the notion of creation time.

Default:

false

disableATime

Do not record atime. Used in conjunction with localFSTimeData.

Default:

false

Transfers

signiantManagerHost: Hostname of Signiant manager. See Signiant Integration

signiantManagerUser: Username for Signiant manager. See Signiant Integration

signiantManagerPassword: Password for Signiant manager. See Signiant Integration

enableTranscoderTransfer

Off-load file-to-file transfers of non-growing files to available transcoder.

Changed in version 5.3.1: Default value was changed to true

Default:

true

storageRuleDisableArchiveSources

If true, archived files will not be used as sources for storage rule transfers.

Default:

false

Library

libraryUpdateInterval

Default library update interval in the system (seconds).

Default:

60

libraryExpireTime

Default library expire time in the system (seconds).

Default:

86400

useLucene

If Lucene should be used directly when updating auto-refreshing libraries. This is faster than using Solr when there are a large amount of auto-refreshing libraries, but only works with the default Solr configuration that is shipped with Vidispine.

Default:

false

Growing files

fileGrowingTimeout

The max time a file can keep growing (seconds).

Default:

36000

fileNotGrowingTimeout

A file is considered as not growing if it has not been changed during this period (seconds).

Default:

600

JavaScript

javascriptInterpreter

The default JavaScript engine to use for scripts that don’t explicitly target a specific engine. Valid values are:

graalvm - Use GraalVM JavaScript.
rhino - Use Mozilla Rhino.

Changed in version 5.0: GraalVM JavaScript was made the default.

Default:	`graalvm`
Since:	5.0

Services

itemDeleteInterval

The running interval (seconds) of ItemDeleteCruncher during the “idle” period (no item to delete).

Default:

60

itemDeleteIntervalShort

The running interval (seconds) of ItemDeleteCruncher during the “busy” period (there are items to be deleted).

Default:

5

itemDeleteExecutionTime

Max running time (seconds) of ItemDeleteCruncher thread, after that it goes to sleep.

Default:

5

fileHashExecutionTime

Max running time (seconds) of a file hashing thread, after that it goes to sleep.

Default:

10

Broker

compressDocumentMessages

If JMS messages containing XML should be compressed or not. If true then the JMS_SUN_COMPRESS property will be set on JMS messages so that compression/decompression is performed by the OpenMQ client.

Works only with OpenMQ.

Default:

true

activeMQAdminUrl

Specifies the admin URI of ActiveMQ, for example http://myactivemq:8761. Normally it is not necessary specify it, but some functionality requires it, for example indexQueueLimit. For embedded broker, this does not have to be set.

Default:	not set
Since:	5.7.1
Cached:	yes

activeMQBrokerName

Specifies the ActiveMQ broker name used. Used in conjunction with activeMQAdminUrl.

Default:	`localhost`
Since:	5.7.1
Cached:	yes

Database management

auditTrailPurgingTime

Remove all audit trail entries older than the specified time (in minutes) and put them in XML format in files inside the directory described by auditTrailPurgingDirectory. See Audit trail table.

Default:

not set

auditTrailPurgingDirectory

Default:

not set

auditTrailPurgingCompress

If true, purged logs are stored using gzip compression. If false, they are stored as plain XML documents. Equivalent to the compress element in the database purging configuration document

Default:

true

auditTrailPurgingBatch

Sets batch size of audit log entries when puring. If there are fewer entries, purging is paused. Equivalent to the batch element database purging configuration document

Default:

10000

auditTrailIncludeBody

When true, the audit trail will include the body of requests, as well as the response code returned by the requests. These will always be included in purged documents, and can be seen in GET /log requests using the body query parameter. Equivalent to the body element in database purging configuration document

Default:	false
Since:	5.1

changeLogPurgingTime

Remove all processed change-log entries older than the specified time (in minutes). See Change-log table.

Default:

not set

changeLogForcePurgingTime

Remove all change-log entries (processed or unprocessed) older than the specified time (in minutes).

Default:

not set

jobPurgingTime

Remove all job entries older than the specified time (in minutes) and put them in XML format in files inside the directory described by jobPurgingDirectory. See Job table.

Default:

not set

jobPurgingDirectory

Default:

not set

disableSequenceChecker

Default:

false

On start-up, Vidispine checks the sequences for all tables, which can be a lengthy process. On a database which is known to be in a consistent state, setting disableSequenceChecker to true will cause this step to be skipped.

Transcoding

maxTranscoderUnavailableTime

When a transcoding job has started, and transcoder connection becomes available, wait for this time (seconds) for connection to be restored until job fails.

Default:

60 seconds

bulkyMetadataKeysToIgnore

Comma-separated list of bulky metadata keys to ignore from analysis results, e.g. crop,

Default:

(none)

transcoderNonblockingStatusInterval

How frequently the transcode progress of a job will be updated, in milliseconds. A lower number may give a better user experience, but also a higher number of writes to the database.

Default:

5000

Vidispine Server Agent

syncVxaFileChanges

This determines whether items created from the VSA or VDA are re-created when the corresponding original file is changed. If the original file is deleted, the item would be removed.

Default:

false

syncVxaDeletes

Similar to syncVxaFileChanges but this one only affects file deletions. When the original file on an agent storage is removed, the corresponding item in Vidispine would also be deleted.

Default:

true

useVxaHash

If set to true, Vidispine agent will be used to compute the hash of the files.

Default:

false

useVxaMimeType

If set to true, Vidispine agent will be used to detect the mime type of the files.

Default:

false

Deletion lock

autoRemoveExpiredDeletionLocks

It set to true, expired deletion locks on collections and items will be removed automatically

Since:	4.15
Default:	false

deletionLockCleanUpBatchSzie

Number of “to be removed” or “expired” deletion locks that will cleaned up in one batch.

Since:	4.17.7
Default:	100

System properties

System properties are set as argument to the JVM. See Setting JVM options.

The following properties are used in Vidispine:

com.vidispine.site

The site id prefix for the current site.

Default:

VX

com.vidispine.license.dir

The directory containing the Vidispine license or slave license file.

Default:

${com.sun.aas.instanceRoot}

com.vidispine.license.tmpdir

The directory where temporary license files may be stored.

Default:

${com.sun.aas.instanceRoot}

com.vidispine.credentials.dir

The directory containing credentials files such as the AwsCredentials.properties file used with Amazon S3 and Glacier.

Default:

${com.sun.aas.instanceRoot}

com.vidispine.log.dir

The directory containing the server log files.

Default:

${com.sun.aas.instanceRoot}/logs

vidispine.identifier.format

If full, output Long identifiers.

Default:

Normal, short identifiers.

com.vidispine.xml.prefix

Controls namespace prefix mapping of XML written by Vidispine that is _not_ part of API output, e.g. XML written to files. Comma-separated list of {namespace}={prefix} assignments. Namespaces without assignment get a ns# prefix.

Default:	Only `ns#` prefixes.
Example:	`http://www.smpte-ra.org/schemas/2067-2/2016=cc`

infi.sleep_after_start

The number of seconds to sleep after starting Infinispan, before VidiCore going on starting other services.

This should prevent “split-brain” issue during startup in some cases.

Default:

-1 (No delay)

com.vidispine.asyncpool.coresize

Controls the size of the internal async pool in VidiCore (New in 5.3.1.). It’s also available as a configuration property.

Default:

5

com.vidispine.service.quorum

The VidiCore background services (i.e. IndexCruncher, JobCruncher, etc.) would only be started/stopped if the quorum is reached. This is to prevent “non-clustered” services from being started on multiple nodes in a cluster with a “split-brain” issue.

The quorum value should be set to > N/2, where N is the total instance count in the cluster.

For Example: The quorum should be set to 2 for a two-node-cluster as well as a three-node-cluster.

(New in 5.3.5.).

Default:

1

Since 5.3, some system properties can be overridden by configuration properties. The properties that can be overridden are:

com.vidispine.site
vidispine.identifier.format
com.vidispine.xml.prefix

Also in 5.3, is is possible to change the log levels of components using configuration properties. The configuration properties used for this is:

loglevel. followed by the component name. (e.g. loglevel.com.vidispine.filemgmt.storagesupervisor)

New in version 5.4.4.

It is now also possible to override the com.vidispine.service.quorum system property using a configuration property as above.

While it is possible to change these values on a system in production, it is adviced that changing these values are done on an idle system, as the update in a cluster is asynchronous.

Bulky metadata storage

New in version 5.3.

By default, the values of bulky metadata are stored in the database. In a large system, this can occupy a large portion of the database. In version 5.3, there is the possibility to store bulky metadata on file system (or cloud storage).

To change the configuration the bulky metadata configuration resource is used. The configuration document contains two parameters, a base URI for where the bulky metadata should be stored, and an option to disable that storage. An explanation on how these to parameters interact follows below.

Transferring bulky metadata from database to file system

To move bulky metadata entries from database to the file system pointed out by the URI, use a configuration document like this:

NONE

PUT /configuration/bulkymetadata
Content-Type: application/xml

<BulkyMetadataConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <uri>file:///mnt/srv/bulkystorage/</uri>
</BulkyMetadataConfigurationDocument>

When this configuration is set, all bulky metadata is written to the file storage. Reading metadata is also done from file storage, but if the file storage does not contain the metadata, the database is read instead.

The path that is used to store the bulky metadata looks like this:

Item id, with the id split in thousands
Shape id, with the id split in thousands
Key, channel, stream, and timecode, delimited by -.

In order to migrate all metadata to the storage, a reindex command is used:

NONE

PUT /reindex/bulkymetadata

When the reindex process has finished, all metadata is on the storage. This can be verified by retrieving the bulky metadata configuration, which also returns status information.

NONE

GET /configuration/bulkymetadata
Accept: application/xml

<BulkyMetadataConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <uri>file:///mnt/srv/bulkystorage/</uri>
  <status>
    <metadataInDatabase>0</metadataInDatabase>
    <metadataOnStorage>45033</metadataOnStorage>
    <storageStatus>OK</storageStatus>
  </status>
</BulkyMetadataConfigurationDocument>

New in version 5.4.5: The bulky metadata migration can be parallelized by setting the bulkyMetadataMigrationThreads property.

Transferring bulky metadata from file system to database

To move bulky metadata entries back from the file system to database, use a configuration document like this:

NONE

PUT /configuration/bulkymetadata
Content-Type: application/xml

<BulkyMetadataConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <uri>file:///mnt/srv/bulkystorage/</uri>
  <storageDisabled>true</storageDisabled>
</BulkyMetadataConfigurationDocument>

Note the URI is still present, but the storageDisabled is set to true. It is vital that the URI remains set, and unchanged, as metadata will be read from the storage if it is not present in the database.

To migrate all metadata, use again:

NONE

PUT /reindex/bulkymetadata

NONE

GET /configuration/bulkymetadata
Accept: application/xml

<BulkyMetadataConfigurationDocument xmlns="http://xml.vidispine.com/schema/vidispine">
  <uri>file:///mnt/srv/bulkystorage/</uri>
  <storageDisabled>true</storageDisabled>
  <status>
    <metadataInDatabase>45033</metadataInDatabase>
    <metadataOnStorage>0</metadataOnStorage>
    <storageStatus>OK</storageStatus>
  </status>
</BulkyMetadataConfigurationDocument>

Once everything has been migrated, the URI can be removed from the configuration, if preferred.

Transferring bulky metadata from one storage to another

There are two ways of moving bulky metadata from one storage to another.

Move metadata from storage to database, ensure every metadata is moved, then move metadata to new storage.
Stop/pause Vidispine, copy or move files from the old storage to the new storage. Start Vidispine and change URI.

If the second option is chosen, tools like rsync or aws s3 sync can be used to do a first synchronization while the system is in use.

Important notes

The number of bulky metadata entries on storage returned by GET /configuration/bulky-metadata is based on database information, and not explicit file system scanning.

When the bulky metadata is moved from database to file system, note that database backups no longer contain the bulky metadata values. Make sure appropriate backup procedures is in place for the bulky metadata storage. Good tools are rsync and aws s3 sync (mentioned above) or incremental tar balls.

Before migrating bulky metadata, a full database backup is recommended.

Advanced configuration/tweaking

Methods in this section should only be used after recommendation by Vidispine Support.

SQL Query rewriting

New in version 5.0.6.

SQL queries sent by Vidispine can be modified by creating a file sqltranslations.txt in the /etc/vidispine/ directory. The format of the file are pairs of lines, where the first line of each pair is a regular expression, and the second line of the pair is a replace pattern, e.g.:

NONE

(?i)^(select .*)$
/* comment inserted */ $1
(?i)^(delete .*)$
/* another comment inserted */ $1