This chapter consists of the following topics:
If properly configured, the Video Server Technology (VST) software is normally started automatically when the server boots.
This section explains how to manage VST in the following sections:
-
Note: For information on booting from a backup plex, see “Configuring to Boot From a Backup Plex ” in Chapter 8.
By default, VST is configured to autostart when the system boots. As superuser, you can control the autostart of VST at boot time using the chkconfig command with the vtr option. The following enables automatic startup:
# chkconfig vtr on |
The following disables automatic startup:
# chkconfig vtr off |
You must be root to start VST. Start VST with the following command:
# /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 |
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 parent 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 the /usr/vtr/config/vtrd.conf file and adding them immediately after the program path, /usr/vtr/bin/vvtr. See the vvtr(1) man page for a description of the startup options.
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 the following:
Video server on <host> is running. |
For additional VST status information displayed by vtrstat, see “Monitoring the System”.
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 troubleshoot VST behavior.
This section explains the following:
Each VST log message has the following format:
c dd-hh:mm:ss.mmmmmm pppp log_message |
The fields represent the following:
| c | Severity code of the message | |
| dd | Day of the month | |
| hh:mm:ss.mmmmmm | Time stamp that indicates when the message was written | |
| pppp | Process ID of the process that wrote the message to the log | |
| log_message | Actual text message |
Table 4-1 shows the VST logging le vels and security codes, which are listed in decreasing order of severity.
Severity | Severity Code | Logging Level | Description |
|---|---|---|---|
P | –6 | Panic condition. | |
A | –5 | A condition that should be corrected immediately, such as a corrupted system file. | |
C | –4 | A critical condition that has system-wide impact, such as a hard device error; immediate action is required. | |
E | –3 | A problem that needs correcting, but does not require immediate action. | |
W | –2 | Possible problem, but could be a transient problem that corrects itself. | |
N | –1 | Condition that might require attention, but is not an error condition. | |
I | 0 | Informational message. | |
n | n | Information message that normally is of use only to engineers for debugging; can be Debug1, Debug2, or Debug3, where Debug3 produces the greatest 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 known |
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 08-12:12:25.910495 1364 No media devices detected by "dq" module |
Logging is configured by setting the value of the following control in the system defaults file /usr/vtr/config/system-defaults/main:
vtr.main.log_level.file |
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. As shown in Table 4-1, positive values enable more verbose logging (1 = Debug1, 2 = Debug2, ...); negative values disable all but the more severe events (–2 = Warning, –3 = Error, and so on).
 | Caution: Level 2 and above create very large files that can adversely affect system performance and should only be used for troubleshooting. Using the MVCP SET command to set the log verbosity allows you to effect the change without a VST restart. |
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 10.
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 4-2 shows the list of available options.
Table 4-2. rotatelogs Command Options
Option | Description | Default Value |
|---|---|---|
–b | Log filename | vtrlog |
–c | Log file compression |
|
–d | Log file directory | /var/adm/vtr/logs |
–h | Command options |
|
–l | Daemon to notify | vtrd |
–m | Maximum number of backups retained on the server | 10 |
–s | Minimum log file size to trigger rollover | 10 MB |
–D | Debug level | Off |
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).
For example, to retain the last 20 log files on a machine, the rotatelogs entry in crontab must look like the following:
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).
Once 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. This section describes how to monitor VST in the following subsections:
-
Note: The tool mcstat is part of SGI Media Server control GUI, which you can use for non-production, developmental activities. The control GUI is described in Appendix A, “The SGI Media Server Control GUIs”.
The tool vtrstat is a command-line tool that does the following:
Indicates whether or not VST is running.
Indicates which units are open if the -units option is used.
Indicates which media ports are available if the -ports option is used.
Example 4-1 shows an example output of vtrstat.
vsta 7# /usr/vtr/bin/vtrstat -units Unit Owner Port Function Status Location Clip ----------------------------------------------------------------------- U1 mcpanel/vst12 MFCODEC_2 PLAY RUN 16:42:39:20 dvctod U2 mcpanel/vst12 MFCODEC_3 STOP DONE 15:11:27:14 test1 U3 mcpanel/vst12 MFCODEC_10 STOP DONE 15:12:29:19 test50 U4 mcpanel/vst12 MFCODEC_8 STOP DONE 15:15:30:11 apr9/I U5 mcpanel/vst12 MFCODEC_5 STOP DONE 16:44:46:09 dvctod vst12 8# /usr/vtr/bin/vtrstat -ports # Port Type Description ---------------------------------------------------------- 1 MFCODEC_0 Video WHITEHOUSE OVAL OFFICE 2 MFCODEC_1 Video 1ST AND MAIN, E/W 3 MFCODEC_2 Video 2ND AND BROADWAY, N/S |
A description of these functions can be found in Chapter 9, “Introduction to MVCP”.
You can also use the following standard SGI IRIX tools to monitor various system resources: