Available settings

These settings are those settings that are vital to Portal being setup successfully. Portal tries to provide sensible defaults.

The settings are read from the file portal.conf. This is a text file designed for the system administrator to use to configure an installation of Portal.

It can be located in two places. Firstly it checks in:

/etc/cantemo/portal/portal.conf

Failing that it will check in the directory Portal was invoked from. On a production site it should always read from /etc/cantemo/portal/portal.conf.

configs/ directory holds example configuration files.

[replace_urls]

A recommended setting is to set the location that thumbnails, videos and preview audio files will be served from.

It works as a URL replace mapping table, allowing you to specify that an internal resource be mapped to an external address, and this is needed for Portal installations and installations that use the NLE plugin such as the Adobe Premiere Pro CS6 integration. This is used for systems with an external interface

Warning

Colons (:) and equal signs (=) will need to be replaced with %3A and %3D respectively

Example:

http%3A//10.0.1.10%3A8080/: http%3A//gw1.cantemo.com%3A8080/

The second address should be the interface that clients or webbrowser normally connect to.

[logging]

Location of the where the log files should be stored:

LOG_CONFIG_FILE: /etc/cantemo/portal/logging.conf

[debug]

Turn on and off fancy debugging:

DEBUG: false

Turn on if debug is true for template debugging. You can log exceptions and other errors straight to the web page if this and DEBUG is set to true:

TEMPLATE_DEBUG: false

List of internal IP Addresses:

INTERNAL_IPS: 127.0.0.1

Serve up development files and media straight from the console, always set to false on a production system:

DEVELOPMENT_SYSTEM: false

[admins]

Lists of email addresses to be sent problems with Portal if any occur, each line should be a separate name and email address:

Example Name: example@example.com
Second Example: example2@example.com

[site]

Local time zone for this installation. Choices can be found here: http://en.wikipedia.org/wiki/List_of_tz_zones_by_name although not all choices may be available on all operating systems. If running in a Windows environment this must be set to the same as your system time zone. For more information on the formats of the date and time settings, please see https://django.readthedocs.io/en/1.4/topics/settings.html Also note that if internationalization is enabled in the license and configuration then the date and time settings are ignored and the locale specific settings are used instead.:

TIME_ZONE: Europe/Stockholm

Date time format for display in the system:

DATETIME_FORMAT: N j, Y, H:i

Short date format for display in the system:

SHORT_DATE_FORMAT: d/m/y

Date input format if the localization it turned off for input. Used by all input fields to work out the format of the date and time being put into the system:

DATE_INPUT_FORMATS:  %d/%m/%y, %m/%d/%Y, %Y-%m-%d

List of Datetime input formats used for parsing datetimes Use comma separated and unquoted:

DATETIME_INPUT_FORMATS: %Y-%m-%d %H:%M:%S, %Y-%m-%d %H:%M, %Y-%m-%d, %m/%d/%Y %H:%M:%S, %m/%d/%Y %H:%M, %m/%d/%Y, %m/%d/%y %H:%M:%S, %m/%d/%y %H:%M, %m/%d/%y, %Y-%m-%dT%H:%M:%S%f%z

Language code for this installation. All choices can be found here: http://www.i18nguy.com/unicode/language-identifiers.html and this will be the base language for the system which will of course get overridden by internationalization:

LANGUAGE_CODE: en

ID of the site, used in multi-site instances:

SITE_ID: 1

URL of this instance of the site:

SITE_URL: http://example.com

This is message that will get sent to pages when an error has occurred. Put in the number, email or name of the relevant person to contact:

SITE_HELP: Example administration staff - admin@example.com

URL prefix for admin media – CSS, JavaScript and images. Make sure to use a trailing slash. Examples: “http://example.com/media/”, “/admin/media/”.

ADMIN_MEDIA_PREFIX: /admin/media/

A URL which can be used in templates for serving Javascript from:

JAVASCRIPT_URL: http://localhost:8000/sitemedia/js/

Use internationalization on the system:

USE_I18N: True

Provide localized view of dates and times for users:

USE_L10N: True

URL that users are redirected to after login:

LOGIN_URL: /authentication/login/

You can override the url used for logout functionality in the Portal GUI. This can for example be used to redirect the user to a separate page after the have logged out, by using the next query parameter

LOGOUT_URL: /authentication/logout/?next=/my_plugin/custom_logout_view/

The default value for the LOGOUT_URL is:

LOGOUT_URL: /authentication/logout/

Define whether or not users have to be authenticated to use Portal, If false then use the credentials below. With third party systems it should always be set to true:

LOGIN_NEEDED: True

This is a string that contains the URL for the default redirect upon login to Portal. It sets this globally and also each user that is created gets this string as their default upon login

It should not be a complete URI - not contain any IP Address or hostname, but it does require a trailing slash.:

HOMEPAGE_LOGGED_IN: /vs/search/

Transcode shapes that will be selected by default when creating a new group, these should match transcode formats being setup for an installation:

DEFAULT_VIDEO_TRANSCODES: lowres
DEFAULT_AUDIO_TRANSCODES: lowaudio
DEFAULT_IMAGE_TRANSCODES: lowimage

This controls how portal behaves when the rules engine 3 plugin is enabled or disabled. If set to “true” then Portal will attempt to stop and/or start tomcat whenever the plugin is enabled and disabled. If set to “false” it will not try to control tomcat at all. Possible values are “true” and “false”. The installer will set this boolean at install time depending on the flags supplied.:

RE3_LOCAL: true

Whether to use secure session cookies. If this is set to True, the session cookies will be marked as “secure,” which means browsers may ensure that the cookies are only sent under an HTTPS connection.:

SECURE_COOKIES: false

A list of strings representing the host/domain names that this Portal site can serve. This is a security measure to prevent HTTP Host header attacks, which are possible even under many seemingly-safe web server configurations. Values in this list can be fully qualified names (e.g. ‘portal.example.com’), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port) or IP addresses (e.g ‘10.1.2.3’). A value beginning with a period can be used as a subdomain wildcard:

'.portal.com' will match portal.com, example.portal.com, and any other subdomain of portal.com.

A value of ‘*’ will match anything;:

ALLOWED_HOSTS: portal.example.com, 10.1.2.3

[homepage_choices]

This section did previously contain the list of landing pages the user can choose from in their preferences. As of Portal 2.1 this configuration is now available in the System Settings instead.

[reporting]

Defines the location that reports will be saved to, e.g. file:/home/vidispine/ or ftp://user:pass@localhost:21/:

REPORT_DESTINATION_URI: file%3A/tmp/

[thumbnails]

The width of the thumbnails to be shown in search results, collections and other pages:

THUMBNAIL_WIDTH: 242

The height for the thumbnails:

THUMBNAIL_HEIGHT: 136

Whether the thumbnails should be shown with automatic scrubbing:

THUMBNAIL_MOUSE_SCRUB: True

[media]

URL that handles the media served from MEDIA_ROOT. Make sure to use a trailing slash if there is a path component (optional in other cases). Examples: “http://media.example.com”, “http://example.com/media/”:

STATIC_URL: /sitemedia/

A string for where the preview media is held. Note that hostnames and domain names don’t need the trailing slash but paths do:

PREVIEW_URL: /sitemedia/

Defines the preview video format(s) available for browsing, created by the server. If multiple formats with the same mimetype are added to the PREVIEW_VIDEO_SHAPES list, the user will be able to select which one to view in the item page player:

PREVIEW_VIDEO_FORMAT: mp4, flv
PREVIEW_VIDEO_SHAPES: lowres

Defines the preview audio format(s) available for browsing, created by the server. Several formats can be defined by adding them on a comma separated:

PREVIEW_AUDIO_FORMAT: mp3, wav
PREVIEW_AUDIO_SHAPES: lowaudio

Defines the preview image format(s) available for browsing, created by the server. Several formats can be defined by adding them on a comma separated:

PREVIEW_IMAGE_SHAPES: lowimage

Defines the method used to fetch the preview file from the server. Several formats can be defined by adding them on a comma separated. Example: “http, ftp, file”:

PREVIEW_GET_METHOD: http

For defining how many hours before items that have been requested for deletion are actually purged you can set a grace period. Default is 24 hours:

DELETION_GRACE_PERIOD: 24

The DASH player can be enabled by setting DASH_ENABLED to true. Note that it only works for locally stored media:

DASH_ENABLED: True

When the dash player is enabled, you can select which video and audio shapes will be used with the settings DASH_VIDEO_SHAPES and DASH_AUDIO_SHAPES. The video shapes will be used when negotiating bandwidth, so you can create multiple proxy files and the player will automatically select the proxy with the highest bitrate the browser is able to download. Audio shapes will be used to allow the user to select different audio track, and can be used for example when the video material has audio tracks in different languages:

