Chapter 8. Running VST

This chapter consists of the following:

Starting and Stopping VST

Video Server Toolkit (VST) is normally started automatically when the VST server boots. In a development environment, you may choose to disable automatic startup and start it manually instead.

This section explains how to start VST in the following sections:

Note: For information on booting from a backup plex, see “Configuring for Booting From a Backup Plex” in Chapter 9.

Configuring VST to Start Automatically

By default, when VST is installed, it does not enable itself to be automatically started when the system boots. As superuser, you can configure VST to start automatically at boot time using chkconfig with the vtr option. The following enables automatic startup:

# chkconfig vtr on 

The following disables automatic startup:

# chkconfig vtr off 

Starting VST Manually

You must be root to start VST. Start VST with

# /usr/vtr/bin/vtrstart 
vtrstart: Starting video server

Note: The message is displayed only if the system has verbose logging enabled (chkconfig verbose on).

If VST is already running, vtrstart displays an error:

vtrstart: Video server is already running (use -f to force restart)

As indicated, to stop the VST instance currently running and start a new VST instance, add the -f option:

# /usr/vtr/bin/vtrstart -f 
vtrstart: Stopping video server
vtrstart: Starting video server

Stopping VST

Stop VST with

# /usr/vtr/bin/vtrstop 
vtrstart: Stopping video server

Setting Startup Options

When the VST daemon vtrd starts, it reads the configuration file /usr/vtr/config/vtrd.conf. The daemon vtrd is the VST server daemon that manages the VST server processes.

The default installation operates normally without any change to the startup options. However, you can change the startup options for vvtr, the VST server process, by editing /usr/vtr/config/vtrd.conf and adding them immediately after the program path, /usr/vtr/bin/vvtr.

Table 8-1 describes the startup options for vvtr.

Table 8-1. VST Server Process (vvtr) Startup Options



-l logopts

Sets the log options, which control the format of the messages written to the log. If this option is omitted, each message contains the severity code, a timestamp, the process ID, and the text of the message.

The following may be specified for this option:

-l l, do not include the severity code in each log message
-l t, do not include the time stamp in each log message
-l p, do not include the process ID in each log message


“VST Log Message Structure” for more information about log message format.


Specifies that VST should not run at high priority (p). If this option is omitted, VST runs at high real-time system priority to ensure no interruptions in video/audio input or output.

Include this option only at the direction of VST support personnel.

Checking VST Status

You can use vtrstat to check whether VST is running on the system. If VST is not running, vtrstat displays the following message:

# vtrstat 
Video server on <host> is stopped

If VST is running and responding to MVCP connections, vtrstat displays

Video server on <host> is running.

For additional VST status information displayed by vtrstat, see “Monitoring the System”.

Using the O2 Graphics Window

An optional graphics port is available on O2 workstation that allows you to see the outgoing video in the VST X window in the graphics display. This window is sized to display a 625/50 video frame with non-square pixels (720 x 576). If you are playing video with a smaller image size, the image is centered within the VST X window.

Note: If you are playing video with non-square pixels (CCIR601 timing), for example a 525/59.94 video frame, the aspect ratio in the graphics window is incorrect; pixels are square on the graphics display and VST does not rescale the image.

The graphics window is enabled by default on O2 workstation. To disable it, edit /usr/vtr/config/device-defaults/mvp and set to false.

If you wish to use the graphics port, you cannot start VST automatically at boot time. The vvtr X Window appears only when you use /usr/vtr/bin/vtrstart to start VST.

To disable automatic startup, enter this command;

# chkconfig vtr off 

Logging VST Events

The VST logging feature provides a mechanism for storing a text record of events that occur during operation of the system. The default logging configuration generally records only events that are generated by various error conditions, but you can enable additional logging to help track and trouble-shoot VST behavior.

This section explains

VST Log Message Structure

Each VST log message has the following format:

c  dd-hh:mm:ss.mmmmmm  pppp  <log message>


  • c is the severity code of the message

  • dd is the day of the month

  • hh:mm:ss.mmmmmm is a time stamp that indicates when the message was written

  • pppp is the process ID of the process that wrote the message to the log

  • log message is the actual text message

