previous next

Chapter 16: Access and Error Logs

This chapter explains how Helix Universal Server records information about client connections and other events. Using the log files, you can compile reports about system activity, gathering the statistical information you need.

Tip: If you're interested in designing custom reports to track specific activities on Helix Universal Server, refer to Chapter 17.

Understanding Log Files

Helix Universal Server maintains an access log that includes statistics about client connections. It keeps another log of error and informational messages about Helix Universal Server operation. The log files are text files that you can open with any text editor, or parse with a script or application. As accesses or errors occur, Helix Universal Server appends information to the end of the appropriate log file. The following sections introduce you to the log files and their features.

Access Log

The access log records information about requests by RealNetworks media players, Windows Media Player, and QuickTime Player, as well as browser requests for Helix Administrator pages. Using these logs, you can find out what clips were played, the times when media players connected, and so on. This information can help you determine which clips are most popular, for example.

The default access log is rmaccess.log, which is located in the Logs subdirectory of the main Helix Universal Server installation directory. However, information about which authenticated files have been accessed is stored in reglog.txt and accesslog.txt, which are described in "Logs Directory". Requests for streams that will be cached are stored in the cached requests log.

Logged Information

Helix Universal Server provides six logging styles that determine the amount of information gathered on each access attempt. In general, each style builds on the preceding style, adding more information. For instance, logging style 0 gathers the least amount of information. Logging style 1 includes the style 0 information, and adds more information, and so forth. You choose just one logging style for the entire log.

For More Information: The section "Access Log File Format" explains the logging styles and information fields.

Media Player Statistics

All logging styles can record statistics about a media player's playback experience. These statistics let you learn how many media packets were dropped, for instance, or whether the viewer paused the clip. There are four types of client statistics. You can use any combination of these statistics types, up to all four. Or, you can turn off client statistics gathering entirely. As well, users may choose not to report statistics.

For More Information: See "Client Statistics".

Error Log

The error log contains information and error messages about Helix Universal Server operation. By looking for patterns of errors, you can troubleshoot and correct possible problems on your site. The default file name is rmerror.log, and the file is generated in the Logs subdirectory of the main Helix Universal Server installation directory. Helix Universal Server records an entry in this log only when an error occurs. Until an error happens, the file does not exist. The error log uses the following syntax:

***date time servername(process_ID): error_message

The following table explains these fields in the error log file.

Error Log Fields
Entry Meaning
*** Three asterisks indicate an error. Informational messages are not preceded by asterisks.
date Date on which the error occurred, given in the form dd-Mmm-YY, as in 26-Apr-02.
time Time the error occurred on the Helix Universal Server clock, given in the form HH:MM:SS.xyz, as in 21:05:10.614.
servername(process_ID) Helix Universal Server name, followed by the process ID in parentheses.
error_message Text of the message.

Note: If you receive a message that refers to a fatal error, contact the RealNetworks Technical Support Department for assistance.

Log File Rolling

The access and error log files can grow indefinitely as they accumulate data. To keep log files manageable, you can limit a log file to a specific size. With the access log, you can also create a new log at a preset interval, such as every six hours or two weeks, depending on the amount of data you expect to log. Helix Universal Server begins, or rolls, a new log file when the limit is reached. Rolled log files are named with the following format:

file_name.log.timestamp

The name and extension are set through Helix Administrator, as described in "Customizing the Access and Error Logs". The timestamp has the following format, using a 24-hour clock:

YYYYMMDDHHMMSS

For example, the following file was created on June 22, 2002, at 1:49.53 P.M:

rmaccess.log.20020622134953

Access Log Used with Other Features

The following sections describe how information about various features appears in the access log file.

Helix Universal Proxy

If clips are proxied, the access log provides additional information about the connection. For more information, see "Proxied Clip Information".

Live Unicasting

Clients transmit data for live events at the conclusion of a broadcast. Entries will not appear in the access log until the live event is over, or the user clicks Stop. As described in "GET Statements", the GET statement shows unicasted events starting with the live mount point (usually /broadcast/ or /encoder/). Statistics type 3, which show user actions such as fast forward and pause, are not available for live events.

SLTA

If you broadcast a prerecorded clip in an infinite loop using SLTA, and the client remains connected, no access record is created until the broadcast stops or the client halts.

Splitting

On transmitters, the access log does not show any records pertaining to the receiver connections. However, if the same event is transmitted to multiple Helix Universal Servers, records will be created in the transmitter's access log. On receivers, the access log contains records for each clip delivered, and shows the splitting mount point.

Back-Channel Multicasts

Clips that were broadcast using back-channel multicasts can be identified with the protocol statement, which will be either PNAM or RTSPM. The same clip delivered over unicast will show PNAT or RTSPT if the TCP transport was used, or PNA or RTSP if UDP was used. For more information, see "File Name and Protocol".

Scalable Multicasts

