Media Indexer v3.8.1 ReadMe

Installation Requirements........................................................................................................................ 1
Limitations ............................................................................................................................................... 1
Fixed in Interplay Media Indexer v3.8.1.30621 ....................................................................................... 2
Important Information
Avid recommends that you read all the information in this ReadMe file thoroughly before installing or using
any new software release.
Installation Requirements
Patch v3.8.1.30621 contains full installers for PC and Mac. The installers have the following requirements:
This patch is recommended to be installed on all Media Indexer v3.6.x, v3.7.x, and v3.8.x servers and
clients. You can also run an MI v3.8.1 server with MI v3.7.x or v3.8.0clients.
The internal database schema version has not changed from MI version v3.8.0 to v3.8.1 except for the
ignored items schema. Media Indexer will *not* trigger a reindex of the configured storage locations
but start with empty ignored items list in the database. A reindex needs to be triggered manually in
case earlier ignored items need to be reevaluated immediately.
Updating from an MI v3.7.x or earlier version will cause a reindex. This can take time so plan
accordingly. For information on prebuilding the MI cache during an upgrade, see the Interplay Best
Practices Guide.
Uninstall the previous Media Indexer version before installing the new one.
Make sure that Visual Studio 2012 C++ Redistributables are installed on the machine (windows) as
these are required but not installed by the Media Indexer automatically.
The following limitations are present in this patch release:
Same limitations for Unicode character filenames apply as for other 3.x Media Indexer
versions. For example, the information is contained in the MI v3.7.1 Readme.
Fixed in Interplay Media Indexer v3.8.1.30621
IPMI-7733 - File System Changes on Mac Take Long to Detect
Media Indexer used a longer delay to scan the local mac file system for changes than expected
when the Mac OS version is El Capitan or newer. Thisproblem occurred because newer Mac OS
versions use different “magic numbers” to identify HFS/HFS+ file systems. As a consequence,
the file system was not detected properly and the default polling behavior with longer delays was
This has been improved so that Media Indexer logs out the magic number retrieved from the file
system. Also, the expected magic numbers are now configurable and the default contains three
possible magic numbers rather than the single one used previously.
With the fix in place, the file system on newer Mac OS versions is scanned at the smaller interval
as expected.
The magic numbers that are used to detect a local Mac HFS/HFS+ file system are configurable
static defaultHfsFTypes = new Integer[] {
new Integer(17),
new Integer(21),
new Integer(23)
The logging contains information about the configured or applied default list of HFS types as integer
values as well as the type that the OS API returns for the local path under question as hexadecimal
value. (17 decimal value is the same as 11 hexadecimal value or 17 == 0x11)
hfsFTypesList is: [17, 21, 23]
HFS Folder Monitor statfs.f_type for path: /Volumes/Data/Media is 0x11.
IPMI-7654 - Thread Safety
Media Indexer uses a no-op implementation internally when a stub that represents a remote end
of a Media Indexer connection (such as client MI to server MI) is not yet initialized or the
connection to the remote end is currently inactive. The change from no-op to active remote end
or vice versa is a potential concern for thread safety, as the status of the connection is shared
among multiple different threads.
The code areas around these concerns were identified and improved via lock-free mechanisms
so that the change from no-op to actual remote end and vice versa is considered thread-safe
IPMI-7566 - Avoid Restarting NOMI on Weight Change
Media Indexer restarted the NOMI by tearing down connectors for client-server and server-server
communication and rescreating them again whenever a change was made to the weight or group
name while the change was applied via the web UI configuration options.
The restart of the NOMI is unnecessary in cases where only the weight is changed. This was
fixed by avoiding a restart on weight changes. If the group name is changed, however, the
grouping has to be restarted. This improves stability on Media Indexer nodes forming a NOMI
group especially when just changing the weight.
IPMI-7504 - Disabling FI Events About Precomputes (Preparation)
Media Indexer's format independent (FI) event system sends events for changes to the indexed
data such as FORMATDESCRIPTOR_ADDED. In previous releases this also included events
about precomputes (e.g. rendered effects). Sending events for changes to precomputes is not
necessary since precomputes cannot be dynamically relinked nor can anyone register as a
listener for the precompute channel id in the classic event system of Media Indexer.
For optimizations, Media Indexer avoids sending FI events on precomputes by default. This
behavior can be reenabled by feature toggle, however.
Even though this improvement was made available, it will have no observable impact until
another aspect is taken care of that is tracked by IPMI-7734. IPMI-7734 will be included in a
future release. This means that FI Events for precompute media are actually sent.
The configuration of this aspect can be adapted in jini.config found in the installation folder
static sendEventsForPrecomputesEnabled = Boolean.FALSE;
IPMI-7503, IPI-1714 - Reusing JMS Producers for Events
Media Indexer used a single connection and session in some scenarios but none of the
scenarios was reusing producers. This impacted sending messages as each time a producer
was created and had to be announced with the broker. If the broker was part of a NOMI (network
of brokers) that announcement appears to be more impactful than in case of a single node
NOMI. This could lead to the situation that adding another producer took a very long time or
never finished and as such no more messages were sent. In consequence, NOMI nodes did not
see other NOMI nodes anymore and each of them found itself to be master. Also, no more
responses to requests could be sent back so that clients had the impression that MI was hung.
This problem was improved by introducing connection pooling that also will pool
producers.Connection pooling will lessen the burden of recreating producers in a network of
brokers. As a result, message sending from the MI side should no longer result in a hang due to
the protocol of producer creation in the networked broker setup.
The connection pools in use can be configured in the file found in the
installation folder AvidMI/state/condfig/
# number of pooled connections for AMQ pooled connection factory
# number of pooled sessions for each connection of AMQ pooled connection
IPMI-7502 - Enhancing Cleanup of Ignored Items
Instead of moving files that fail indexing into a quarantining folder, Media Indexer keeps track of
files failing indexing in a special area in the mongo database. There were certain scenarios that
the entries in the ignored items collection of that database did not get cleaned up, for example,
when a workspace was removed from the MI configuration. This and other scenarios have been
IPMI-7501 – Fix to Correctly Handle Remote Service Stubs when the Remote End of a
Connection is Inactive or the Connection is Not Established
Media Indexer uses a No-Operation Stub for remotely connected Media Indexer endpoints when
the connection is disabled or not yet initialized. This stub did not properly handle all possible
cases for all available endpoints in a defined manner. This has been fixed and the logging and
automatic testing capability around this has been enhanced.
IPMI-7473 – Fix to Correctly Decode URL Network Locator in Indexed AMA Metadata Files
Media Indexer did not correctly decode URL-Encoded Network Locators, especially in AMA
Metadata files. This has been fixed.
IPMI-7335 – Parameterize Network Interface to Join On
Media Indexer Servers use Multicast for finding each other in a NOMI group. With Multicast and
multiple network interfaces, it can be important to define which network interface will be used to
publish and receive multicast requests. By default Media Indexer uses a certain semantic to
define which network interface to use.
With this change implemented, Media Indexer logs out which network interfaces are available
and which is selected for the multicast discovery when starting to join the NOMI group.
This logging should help to investigate if the network interface chosen by default is matching the
expectations depending on the network and routing context.
Additionally with this feature it is possible to manually define which network interface to use. Note
that this requires manual configuration and a restart of the Media Indexer service and depends
on the network stack.
While the default configuration attempts for a best effort, in some configurations it might be
necessary to manually specify the network adapter to use.
The configuration options for this aspect are covered in the file in
joinNetworkInterface argument could be applied in the following way:
1) no joinNetworkInterface (AMQ will choise by itself)
2) joinNetworkInterface=default (default value will be resolved into network
interface name using local ip address)
3) joinNetworkInterface=name (name is the network interface name
e.g. joinNetworkInterface=eth3. Available network interface names could be
found in logs during MI startup)
Example log output for the log out of available network interfaces is shown below.
Available network interfaces: [name:lo (Software Loopback Interface 1), name:net0
(WAN Miniport (SSTP)), name:net1 (WAN Miniport (L2TP)), name:net2 (WAN Miniport
(PPTP)), name:ppp0 (WAN Miniport (PPPOE)), name:eth0 (WAN Miniport (IPv6)),
name:eth1 (WAN Miniport (Network Monitor)), name:eth2 (WAN Miniport (IP)),
name:ppp1 (RAS Async Adapter), name:net3 (WAN Miniport (IKEv2)), name:eth3
(Intel(R) PRO/1000 PT Dual Port Server Adapter), name:net4 (Microsoft ISATAP
Adapter), name:eth4 (Intel(R) 82567LM-4 Gigabit Network Connection), name:net5
(Microsoft ISATAP Adapter #2), name:eth5 (Intel(R) 82574L Gigabit Network
Connection), name:net6 (Microsoft ISATAP Adapter #3), name:eth6 (Intel(R) PRO/1000
PT Dual Port Server Adapter #2), name:net7 (Microsoft ISATAP Adapter #4), name:net8
(Teredo Tunneling Pseudo-Interface), name:eth7 (Intel(R) PRO/1000 PT Dual Port
Server Adapter #2-QoS Packet Scheduler-0000), name:eth8 (Intel(R) PRO/1000 PT Dual
Port Server Adapter #2-WFP LightWeight Filter-0000), name:eth9 (WAN Miniport
(Network Monitor)-QoS Packet Scheduler-0000), name:eth10 (WAN Miniport (IP)-QoS
Packet Scheduler-0000), name:eth11 (WAN Miniport (IPv6)-QoS Packet Scheduler-0000)]
Example log output for the chosen network interface follows here.
Processing discoveryUri: multicast://default?group=MINOMI&joinNetworkInterface=default for NOMI DiscoveryNetworkConnector
The following arguments will be processed: [group=MI-NOMI,
joinNetworkInterface=default in discovery URI. So it will be determined
The following joinNetworkInterface will be used: name:eth6 (Intel(R) PRO/1000 PT
Dual Port Server Adapter #2)
Setting processed discoveryUri: multicast://default?group=MINOMI&joinNetworkInterface=eth6 for NOMI DiscoveryNetworkConnector