Table 8-2 shows the VST log severity levels and codes, which are listed in decreasing order of severity.

Table 8-2. Log Levels

Severity Level

Severity Code




Panic condition.



A condition that should be corrected immediately, such as a corrupted system file.



A critical condition that has system-wide impact, such as a hard device error; immediate action is required.



A problem that needs correcting, but does not require immediate action.



Possible problem, but could be a transient problem that corrects itself.



Condition that might require attention, but isn't an error condition.



Informational message.



Information message that normally is of use only to engineers for debugging; can be Debug1, Debug2, or Debug3, with Debug3 producing the most amount of debugging information.

The following is an example of a message that has a severity code of 2 (Debug2 severity level). The message was written on day 14 of the month at the time that is shown in the message, and the ID of the process that wrote the message is 8254:

2 14-22:23:50.316766  8254 mvcp/ninety9 <-- 100 VTR Ready

The following example shows a Notice-level message.

N 29-09:26:11.490919   3064 U1 Unit ERROR (err=22): Clip timecode type not know

The following example shows an Info-level message.

I 29-09:26:12.758644   3065 (littlered_1) Timecode input acquired tc=09:27:35.02 (offset=* -27000000)

The following example shows a Warning-level message.

W 28-14:06:56.807983  35339 U16(DIVO_DVC_2) Video input missing

Configuring Logging

Logging is configured by setting the value of the following controls in the system defaults file /usr/vtr/config/system-defaults/main:

  • vtr.main.log_level.file

  • vtr.main.log_level.syslog

For example, to enable increased logging by including the first level of debug events in the events that are logged to the server log, /usr/vtr/adm/logs/vtrlog, include the following control setting in the main system defaults file:

vtr.main.log_level.file 1

The value of the control is relative to the Info log event severity. Positive values enable more verbose logging (1 = Debug1, 2 = Debug2, ...); negative values disable all but the more severe events (-2 = Warning, -3 = Error, ...).

Managing Log Rollover

Log rollover is the practice of saving the current log file and restarting logging into an empty log file. Rollover avoids the problems of running out of disk space and of having a list of log messages too long to handle easily.

VST manages the vtrlog server log file. By default, the log file is saved and a new log file begun every night at 2:00 a.m. if the log file is at least 10 MB. The default number of log files retained on the system is ten.

The command rotatelogs is used to manage the log files and is executed by the system's cron job handler at the right time. Table 8-3 shows the list of available options.

Table 8-3. rotatelogs Command Options



Default Value


Log filename



Log file directory



Lists these options



Daemon to notify



Maximum number of backups retained on the server



Minimum log file size to trigger rollover

10 MB


Debug level


To change any defaults (such as the time of the rollover or the log size), the crontab entry of rotatelogs in the system must be edited (as root, using crontab -e). This entry was installed as part of the initial VST installation by an exitop.

For example, to retain the last 20 log files on a machine, the rotatelogs entry in crontab must look like:

1       2       *       *       *       /usr/vtr/bin/rotatelogs -m 20

The debug option is off by default. It can be turned on using the -D option. There is only one level of debugging information (on).

Monitoring the System

Once Video Server Toolkit (VST) is installed and running, you can monitor its operation using the tools mentioned in this chapter. Two tools, vtrstat and mcstat, work directly with VST. You can also use standard SGI IRIX tools to monitor various system resources.

This chapter describes how to monitor VST in the following sections:


vtrstat is a command-line tool that tells you:

  • Whether or not VST is running

  • Which units are open, if the -units option is used

  • Which media ports are available, if the -ports option is used

Example 8-1 shows an example output of vtrstat.

Example 8-1. vtrstat Output

vsta 7# /usr/vtr/bin/vtrstat -units 
Video server on vsta is running.