DASH_VIDEO_SHAPES: highres, lowres
DASH_AUDIO_SHAPES: english, german, swedish

You can control the grace period items are kept in the recycle bin by adjusting the DELETION_GRACE_PERIOD setting. This specifies the number of hours after the user deletes an asset before it is actually deleted from the system. The default is 24 hours:

DELETION_GRACE_PERIOD: 24

[paths]

Should be absolute paths with no trailing slashes to where on the file system the media is mounted. This is the image files, css, javascript and other files used to support the Portal installation:

MEDIA_ROOT: /opt/cantemo/portal/portal_media

[database]

Database settings take the following form, and should be setup in advance:

The user of the database:

DATABASE_USER: myDatabaseUser

The password for of the database:

DATABASE_PASSWORD: myDatabasePassword

The hostname of the database can be set to blank for localhost, a domain name or an IP address. If you are using sqlite3, you can use a path:

DATABASE_HOST: 10.0.0.1

The port for the Database:

DATABASE_PORT: 5432

The Database engine, ‘postgresql_psycopg2’

DATABASE_ENGINE: postgresql_psycopg2

The Database name:

DATABASE_NAME: example

The default number of results to show in a search:

DEFAULT_RESULTS_SHOWN: 15

[email]

Email address used for sending email from the site:

SENDING_EMAIL: noreply@example.com

Contact email for sending emails to about Portal:

CONTACT_EMAIL: example@example.com

SMTP host for relaying emails from Portal:

EMAIL_HOST: smtp.example.com

Username for logging on to the SMTP relay:

EMAIL_HOST_USER: noreply@example.com

Password for the user logging on to the SMTP relay:

EMAIL_HOST_PASSWORD: example

Port for the SMTP relay:

EMAIL_PORT: 587

Use TLS encryption with the SMTP relay (True or False):

EMAIL_USE_TLS: true

Require verification that email is sent:

REQUIRE_EMAIL_VERIFICATION: false

Email address that the recipient will see when sending email:

DEFAULT_FROM_EMAIL: noreply@example.com

A (optional) prefix that can be applied to all outgoing mail:

EMAIL_SUBJECT_PREFIX: DAM

Email address used for sending error messages from Portal to its administrators:

SERVER_EMAIL: noreply@example.com

[secrets]

secret keys that should be a random string of ASCII. PLEASE make sure that any % characters are changed to %% if you are auto generating the key:

SECRET_KEY: asdfghjkklpoiuytrewzxcvbnm
CSRF_MIDDLEWARE_SECRET: sdfghjktyuioiweury

[enable_extras]

This will enable extra features on the site

USE_AUTH enables authentication on the site:

USE_AUTH: True

AUTHENTICATION_BACKENDS configures the list of backend moduels used for authentication. Additional authentication plugins may be configured here. Note that the order is important as backends are tried in the order listed and excecution is stopped when a plugin which accepts the username and password is found:

AUTHENTICATION_BACKENDS: portal.vidispine.authentication.VidispineBackend, django.contrib.auth.backends.ModelBackend

UPLOADER_METHODS can configure which methods will be used on the uploader page and which order they should be tried. For example, to enable the html5 uploader, you can configure as follows:

UPLOADER_METHODS: html5, java

SEARCH_SUBSTRING allows you to change the default search behavior to always do substring searches. This means that if a metadata field contains “foobar” then a search for “ooba” will result in a match for that item. The default for this setting is False:

SEARCH_SUBSTRING: True

USERNAMES_CASE_INSENSITIVE changes the username matching on the login page to be case insensitive. This is useful if you populate Portal’s user database from an external source where usernames have mixed casing, such as Microsoft Active Directory. The default value for this setting is False:

USERNAMES_CASE_INSENSITIVE: True

VERSION_SUPPORT enables the version support in portal, allowing you to upload new versions of the media of an item:

VERSION_SUPPORT: True

COMMENTS_ENABLED enables comments in portal, allowing you to comment items. The default value for this setting is True:

COMMENTS_ENABLED: True

REQUIRE_METADATA_SCHEMA can be used to force a user to always associate a metadata schema with an item. This can be used in conjunction with required fields to force a user to always enter metadata required by the workflow. The default value for this setting is False:

REQUIRE_METADATA_SCHEMA: False

METADATA_KEY_SLUGIFY is used to slugify the keys for metadata. This can be set to false if you want to write the keys yourself.The default value for this setting is True:

METADATA_KEY_SLUGIFY = True

LICENSE_WARNING_DAYS lets the admin know when the Portal and/or Vidispine license is about to expire (in days). Once the LICENSE_WARNING_DAYS mark is reached, a warning will be presented on the healthcheck page and the admin will get notified via growl messages. The default value for this setting is 30 days:

LICENSE_WARNING_DAYS = 30

[display]

This is used to say which template to use if there are no themes set as default in the database. It should point to an HTML file that is under one of the template directories:

THEME_DEFAULT_NOTHEME: website/base_website.html

We automatically add the STATIC_URL as a prefix:

THEME_DEFAULT_CSS: css/base.css

Configure whether a user can change the theme they use:

THEME_USER_CHANGE: True

When loading themes from the database the file that gets used from the filesystem as a base:

THEME_EXTENDS: base.html

[user_settings]

To decide what fields to show in the user settings page:

DEFAULT_GROUP_USER_CHANGE: False
DEFAULT_INGEST_GROUP_USER_CHANGE: False
DEFAULT_SORT_LIST_EXCLUDES: originalWidth, originalHeight, originalAudioCodec, originalFormat, originalVideoCodec, user, durationSeconds, itemId, mediaType

[cache]

Enable or disable the cache backend:

USE_CACHE: False

What cache backend to use, see the documentation on cache backends for more details:

CACHE_BACKEND: locmem://

Standard timeout for caching pages:

CACHE_MIDDLEWARE_SECONDS: 5

Prefix to add to all cache keys. (Useful if you are sharing an backend cache with another system):

CACHE_MIDDLEWARE_KEY_PREFIX: portal

[session]

Set the age for when a users session should timeout, forcing users to log in again. The default is two weeks, and is specified in seconds:

SESSION_COOKIE_AGE: 1209600

Close the users session when they close their browser:

SESSION_EXPIRE_AT_BROWSER_CLOSE: False

The domain name used to store the cookie (useful when load balancing an environment):

CSRF_COOKIE_DOMAIN: portal

[celery]

Use the celery backend for delayed or periodic processing.

Process jobs directly without sending the task to a background process. This setting is mostly useful for debugging purposes:

CELERY_TASK_ALWAYS_EAGER: False

AMQP message queue resource // username:password / host : port /virtual host:

BROKER_URL:  amqp://portal:secret@localhost:5672/portal

The number of concurrent worker processes/threads/green threads, executing tasks. Default is the (number of cpus available / 2 + 1):

CELERY_WORKER_CONCURRENCY: number_of_cpus/2+1

From Portal 2.0 we ship with RabbitMQ and the default settings shouldn’t be changed unless the RabbitMQ setup has been changed

The number of celery workers dynamically scales depending on the load for each particular worker type. By default the maximum number of workers for a particular queue is number_of_cpus/2+1 but these settings can be changed via the following parameters:

CELERY_MINIMUM_WORKERS: 1
CELERY_MAXIMUM_WORKERS: number_of_cpus/2+1

If you are running flower on another host, for example if you are running in a containerized environment, then you will need to set the FLOWER_URL to the base url where flower is running:

FLOWER_URL: http://127.0.0.1:5555

[realtime]

Realtime is the section of the configuration that deals with realtime updates by using, websockets for modern browsers or fallback to other communication mediums for older browsers. This is an optional system.

It is enabled by:

REALTIME_ENABLED: True

The realtime system needs the realtime server live on a system, accessible to the browsers that will be using it. Either put this on a different port on the same system or on a different host with a different hostname. This should be then configured by detailing where the browser connects:

REALTIME_SERVER: http://ipaddress:port

An example could be: http://portal:8002 or http://realtime.portal either way you should never need to put a trailing slash.

To publish to this server we either use QMan or Portal so another URL is

used that is more complete:

REALTIME_URL:  http://ipaddress:port/web/publish

This should match the string above and needs the /web/publish string on the end. When publishing we use a secret key:

REALTIME_SECRET: asdfghjkl

Make sure this secret key is also configured when you are configuring the realtime system..

All the notifications that are received can either be sent to Portal or to QMan. It is recommended to always use QMan, and so you should point the notifications to the server running QMan:

NOTIFY_SERVER: 10.0.0.1