To prevent large, scalable multicasts from overwhelming Helix Universal Server when statistics are sent, collect statistics with a Web server designed to handle large numbers of HTTP posts simultaneously. See "Gathering Client Statistics" for instructions on configuring this feature.

Access Control and Authentication

The access log does not show whether access control rules are in use. Only clients with IP addresses approved by the access control rules, and that supplied the proper name and password (if required) are allowed to receive content. Authenticated content is identified by the /secure/ mount point in the path shown in the GET statement. For more information, see "GET Statements".

ISP Hosting

You can identify which on-demand files were served by the ISP hosting feature by comparing the file name in the GET statement to the /path/ value in the user list file.

Monitoring

The Server Monitor shows files that are being viewed presently, whereas the access log provides a historical report of files that have been served. All of the files that Server Monitor shows will appear in the access log when they finish playing.

Helix Administrator

The access log file shows all files served by Helix Universal Server, including all Helix Administrator pages. These appear in the GET statement and begin with admin. For more information, see "GET Statements".

When the logging style is 5, the end of each record gives a presentation ID. For Helix Administrator pages, this number associates the elements on a particular page. All of the images that go with each page also appear in the access log. All files served that are related to a particular page are numbered sequentially.

SMIL files

Each file in a SMIL presentation, including the SMIL file itself, generates a record in the access log. When the logging style is 5, all files have the same ID number. For example, the files presentation.smil, presentation.rt, presentation.rp, and presentation.rm all have the same number in the presentation_ID field, such as 432. If the SMIL file was requested through a URL that used Ramgen, an additional record is created for the Ramgen statement, and shows a different value for the presentation_ID field.

Ram Files

All of the files listed in a Ram file generate a record in the access log. Because Ram files may be served by a Web server, there may be no record created in the access log for the Ram file. When the logging style is 5, all of the files listed in a Ram file have the same presentation_ID number.

Access Log File Format

Helix Universal Server records each access request in a separate record written to a new line in the access log. Fields within a record are separated by spaces or by pipes (|). At least one record is created for every clip served. If the client requests a presentation that includes several clips, one record is created for each clip in the presentation. Two records are created for every proxied clip delivered by proxy pull-split or cache.

Logging Style

Helix Universal Server provides six logging styles, numbered 0 through 5. Styles 1 through 4 each include the information of lower logging styles. For example, style 3 collects the same information as styles 0, 1, and 2, as well as some additional information. The default is style 5, which adds a presentation_ID field to the information in style 2. The following sections describe which fields each logging style collects. The section "Access Log Fields" explains the information logged in each field.

Tip: Although square brackets in syntax typically indicate optional material, the square brackets shown in the following access log syntax actually appear in the access log records.

Note: In the following examples, client statistics are not logged, so each entry shows [UNKNOWN] where the statistics fields would be. If you collect client statistics, therefore, each log entry will contain additional information. For more information, see "Client Statistics".

Logging Style 0

Logging style 0 uses this format:

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_stats_results]

Here is an example of an actual log record, showing that 858,636 bytes of the requested clip were sent over RTSP:

207.188.7.125 - - [26/Jun/2002:10:31:44 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686] [UNKNOWN]

Logging Style 1

Logging style 1 follows this format:

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_stats_results] file_size file_time sent_time resends
failed_resends

The following sample log record shows the same information as logging style 0, but adds information on file size, clip timeline length, actual time streamed, and resent packages:

207.188.7.125 - - [26/Jun/2002:10:06:33 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686] [UNKNOWN]
926322 217205 1 0

Logging Style 2

This is the format for logging style 2, which is identical to style 1, except that it records a client ID, which may be a global ID or an ID set through a cookie:

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_ID] [client_stats_results] file_size file_time
sent_time resends failed_resends

Here is an example:

207.188.7.125 - - [26/Jun/2002:10:07:42 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[8e07b707-19b7-448b-96b6-96c90151f2a6] [UNKNOWN] 926322 217 205 1 0

Logging Style 3

Logging style 3 follows this format. It builds on style 2 by adding information about the streams and the Helix Universal Server that delivered the clip:

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_ID] [client_stats_results] file_size file_time
sent_time resends failed_resends [stream_components] [start_time] server_address

This example shows the server and stream information added to the end of the record:

207.188.7.125 - - [26/Jun/2002:10:09:09 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[8e07b707-19b7-448b-96b6-96c90151f2a6] [UNKNOWN] 926322 217 205 1 0
[1 1 0 0] [26/Jun/2002:10:05:14] 208.147.89.157

Logging Style 4

Logging style 4 adds information about the clip's average bit rate and number of packets sent:

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_ID] [client_stats_results] file_size file_time
sent_time resends failed_resends [stream_components] [start_time] server_address
average_bitrate packets_sent

Here is an example:

207.188.7.125 - - [26/Jun/2002:10:10:04 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[8e07b707-19b7-448b-96b6-96c90151f2a6] [UNKNOWN] 926322 217 205 1 0
[1 1 0 0] [26/Jun/2002:10:05:14] 208.147.89.157 34816 488

Logging Style 5

Logging style 5, which is the default style, does not build on the preceding styles. Instead, it copies style 2 and adds a presentation ID that helps you keep track of presentations that contain multiple clips:

IP_address - - [timestamp] "GET filename protocol/version" HTTP_status_code
bytes_sent [client_info] [client_ID] [client_stats_results] file_size file_time
sent_time resends failed_resends presentation_ID

The following is an example of a logging style 5 entry:

207.188.7.125 - - [26/Jun/2002:10:11:03 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[8e07b707-19b7-448b-96b6-96c90151f2a6] [UNKNOWN] 926322 217 205 1 0 124

Access Log Fields

The following table summarizes the various logging fields that may appear in an access record, and indicates which logging styles include the fields. The following sections describe the access log fields in detail.

Access Log Fields
Log Field Logging Styles Reference
IP_address 0, 1, 2, 3, 4, 5 click here
[timestamp] 0, 1, 2, 3, 4, 5 click here
"GET filename protocol/version" 0, 1, 2, 3, 4, 5 click here
HTTP_status_code 0, 1, 2, 3, 4, 5 click here
bytes_sent 0, 1, 2, 3, 4, 5 click here
[client_info] 0, 1, 2, 3, 4, 5 click here
[client_ID] 2, 3, 4, 5 click here
[client_stats_results] 1, 2, 3, 4, 5 click here
file_size 1, 2, 3, 4, 5 click here
file_time 1, 2, 3, 4, 5 click here
sent_time 1, 2, 3, 4, 5 click here
resends 1, 2, 3, 4, 5 click here
failed_resends 1, 2, 3, 4, 5 click here
[stream_components] 3, 4 click here
[start_time] 3, 4 click here
server_address 3, 4 click here
average_bitrate 4 click here
packets_sent 4 click here
presentation_ID 5 click here

IP Address

The IP_address field gives the IP address of client, such as 123.45.123.45. If media is being proxied to the client, the log displays the IP address of the proxy. For more information, see "Proxied Clip Information". Following the IP address are two hyphens for compatibility with standard Web server log formats.

Timestamp

The [timestamp] field indicates the time that the client accessed the file according to the Helix Universal Server clock. It uses the following format:

[dd/Mmm/yyyy:hh:mm:ss TZ]

Here, TZ is the time zone expressed as the number of hours relative to the Coordinated Universal Time (Greenwich, England). For example:

[26/Jun/2002:10:10:04 -0700]

File Name and Protocol

The "GET filename protocol/version" field lists the file name and path requested by the client. The path is everything in the URL after the port number. If the client requests a file that doesn't exist, UNKNOWN appears in place of the file name. Possible values for the application-layer protocol used to send the clip to the client are RTSP, PNA, MMS, and HTTP. In addition, a letter at the end of the string indicates which transport type was used:

(blank) UDP connection
T TCP connection
H HTTP connection
M Multicast

For example, RTSPT means that the clip was streamed using the RTSP protocol over a TCP connection. The version number indicates the edition of the protocol.

For More Information: See "GET Statements".

HTTP Status Code

The HTTP_status_code field holds a return code that uses the HTTP standard error codes. It usually returns 200.

Bytes Sent

The bytes_sent field records the number of bytes transferred to the client. If the media is being proxied to the client using proxy cache or pull splitting, the log displays this field in two records for each client connection, as described in "Proxied Clip Information".

Client Information

The [client_info] field describes the version and type of client being used.

RealNetworks Clients

For RealNetworks clients, [client_info] uses the following format:

[platform_version_client_type_distribution_language_CPU]

The following information is recorded:

platform Operating system client software runs on, such as WinNT, Mac, and so on.
version Operating system version number.
client Version number of the client software.
type Type of client software.
distribution Distribution code of the client software.
language Language setting in client software.
CPU Type of processor on which the client is running. If the processor does not have a hardware Floating Point Unit, the string no-FPU is appended to the end of the CPU field with no delimiter.

For example:

[WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]

Note: RealAudio Player 1 logs just two fields for [client_info]. They are platform and client.

Windows Media Player

For Windows Media Player, the [client_info] field records the player version like this:

[NSPlayer/7.1.0.3055]

QuickTime Player

For QuickTime Player, the client information records the player version and the operating system. For example:

[QTS (qtver=5.0.2;os=Windows NT 5.0)]

Unknown Clients

If client information can't be gathered because the request came from a client that chose not to send statistics, or from a browser requesting Helix Administrator pages, [UNKNOWN] appears in the [client_info] field.

Proxied Media

If media is proxied to the client, the log displays, at a minimum, the version and type of the proxied client. For media delivered by proxy pull splitting or cache, RealNetworks Broadcast Receiver or the Helix Universal Proxy version and type appear in an additional record. For example:

[linux-2.2-libc6-i586-server_RealProxy_9.0.2_RealNetworks]

For More Information: See "Proxied Clip Information".

Client Identifier

For [client_ID], the access log can record an identification number for each media player. This may be a globally unique ID. For RealNetworks clients, it may be an ID based on a cookie. The following sections explain the possible field entries. The default settings for Helix Universal Server and RealNetworks clients record a cookie-based ID for each client access attempt. Users can control whether IDs are transmitted and cookies are accepted, however. As well, you can disable the logging of GUIDs and the setting of cookies through Helix Universal Server regardless of client configurations.

For More Information: See "Modifying the Access Log" for instructions on turning off client ID logging.

Globally Unique Identifier (GUID) for RealNetworks Client

If a RealNetworks client is configured to send a globally unique ID, it does so. For privacy protection, however, RealOne Player is set by default not to send a GUID. Because sending a GUID rests solely at the discretion of each user, users must change their default GUID settings for their GUIDs to appear in the access logs. In RealOne Player, the user command for controlling GUID reporting is Tools>Preferences>Connection>Internet Settings.

For More Information: To review RealNetworks' Consumer Software Privacy Statement, see the Web page located at http://www.realnetworks.com/company/privacy/software. html

Cookie-Based IDs for RealNetworks Clients

If a RealNetworks client's GUID reporting is not enabled, Helix Universal Server logs an ID based on a client cookie, setting the cookie on the first client access. In subsequent access attempts, the client returns the ID set in the cookie. The cookie-based ID is in the same format as the GUID, and is unique to each Helix Universal Server that delivers content to that client. However, the same client returns a different ID to each Helix Universal Server it contacts.

Although cookies are enabled by default in RealNetworks clients, a user can elect not to accept them. In this case, Helix Universal Server records the ID value it attempted to set, but does not know that the cookie was refused. When the same client does not return a cookie-based ID on its next media request, Helix Universal Server sends another cookie, again recording the ID of a cookie that is rejected. This happens on each media request from that media player, resulting in multiple records that list different IDs because the same media player refused the cookie each time.

Note: In RealOne Player, the user command for controlling cookies is Tools>Preferences>Connection>Internet Settings.

Windows Media Player and QuickTime Player IDs

If Windows Media Player and QuickTime Player are configured to send their GUIDs, Helix Universal Server records those ID values. If the players do not send GUIDs, Helix Universal Server generates an ID for the log. In this case, the same media player may be identified by multiple IDs in the log. Windows Media Player and QuickTime Player do not support cookie-based IDs.

Unknown IDs

When Helix Universal Server can't gather an ID because the client does not support GUIDs or cookies (as with a browser requesting Helix Administrator pages), empty square brackets—[ ]—appear in the [client_ID] field. If GUID reporting is disabled on the server or media player side, and Helix Universal Server does not attempt to set a cookie-based ID, the [client_ID] field shows a series of zeroes instead of a unique client identifier:

00000000-0000-0000-0000-000000000000

Statistics Results

The [client_stats_results] field holds connection statistics sent by the client when it finishes playing a clip, as described in "Client Statistics". If the client blocks connection statistics, or the statistics cannot be collected, the field appears as [UNKNOWN].

File Information

The following fields hold information about the requested clip:

Resend Information

The resends field lists the number of packets successfully resent because of transmission errors. The failed_resends field gives the number of packets not successfully resent in time to correct transmission errors.

Stream Components

The field [stream_components] is recorded only for RealNetworks media players. It explains the type of material sent, indicated in the following pattern:

RealAudio_stream RealVideo_stream Event_stream Image_maps

A value of 1 indicates that the clip includes this type of stream. The value 0 indicates that it does not. Thus, a clip that includes RealVideo and RealAudio but no event streams or image maps would appear in the access log as this:

1 1 0 0

Start Time

The [start_time] field gives the timestamp of when the clip began to stream, according to the Helix Universal Server clock. It is identical in format to the timestamp at the beginning of each access record, but does not list the time difference from Coordinated Universal Time. Here is an example:

[26/Jun/2002:10:05:14]

Server Address

The server_address field lists the IP address of the Helix Universal Server that delivered the clip.

Average Bit Rate

The average_bitrate field lists the average bit rate of the clip in bits per second.

Packets Sent

The packets_sent field lists the total number of packets sent to the client.

Presentation ID

The presentation_ID field records a number used by all clips in the same SMIL or Ram presentation. SMIL files are also included in the log, and use the same number as their clips. For example, if the log entries for a SMIL file, a video clip, and a GIF image all list presentation ID 437, you can conclude that the SMIL presentation consisted of that video and image. Helix Universal Server assigns the IDs, which are recorded only with logging style 5, when it transmits the clips.

Proxied Clip Information

If clips are proxied, the access log provides additional information about the connection by creating two records for every clip delivered by proxy pull splitting or cache. Proxied clips delivered by passthrough are recorded in the access log with one record. The following table outlines proxy-specific data contained in the access log by the type of Helix Universal Proxy delivery, and the access log field.

Access Log Data for Proxied Clips
Proxy Delivery Access Log Record Access Log Field
IP_address bytes_sent [client_info]
live
pull-split
proxy control channel Helix Universal Proxy IP address 0 version and type of proxied client
proxy live data channel Helix Universal Proxy IP address number of bytes sent to proxy RealNetworks Broadcast Receiver
on-demand cache proxy control channel Helix Universal Proxy IP address 0 version and type of proxied client
proxy cache data channel Helix Universal Proxy IP address number of bytes sent to proxy version and type of proxy server
passthrough proxied client connection Helix Universal Proxy IP address number of bytes sent to proxy version and type of proxied client

Note: In the records demonstrating the control channel between Helix Universal Proxy and Helix Universal Server, bytes_sent is 0 (zero) because the actual data is sent on a separate data channel.

GET Statements

The GET statement within an access log record shows the path and file name of each file that Helix Universal Server served, as well as the protocol and protocol version used to stream or broadcast the file. The following sections show sample entries for GET statements used with different types of on- demand and live content.

For More Information: To see the GET statement in context, refer to "Logging Style".

On-Demand Content

The following table lists the formats in which each type of on-demand content is shown in the GET statements of the access log. For a SMIL presentation, a separate record is generated for the SMIL file and for each file in the presentation. When the logging style is set to 5, you can identify which files are in the same presentation through the numeric identifier at the end of each access record.

GET Statements for On-Demand Content
Feature Protocol Example Statement in Access Log
On-demand streamed content RTSP "GET presentation/presentation.rm RTSP/1.0"
PNA "GET presentation/presentation.rm PNA/10"
HTTP "GET presentation/presentation.rm PNH/10"
SMIL files (1 record for the SMIL file, one record for each file listed within the SMIL file) RTSP "GET presentation/presentation.smi""GET presentation/presentation.rt"
"GET presentation/presentation.rp"
"GET presentation/presentation.rm"
ISP hosting—account-based RTSP "GET ~schu/music.rm RTSP/1.0"
PNA "GET ~schu/music.rm PNA/10"
HTTP "GET ~schu/music.rm PNH/10"
ISP hosting—dedicated RTSP "GET s/sc/schu/music.rm RTSP/1.0"
PNA "GET s/sc/schu/music.rm PNA/10"
HTTP "GET s/sc/schu/music.rm PNH/10"
Helix Administrator activity HTTP "GET admin/index.html HTTP/1.0"
View source request (for on-demand and live clips) HTTP "GET viewsource/template.html HTTP/1.0"
Authenticated on-demand streamed content RTSP "GET secure/topsecret.rm RTSP/1.0"
PNA "GET secure/topsecret.rm PNA/10"
HTTP "GET secure/topsecret.rm PNA/10"

Live Broadcasts

The following table summarizes the format in which each type of live content is shown in the access log. For live streams from Helix Producer 9 and later, the broadcast mount point is typically broadcast/ or redundant/. For RealProducer G2 through 8.5, it is encoder/. For earlier encoders, it is live/. For Windows Media broadcasts, the mount point is typically wmtencoder/, and for QuickTime it is qtencoder/.

While most clips generate one access log record apiece, clips delivered over scalable multicasting generate two records for each client. One is for the .sdp file, and the other is for the live broadcast stream. However, if the user saves the .sdp file and connects by opening that file, rather than by clicking a link on a Web page, only the live broadcast stream generates a record. For more on scalable multicasting, see "Setting Up Scalable Multicasting".

Sample GET Statements for Live Content
Feature Protocol Example Statement in Access Log
Unicasted content, from Helix Producer 9 or later RTSP "GET broadcast/live.rm RTSP/1.0"
PNA "GET broadcast/live.rm PNA/10"
HTTP "GET broadcast/live.rm PNH/10"
Unicasted, redundant content RTSP "GET redundant/live.rm RTSP/1.0"
PNA "GET redundant/live.rm PNA/10"
HTTP "GET redundant/live.rm PNH/10"
Unicasted content, from RealProducer G2 through 8.5 RTSP "GET encoder/live.rm RTSP/1.0"
PNA "GET encoder/live.rm PNA/10"
HTTP "GET encoder/live.rm PNH/10"
Unicasted content, from pre-G2 encoding source RTSP "GET live/live.rm RTSP/1.0"
PNA "GET live/live.rm PNA/10"
HTTP "GET live/live.rm PNH/10"
SLTA content any same as live unicasted content
Authenticated live streamed content RTSP "GET secure/broadcast/live.rm RTSP/1.0"
PNA "GET secure/broadcast/live.rm RTSP/1.0"
HTTP "GET secure/broadcast/live.rm RTSP/1.0"
Push splitting—transmitter's access log RTSP No record is created.
PNA
Push splitting—receiver's access log RTSP "GET broadcast/Japan/broadcast/live.rm RTSP/1.0"
PNA "GET broadcast/Japan/broadcast/live.rm PNA/10"
Pull splitting—transmitter's access log RTSP No record is created.
PNA
Pull splitting—receiver's access log RTSP "GET broadcast/pull/Japan:2030/encoder/live.rm RTSP/1.0"
PNA "GET broadcast/pull/Japan:2030/encoder/live.rm PNA/10"
Multicasting—back-channel RTSP "GET encoder/live.rm RTSPM/1.0"
PNA "GET encoder/live.rm PNAM/10"
Multicasting—scalable (two records are usually created) HTTP and RTP "GET concert.rm.sdp HTTP/1.0"
"GET concert.rm RTP/2.0"

For More Information: Chapter 7 explains broadcast mount points.

Client Statistics

All logging styles can include client statistics, which are shown in the preceding sections as [client_stats_results]. There are four types of statistics, and the access log can record any combination of them. Each set of statistics is enclosed in square brackets, and begins with a prefix such as Stat1. If you log all four types of statistics, for example, the [client_stats_results] field looks like this:

[Stat1:statistics_1][Stat2:statistics_2][Stat3:statistics_3][Stat4:statistics_4]

Note that although other access log fields are separated by spaces, there is no space between the closing square bracket of one statistics type and the opening square bracket of the next statistics type. The following example shows logging style 5 (click here) collecting statistics type 1:

207.188.7.125 - - [26/Jun/2002:10:11:03 -0700] "GET real9video.rm RTSP/1.0"
200 858636 [WinNT_5.0_6.0.10.714_RealPlayer_RN92PD_en_686]
[00000000-0000-0000-0000-000000000000] [Stat1: 487 2 1 2 0
44_kbps_Stereo_Music_High_Response_-_RA8]
926322 217 205 1 0 124

The following sections describe the information gathered by each of the four statistics types. Statistics 1 and 2 report basic information about playback. Statistics 3 provides information about viewer actions. Statistics 4 reports advanced playback information from RealOne Player. The default logging setting gathers statistics 1 and 2. The following table lists the media players and versions that can send the various statistics types.

Media Players and Supported Client Statistics Types
Media Player Statistics 1 Statistics 2 Statistics 3 Statistics 4
RealPlayer 2 and lower yes no no no
RealPlayer 3 and higher yes yes no no
RealPlayer 5 and higher yes yes yes no
RealOne Player and higher yes yes yes yes
Windows Media Player limited limited yes no
QuickTime Player no no no no
any other RTP-based player no no no no

Note the following about client statistics:

Statistics Type 1

Statistics type 1 gathers basic information about the success of media clips received by the client. It also tells what codec the client used to decode the audio portion of the clip. For RealNetworks media players, these statistics apply only to a clip's audio stream. The fields are the following:

[Stat1: received out_of_order missing early late codec]

These fields provide the following information:

received Total number of packets received by the client.
out_of_order Number of packets received by the client out of order. These packets are reordered as the client plays the clip. This information is not recorded for Windows Media Player.
missing Number of packets that the client requested, but that did not arrive.
early Number of requested packets received early by the client. This information is not recorded for Windows Media Player.
late Number of packets received too late by the client. This information is not recorded for Windows Media Player.
codec For Windows Media Player, the names of the audio and video codecs used. For RealNetworks clients, the name of the audio codec used to encode the soundtrack. Possible values for RealNetworks players include:
sipr—RealAudio version 5 formats
dnet—RealAudio version 3 formats
28.8—RealAudio version 2, 28.8 format
lpcJ—RealAudio version 2, 14.4 format
cook—RealAudio version 6 format

Statistics Type 2

Statistics type 2 provides details about the success of clip delivery, giving information about bandwidth requests. Resent packets are described in detail. This statistics type identifies which transport type was used to make the connection, and which audio codec played the clip. For RealNetworks media players, these statistics apply only to a clip's audio stream. This set of statistics uses the following format:

[Stat2: bandwidth available highest lowest average requested received late 
rebuffering transport startup codec]

The fields provide the following information:

bandwidth Clip bandwidth in bits per second.
available Average bits per second available to the user while the clip was playing. This information is not recorded for Windows Media Player.
highest Highest time between the client resend packet request and the packet resend arrival, in milliseconds. This information is not recorded for Windows Media Player.
lowest Lowest time between the client resend packet request and the packet resend arrival, in milliseconds. This information is not recorded for Windows Media Player.
average Average time between the client resend packet request and the packet resend arrival, in milliseconds. This information is not recorded for Windows Media Player.
requested Number of resend packets requested by the client.
received Total number of resent packets received by the client.
late Number of resent packets received by the client too late.
rebuffering Rebuffering percentage for the clip.
transport Transport type for the connection. Values are:
0—UDP
1—TCP
2—IP Multicast
3—PNA over HTTP
startup Time after the media request that the client received the first clip data package, in milliseconds. The data may arrive before the clip starts playing.
codec For Windows Media Player, the names of the audio and video codecs used. For RealNetworks clients, the name of the audio codec used to encoded the soundtrack. Possible values include:
sipr—RealAudio version 5 formats
dnet—RealAudio version 3 formats
28.8—RealAudio version 2, 28.8 format
lpcJ—RealAudio version 2, 14.4 format
cook—RealAudio version 6 format

Statistics Type 3

Statistics type 3 provides detailed information about viewer action while playing clips, but not while receiving live broadcasts. It addresses advanced streaming features, notably ads and image maps. For example, you can find out when a viewer clicked on an image map or stopped the clip. Because each user may carry out several actions, the access log file may grow rapidly when you collect these statistics. Be sure to review the log file frequently, or set up log file rolling to keep the logs to a manageable size. This statistics type uses the following format:

[Stat3:timestamp|elapsed_time|action|;]

Records of activity are separated by a semicolon (;). Thus, the Stat3 record of a viewer pausing, resuming play, and watching to the clip's end looks like the following:

[Stat3:4360|2107|PAUSE|;8401|2107|RESUME|;12608|6321|STOP|;]

Timestamp

The initial timestamp field gives the time in milliseconds when the action occurred. It is relative to the connection time of the client. In the preceding example, the first timestamp is 4360, meaning the action occurred at 4.360 seconds after the client connected.

Elapsed Time

The elapsed_time field records how many milliseconds into the clip timeline that the action occurred. In the preceding example, the PAUSE action occurs at 2107, or 2.107 seconds into the clip timeline. Notice that the RESUME action also lists the same elapsed time because this action restarts the clip at the same point where it paused.

Action

The action field records one of several different actions such as STOP or PAUSE, as described below.

CLICK

Viewer clicked on the image map. Further information includes:

x-coord Horizontal coordinate of the click.
y-coord Vertical coordinate of the click.
action Action that occurred. This is one of the following:

PLAYER="
url"—The URL of a media link the viewer clicked.
URL="url"—The URL of a browser link the viewer clicked.
SEEK="destination"—The seek destination point, in milliseconds.

PAUSE

The viewer paused the client.

RESUME

Resume play after a pause, seek, or stop.

SEEK

The seek destination point, in milliseconds.

STOP

End of clip reached.

RECSTART

Media player began recording the clip.

RECEND

Media player stopped recording the clip.

Statistics Type 4

Sent only from RealOne Player, statistics type 4 gathers most of the same information included in statistics type 1 and type 2, adding packet and bandwidth information for each stream, including the visual tracks of video clips. Statistics type 4 uses the following format:

[Stat4:stream_number|mime_type|codec|received|lost|resent|average_bandwidth
|current_bandwidth|;...information for next stream...|transport turobplay duration
clip_end]

The following is an example type 4 log entry for a RealVideo Clip:

[Stat4:2 audio/x-pn-realaudio|44_kbps_Stereo_Music_High_Response_-_RA8
|44100|940|0|0|;video/x-pn-realvideo|N/A|180889|2918|0|0| 1 0|1|0| 90 2]

Note: If you turn on statistics type 4 as well as statistics type 1 or 2, RealOne Player reports only statistics type 4. Other media players, however, will report statistics type 1 or 2, but not statistics type 4.

Stream Number

The stream_number field indicates how many media streams the clip contains. A video clip might have two streams, for example, one for the audio track and one for the visual track. Following this, information for each stream is reported.

Stream Information

Helix Universal Server reports information for each stream. Information ends with a semicolon. For each stream, the following fields are reported:

mime_type MIME type, such as audio/x-pn-realaudio.
codec Codec used for the stream, such as 44_kbps_Stereo_Music_High_Response_-_RA8.
received Number of packets received.
lost Number of packets lost.
resent Number of packets resent.
average_bandwidth Average bandwidth over the course of clip playback in bits per second.
current_bandwidth The bandwidth in bits per second used when the statistics are reported.

Transport

The transport field indicates the transport protocol used for the connection. Values are:

0 IP Multicast
1 UDP
2 TCP
3 HTTP cloaked

TurboPlay

Three turboplay fields indicate the use and results of the RealOne Player TurboPlay feature. The three fields are separated by pipes, as shown here:

1|513234|1120

The following table lists the possible field values. Values for the second and third field vary depending on whether TurboPlay is on or off, as indicated in the first field.

TurboPlay Field Values
Field 1 Field 2 Field 3
0 (off) Reason TurboPlay is off:
1—User preference.
2—Available bandwidth below 256 Kbps.
3—SureStream in use.
4—Excess rebuffering.
5—Presentation not enabled for TurboPlay.
6—Server not enabled for TurboPlay.
7—Live presentation not supported.
0 (not used)
1 (on) Accelerated delivery rate in bits per second requested by TurboPlay. Average buffering time in milliseconds for start of playback, seeking, and so on.

Duration

The duration field gives the time in milliseconds between the initial client request and the first data packet received by the client.

Clip End

The clip_end field lists the reason the presentation ended. Possible values are:

0 end of presentation reached
1 stop command issued
2 reconnection required
3 redirection
PNR_n error code n occurred

Customizing the Access and Error Logs

The following sections explain how to modify the logging of access and error records. Logging is turned on by default. You may want to change certain default options, however.

Modifying the Access Log

The access log is preconfigured to gather basic client statistics for media player requests. You may want to change the logging style and client statistics types, as well as set up log file rolling.

To modify access logging:

  1. Click Logging & Monitoring>Access & Error Logging. Access logging fields are at the top of the page.
  2. For Logging Style, choose a number from 0 to 5. The default is 5. For information about the logging style, see "Logging Style".
  3. If you do not wish to collect client identifiers, choose Yes from the Disable Client GUIDs pull-down list. This eliminates the collection of client global identifiers, as well as cookie-based IDs. For more information, see "Client Identifier".
  4. The Domain Cookie ID pull-down list is set to Enabled by default. This means that Helix Universal Server attempts to set a cookie on each client. This cookie provides a client ID logged in place of a suppressed GUID when the client requests content. To disable cookie setting, select Disabled. For more information, see "Client Identifier".
  5. Tip: Cookie-based IDs are also disabled on Helix Universal Server if you choose Yes for Disable Client Guids.

  6. The Client Stats Interval setting determines the frequency in seconds that the client reports statistics. A value of 30, for example, means that the client sends statistics, and Helix Universal Server creates new log entry, every 30 seconds. If you set this to 0 (zero), the client sends statistics once when the presentation ends.
  7. In the Client Stats check boxes, select the types of client statistics that each media player reports. You can choose any combination of statistics, or deselect all boxes to gather no client statistics. The default settings are Type 1 and Type 2. For more information, see "Client Statistics".
  8. Tip: If you gather statistics type 3 or 4, the access log file size will grow rapidly. In this case, be sure to review the log file frequently, or use log file rolling.

  9. You can choose to create a new log file at certain intervals, as described in "Log File Rolling".
    1. To create a new log file at regular intervals, set the period through the Log Rolling Frequency pull-down lists. You can roll the log hourly, daily, weekly, or monthly.
    2. To limit the log file by size, type the maximum number of Megabytes in the Log Rolling Size box.
    3. Tip: Generally, you limit log files by frequency or size. You can select both methods, however, to create log files according to the first limit reached. For example, you can create a new log file whenever the preceding file reaches 10 Megabytes in size, or has recorded 3 days of activity, whichever comes first.

  10. The Access Log File field specifies the log file name and absolute path. The default path is the Logs subdirectory of the Helix Universal Server main directory. The default file name of the access log file is rmaccess.log.
  11. Note: If Access Log File is blank, Helix Universal Server records access information in a file named, rmaccess.log, located in the same directory as the Helix Universal Server executable file.

  12. Click Apply.

Modifying the Error Log

Using the error log requires no configuration. You may want to set up log file rolling, though, or specify a different location and name for the error log. For basic information on error log syntax, see "Error Log".

To modify the error log:

  1. Click Logging & Monitoring>Access & Error Logging. Error logging fields are at the bottom of the page.
  2. You can choose to generate a new error log file at certain intervals, as described in "Log File Rolling".
    1. To create a new log file at regular intervals, set the period through the Log Rolling Frequency pull-down lists. You can roll the log hourly, daily, weekly, or monthly.
    2. To limit the log file by size, type the maximum number of Megabytes in the Log Rolling Size box.
    3. Tip: Generally, you limit log files by frequency or size. You can select both methods, however, to create log files according to the first limit reached. For example, you can create a new log file whenever the preceding file reaches 10 Megabytes in size, or has recorded 3 days of activity, whichever comes first.

  3. The Error Log File field specifies the log file name and absolute path. The default path is the Logs subdirectory of the Helix Universal Server main directory. The default name of the error log file is rmerror.log.
  4. On Windows NT systems, you can send error messages to the Windows Event Viewer. For NT Event Log Filter, select the NT error level you want to assign to Helix Universal Server error messages.
  5. Click Apply.


RealNetworks, Inc. © 2002 RealNetworks, Inc. All rights reserved.
For more information, visit RealNetworks
Click here if the Table of Contents frame is not visible at the left side of your screen.
previous next