Unit  Owner        Port    Clip       Function Location
U1    louth        DIVO_0  d/REC12    STOP     01:04:30.05
U2    louth        DIVO_0  *          STOP     *
U3    louth        DIVO_1  d/rPOP     CUE      00:00:00.00
U4    louth        DIVO_1  d/rSEL     STOP     00:00:00.00
U5    louth        DIVO_1  d/REC01    STOP     01:04:30.06
U6    louth        DIVO_1  *          STOP     *
U7    louth        DIVO_0  d/rSEL     CUE      00:00:00.00
U8    louth        DIVO_0  d/rSTOK    STOP     00:03:30.01
U9    louth        DIVO_7  d/rJOR     CUE      00:00:00.00
U10   louth        DIVO_7  d/rSEL     STOP     00:00:00.00
U11   louth        DIVO_3  d/rPOP     CUE      00:00:00.00
U12   louth        DIVO_3  d/rSTOK    PLAY     00:03:02.29
U13   louth        DIVO_4  d/rSEL     CUE      00:00:00.00
U14   louth        DIVO_4  d/rSTOK    STOP     00:00:00.00
U15   louth        DIVO_5  d/rSEL     CUE      00:00:00.00
U16   louth        DIVO_5  d/rSTOK    STOP     00:03:30.01

vsta 8# /usr/vtr/bin/vtrstat -ports
Video server on vsta is running.

#  Port    Type    Description
1  DIVO_0  Video   SGI XT-DIVO Digital Video Option
2  DIVO_1  Video   SGI XT-DIVO Digital Video Option
3  DIVO_3  Video   SGI XT-DIVO Digital Video Option
4  DIVO_4  Video   SGI XT-DIVO Digital Video Option
5  DIVO_5  Video   SGI XT-DIVO Digital Video Option
6  DIVO_6  Video   SGI XT-DIVO Digital Video Option
7  DIVO_7  Video   SGI XT-DIVO Digital Video Option
8  dq_0    Deck    Diaquest Deck Control

A description of these functions can be found in the Video Server Toolkit Developer's Guide in Chapter 11, “Completing Common Tasks Using MVCP Commands.”


mcstat graphically displays the activity of all units that are currently open on a VST server. It is recommended that you install vst_eoe.sw.base and on the SGI workstation you are using to monitor the VST server and run mcstat on that workstation instead of the server.

Figure 8-1 shows an example of mcstat's output when VST is running. When VST is not running, mcstat exits.

Figure 8-1. mcstat Output

Figure 8-1 mcstat Output

mcstat displays a list of all the media ports supported by the VST server. For each port, it displays all the units that are opened on that port; each unit is on a separate line.

The unit display includes the name of the unit, the unit owner information, the name of the clip currently loaded on the unit, the last function executed by the unit (or the one currently executing), the current clip time code, and the status of the function.

IRIX Tools

SGI provides a collection of monitoring tools that can be used with VST, including

  • sar: system activity reporter; reports operating system activity

  • gr_osview: graphical system monitor; graphically displays real-time usage of certain system resources

  • osview, a text version of gr_osview

  • Performance Co-Pilot (PCP): serves as an interface for existing reporting tools, such as graphing performance data over time

Before exporting media data recorded by VST to IRIX tools, you must manipulate the data. For more information about exporting media data, see Video Server Toolkit Developer's Guide .

Using sar

sar, the System Activity Reporter, is an activity counter. The command line options allow you to specify the kinds of activities you want measured, such as disk utilization. To use sar, follow these steps:

  1. Enable sar using the following command:

    # chkconfig sar on

  2. Reboot your system.

    When your system reboots, the sar data collector starts.

  3. Specify the system activity you want sar to measure; for example, to measure disk utilization, use a command similar to the following:

    # sar -d 2 10

    The -d command-line option specifies the display of disk utilization. The numbers, 2 and 10, specify how often you want to take reports. In this example, 10 reports are taken every 2 seconds.

Note: For a complete list of sar command line options, see the sar(1M) man page.

The following is example output of sar.

vsta 100# sar -d 2 10

IRIX64 vsta 6.4 02121744 IP27    12/19/1997

11:15:10     device %busy  avque  r+w/s  blks/s    w/s wblks/s  avwait  avserv
dks2d1     8    1.0      3   12002      0       0     0.0    28.3
dks3d69    8    1.0      1   12257      0       0     0.0    53.3
dks0d1     8    5.4      7     120      7     120    49.3    11.3
dks1d1     0    0.0      0       0      0       0     0.0     0.0
dks0d2     0    0.0      0       0      0       0     0.0     0.0
dks1d2     0    0.0      0       0      0       0     0.0     0.0
dks0d3     0    0.0      0       0      0       0     0.0     0.0
dks1d3     0    0.0      0       0      0       0     0.0     0.0
dks0d4     0    0.0      0       0      0       0     0.0     0.0
dks1d4     0    0.0      0       0      0       0     0.0     0.0
dks0d5     0    0.0      0       0      0       0     0.0     0.0
dks1d5     0    0.0      0       0      0       0     0.0     0.0
dks0d6     0    0.0      0       0      0       0     0.0     0.0
dks1d6     0    0.0      0      16      0      16     0.0     0.0 

Using gr_osview

gr_osview provides a graphical display of system resources use. This display provides a real-time window into the overall operation of the system, as shown in Figure 8-2.

Figure 8-2. gr_osview

Figure 8-2 gr_osview

For more information about this utility, see its man page, gr_osview(1M)

Using osview

osview is a text version of gr_osview. The following show example output of osview:

Osview 2.1 : One Second Average   vcpqa2      10/02/98 09:30:25 #14    int=5s
 Load Average            4MB pages    0    vidintr        0
   1 Min      0.008      16MB pages   0    drop_add       0
   5 Min      0.000  System Activity     TCP
   15 Min     0.000    syscall      206    conns          0
 CPU 0 Usage           read           3    sndtotal       0
   %user       0.00    write          0    rcvtotal       0
   %sys        1.20    fork           0    sndbyte       38
   %intr       0.00    exec           0    rcvbyte        0
   %sxbrk      0.00    readch        45  UDP
   %idle      98.80    writech       78    ipackets       1
 CPU 1 Usage           iget           0    opackets       0
   %user       0.00  Block Devices         dropped        0
   %sys        0.60    lread          0    errors         0
   %intr       0.00    bread          0  IP
   %sxbrk      0.00    %rcache      0.0    ipackets       1
   %idle      99.40    lwrite         0    opackets       0
 Wait Ratio            bwrite     22.4K    forward        0
   %IO          0.0    wcancel        0    dropped        0
   %Swap        0.0    %wcache      0.0    errors         0
   %Physio      0.0    phread         0  NetIF[ef0]
 System Memory         phwrite        0    Ipackets       2
   Phys      512.0M *Swap                  Opackets       0
    kernel    26.7M *System VM             Ierrors        0
     heap      7.7M  Memory Faults         Oerrors        0
      stream  48.0K    vfault         0    collisions     0
     zones     7.7M    protection     0 *NetIF[lo0]
     ptbl      2.9M    demand         0  Scheduler
    fs ctl     9.8M    cw             0    runq           0
    fs data  105.9M    steal          0    swapq          0
     delwri       0    onswap         0    switch        65
    free     350.5M    oncache        0 *Large page stats
    userdata  19.2M    onfile         0 *Interrupts
    pgallocs      0    freed          0 *PathName Cache
 Node[0]               unmodswap      0 *Heap
     Totalmem505.1M    unmodfile      0 *EfsAct
     freemem 350.5M    iclean         0 *XfsAct
     64k page  1.6K *TLB Actions        *Getblk
     256k pages   0  Video              *Vnodes
exit 1MB pages    0    vidioctl       0 

Using Performance Co-Pilot (PCP)

Performance Co-Pilot (PCP) provides a suite of tools that co-operate to deliver distributed, integrated performance-monitoring and performance-management services across a spectrum of performance domains, as shown in Figure 8-3.

Figure 8-3. Performance Co-Pilot

Figure 8-3 Performance Co-Pilot

For more information about Performance Co-Pilot, see its man page, pcp(1M).