If QMan is running on the same machine as Portal, use an IP address, otherwise it is fine to use a hostname as long as it can be resolved by the Vidispine system that will be sending the notifications.

NOTIFY_SERVER_PORT: 8002

Lastly configure the port that notification server will be running on. If you are using Portal to receive notifications then use the same port that Portal will be listening to, otherwise configure it to the port that QMan will listen on.

Protocol used to send notifications:

NOTIFY_SERVER_PROTOCOL: http

Timeout and retries:

NOTIFY_SERVER_TIMEOUT = 5
NOTIFY_SERVER_RETRY = 3

Address used to publish notifications back to Portal. Should be the internal and if using multiple servers possibly loadbalanced configuration:

PORTAL_API_URL: http://portal:8001

Secret PORTAL API Key:

PORTAL_API_SECRET: 12345678

Vidispine settings

Settings for the Vidispine system. Always configure with a user that has _special_all access rights.

The user of the vidispine system:

VIDISPINE_USERNAME: example

The password of the vidispine system:

VIDISPINE_PASSWORD: examplepass

The URL to the vidispine system:

VIDISPINE_URL: http://example/

Port that the Vidispine system is running on:

VIDISPINE_PORT: 8080

The administrative group used by Vidispine:

VIDISPINE_ADMIN_USER_GROUP: _special_all

The roles needed for ingest rights:

VIDISPINE_INGEST_ROLES: _storage_write, _file_write, _import

Default method type used for accessing storage. Leave set to Auto unless you have been advised otherwise:

VIDISPINE_STORAGE_METHOD_TYPE: Auto

The depending on what version of the Vidispine, it is either $ or in newer system “value”:

JSON_VALUE_CONSTANT: value

Default number of results to be shown per page on things like the search results. This can be overridden by users:

DEFAULT_RESULTS_SHOWN: 15

The available options for number of hits per page:

DEFAULT_RESULTS_CHOICES: 15, 30, 45, 60, 100

The number maximum of hits to show per page. To override this setting please add a new “highest value” to the setting “DEFAULT_RESULTS_CHOICES”:

MAX_RESULT_CHOICE: max(DEFAULT_RESULTS_CHOICES)

Ignore roles in the GUI by creating a list like this:

IGNORE_ROLES: _transcoder, _new_role

Ignore Groups in the GUI by creating a list like this:

IGNORE_GROUPS: hiddengroup

Enable ingesting growing files (tailmode). This will configure vidispine to start creating the web proxy while the file is growing, and will cause the web player to add new material to the end of the playing file as it becomes available (only in Google chrome):

INGEST_GROWING: true

When ingesting a file already on a storage, the title is set to the filename. By setting INGEST_FROM_STORAGE_FILENAME_AS_TITLE to false this changes to set the title to the entire path to the file:

INGEST_FROM_STORAGE_FILENAME_AS_TITLE: true

Portal normally stores annotations and subclips with their absolute timecode, including any start timecode of the item. When integrating with third-party system it may be advisable to store timed metadata in Vidispine offset from 0 instead of the startTimecode of the original media. The setting VIDISPINE_TIMESPAN_BASE changes this behaviour. The only valid setting is “starttc” which stores timed metadata offset from zero.:

VIDISPINE_TIMESPAN_BASE: none|starttc

The wizard will update xmp fields it knows the type of to the appropriate data type in Portal. Setting UPDATE_XMP_METADATA_FIELDS to false will disable this behavior, if it is not wanted:

UPDATE_XMP_METADATA_FIELDS: true

Allowed VSAPI URLs

Vidispine’s REST API is by default available on port 8080 of the Portal server, unless blocked by firewall rules or other non-standard setup. In such cases, it can be convenient to proxy calls to the Vidispine API through Portal’s nginx webserver. This can be configured in the [vidispine_allowed_urls] section of the portal configuration file. This section contains a list of regular expressions matching URL patterns and http methods which should be allowed throug the /VSAPI namespace. These calls will be authenticated against the authentication mehtods configured in Portal, including token authentication, basic auth or session cookie authentication.

For example, the following settings will allow the user to do a GET on /API/version in vidispine via the portal URL /VSAPI/version:

[vidispine_allowed_urls]

/version = GET

The following will allow any method starting with P (that is, POST, PUT or PATCH) on any resource under /API/item:

[vidispine_allowed_urls]

/item/.* = P.*

Multiple expressions can be added on separate lines and the request is allowed if any of the listed expressions match:

[vidispine_allowed_urls]

/item/.* = P.*
/version = GET

Rename section (optional)

Create a section:

[replace_urls]

Filenames and URLs can sometimes point to the wrong place, or an internal resource name when you wish to use an external name. You can rename then URLs and point to new resources:

http%3A//192.168.1.2%3A8080/APInoauth/: http%3A//portal.com/APInoauth/

It is also allowed to not rename to anything:

http%3A//192.168.1.2%3A8080/APInoauth/:

Optional settings

These settings don’t need to be set or in the config file.

Rename the download to the original filename (plugins can still override this setting):

RENAME_DOWNLOAD: True

Do not rename the exported file to the original filename (plugins can still override this setting):

RENAME_EXPORT: False

Elastic Search settings

Settings related to Elastic Search server.

Create a section:

[elasticsearch]

The URL to the Elastic Search server:

ELASTICSEARCH_URL: http://elastic1.example.com:9200/ , http://elastic2.example.com:9200/

The url can also contain a username and password if you have enabled authentication in your Elastic Search cluster:

ELASTICSEARCH_URL: http://username:password@elastic1.example.com:9200/

For convenience, the username and password can also be configured in a separate configuration option, which will apply to all servers specified in ELASTICSEARCH_URL. If both the url and the separate options contain a username and password then the ones specified in the url take precedence:

ELASTICSEARCH_USERNAME: username
ELASTICSEARCH_PASSWORD: secret

Portal uses a connection pool internally when connecting to Elastic Search, and the ELASTICSEARCH_POOL_SIZE setting allows you to adjust the size of this connection pool:

ELASTICSEARCH_POOL_SIZE: 50

By default, portal will create a search index without any replicas. If you want to set up elastic search in a cluster mode, you can adjust the setting ELASTICSEARCH_REPLICAS to increase the number of nodes your search index is replicated to. Note that if you change this setting, you will have to recreate the portal search index for the setting to take effect.:

ELASTICSEARCH_REPLICAS: 0

Portal uses a plugin called analysis-morphology which provides grammatical searches for the English language. This plugin must be installed in the Elastic Search cluster in the default configuration. If you are unable to install this plugin in your cluster, you can disable this by setting the ELASTICSEARCH_USE_MORPHOLOGY setting:

ELASTICSEARCH_USE_MORPHOLOGY: False

Elastic Search AWS authentication

To authenticate against an Elastic Search instance in AWS, you can set ELASTICSEARCH_AWS_AUTH to True which will enable the specific authentication required by AWS. In this case, you also have to set ELASTICSEARCH_AWS_REGION to the region your Elastic Search cluster is deployed to:

ELASTICSEARCH_AWS_REGION: eu-central-1
ELASTICSEARCH_AWS_AUTH: True

If ELASTICSEARCH_USERNAME and ELASTICSEARCH_PASSWORD are set, then ACCESS_KEY and SECRET_KEY will be taken from these variables. If the settings are not set then Portal will use boto3 to configure the credentials, which will either use the credentials stored in your instance or IAM role configuration.

For more information on this, see http://boto3.readthedocs.io/en/latest/guide/configuration.html#configuring-credentials

StatsD settings

StatsD is a high-performance statistics gathering server. Portal includes the ability to to send statistics to statsd. To enable statsd, add a section [statsd] to and set the STATSD_HOST variable to the statsd server hostname. This will activate the statsd support in portal. Example:

STATSD_HOST: stats.example.com

STATSD_PREFIX allows you to set the prefix which will be prepended to all statistics sent to statsd. This allows you to distinguish between different portal installations on the same statsd system:

STATSD_PREFIX:  portal

Notifier settings

The notifier is responible for receiving notifications from Vidispine and aggregating them before relaying to Portal for indexing. The following settings can be configured for the notifier:

What is the externally visible hostname that should be registered for notifications in Vidispine. This can be used in an High-Availability setup to point to a proxy for example. Defaults to 127.0.0.1:

NOTIFIER_HOST: 127.0.0.1

What port should the notifier bind to. Defaults to port 5000:

NOTIFIER_PORT: 5000

If you need the notifier to listen to a different address than the address for incoming notifications registered in Vidispine then you can configure the address that the notifier binds to. The default is the same address as NOTIFIER_HOST:

NOTIFIER_BIND_ADDRESS: 127.0.0.1