Click Here to Install Silverlight*
United StatesChange|All Microsoft Sites
Windows Media Player 9 Series
|Windows Media Worldwide

Logging Model for Windows Media Services

Abstract
Provides a technical overview of logging in Microsoft Windows Media Services. This article supplements what is covered in Windows Media Services Help and the Software Development Kit (SDK).

 

Huseyin Koyun
Microsoft Corporation
September 2007
 

Applies to:
   Microsoft® Windows Media® Services 9 Series or later
  

Contents


Introduction

For many companies, streaming media is a source of revenue. Their customers stream on-demand content and live broadcasts for a charge. These companies rely on logged information to determine not only if a customer viewed content, but how long and at what quality. Because of this need, the accuracy and reliability of logging has become very important.

As advertising in streaming media becomes more and more common, new logging information needs to be made available. Events, such as streaming advertisements and user activities on a player, have changed what Microsoft® Windows Media® Services has traditionally considered appropriate for logging, but are nonetheless important. Logging information provides statistics about computer power, network bandwidth, and so on. This is why Windows Media Services contains the important elements of a robust logging model that is much more powerful than Windows Media Services version 4.1.

This article provides a technical overview of logging in Windows Media Services 9 Series or later. The information in this article supplements what is covered in Windows Media Services Help and the (Software Development Kit) SDK.

This document assumes that you have a basic understanding of logging and that you are familiar with Windows Media Services concepts such as publishing point, unicast, broadcast, multicast, distribution, and cache/proxy.

Back to the top of this pageBack to Top


Why Do We Log and What Do We Log?

Logs are used for different reasons:
  • Advertisement model. Internet content providers (ICPs) use logs to bill advertisers based on the number of people that viewed advertisements and to record how long the advertisements were viewed.
  • Verification of streaming charges. ICPs are charged by Internet service providers (ISPs) for the amount of bandwidth they use and the amount of data they transfer to their clients. ICPs use their logs to verify what they were charged for by ISPs and to find out the network and streaming quality of the clients.
  • Pay-per-view. ICPs charge their customers for the content they viewed based on how many times or how long they viewed the content.
  • Statistics for decision making. Logs are also useful for collecting statistics to use for decision making. For example, c-max-bandwidth values are useful in determining if the client computers' network speeds are suitable for higher-quality content, which will require more network bandwidth.

ISPs and ICPs rely on the statistics from logged information to charge their corresponding customers, which is why accuracy and reliability of logging is very important. The improvements made in Windows Media Services ensure that Windows Media servers receive accurate, real-world logging data.

Logs contain different types of data:
  • Network-related. Data such as client Internet Protocol (IP) address, server IP address, and server Domain Name System (DNS).
  • Stream-related. Data such as the number of bytes and packets sent by a server and received by a client, the number of packets lost and recovered on the network, the total buffer time and buffer count, the streaming quality, and the average and maximum bandwidth.
  • Render-related. Data such as the length of time a client receives content, audio and video codecs (compressor and decompressor algorithms), and a timestamp (offset from the beginning of content in seconds).
  • Content-related. Data such as the content path, file name, and the role of the content (for example, advertisement).
  • Client-related. Data such as a client's CPU, operating system and version, language, player and version, and so on.
  • Server-related. Data such as a server's CPU use percentage and the number of clients connected when the log was received.

Logs that contain the following c-status codes are also very helpful in determining client status:
  • 210. Identifies temporary network problems and automatic client reconnections.
  • 401. Identifies unauthorized access to the Windows Media server. There are exceptions when the server does not generate a 401 code, such as with an IP-denial list. If a client's IP address is in the denial list of an enabled IP Authentication plug-in, the client is denied but there is no corresponding log entry.
  • 404. Identifies that the requested publishing point does not exist on the server. 404 codes are also good for link verification. If users click a link on a browser to access content, then this log entry shows that the link is incorrect on the home page and needs to be fixed.
  • 408. Identifies network outages, bandwidth problems, and bottlenecks.
  • 500. Identifies server internal errors, such as a connection to the encoder has stopped.

Back to the top of this pageBack to Top


Logging Overview

Log Formats Accepted by Windows Media Services

For backward compatibility, Windows Media Services supports all the Windows Media Player versions currently available. To connect to a Windows Media server, all versions of the Player earlier than Windows Media Player 9 Series use HTTP/1.0 or Microsoft Media Server (MMS) protocol; Windows Media Player 9 Series or later uses HTTP/1.1 and Real Time Streaming Protocol (RTSP). Depending on the Player version, logs are sent in different formats, such as text, binary, or Extensible Markup Language (XML).

ProtocolPlayer/DistributionLog type
HTTP/1.0
Versions of Windows Media Player earlier than Windows Media Player 9 Series

Server running Windows Media Services 9 Series or later streaming from a server running Windows Media Services 4.1
World Wide Web Consortium (W3C) standard space-delimited text log
MMS
Versions of Windows Media Player earlier than Windows Media Player 9 Series
Binary structure log
HTTP/1.1
Windows Media Player 9 Series or later

Distribution server running Windows Media Services 9 Series or later

Cache/proxy server running Windows Media Services 9 Series or later
XML structure log
RTSP
Windows Media Player 9 Series or later

Distribution server running Windows Media Services 9 Series or later

Cache/proxy server running Windows Media Services 9 Series or later
XML structure log

A server running Windows Media Services 9 Series or later can send logs to upstream servers for distribution and cache/proxy scenarios; these logs are also in XML format. When the Windows Media server sends a log to a server running Windows Media Services 4.1 in a distribution scenario, it sends the log in a format that the 4.1 server understands, which is an MMS binary or HTTP W3C standard space-delimited text log that contains 44 fields.

Types of Logs

Windows Media Services introduces four new log types. To accommodate new ways of delivering content to a client (for example, through Fast Cache or a cache/proxy server), new logging types were added to provide a more resolute description of what the user's experience was.

The different log types are divided into two categories: client logs and server logs. Client logs are further divided into three types: client render logs, client stream logs, and combination (or "legacy") logs. The server logs are divided into distribution logs and propagated cache/proxy logs.

Client Logs

Client logs are sent automatically by players that are based on the Windows Media Format SDK. For unicast streams, logs are sent to a Windows Media server. For multicast streams, logs are sent to an alternate log sever (typically a Web server). Additionally, a player rendering an .asx file that contains a LogURL tag will submit its client logs to the streaming server and to the URLs specified in the .asx or .wsx LogURL tags. (Versions of Windows Media Player 6.4 and earlier do not support LogURL tags defined in .asx files.) If a client is not based on the Windows Media Format SDK, but on an Advanced Systems Format (ASF) specification, then it is the Independent Software Vendor's (ISV's) responsibility to make sure clients send the proper logs for each scenario. Logging is one part of the quality tests that another provider's player application must pass to be Microsoft-certified.

There are two types of client logs: rendering (playing) and streaming (receiving). Traditionally, players have sent a combination of the two logs because they were receiving and playing content simultaneously. Starting with players based on the Windows Media Format 9 Series SDK, these logs are differentiated. Because of the Fast Cache feature, content is being delivered to a player at faster than real-time speeds. Therefore, a player may finish receiving the streamed content before it finishes rendering it. This is why there are two logs for the same session.

Client Render (Play) Logs

A client rendering log is the most typical type of log that a client will send to the server. Such logs are submitted to the server when the client ends the playback of content. For example, when the player transitions from any playing state (play, fast-forward, or rewind) to a nonplaying state (stop, pause, end of stream, and beginning of stream). The following table shows some possible combinations for a rendering log.

Current stateNext stateExplanation/actualLog
Play
Pause
 
Yes
Play
Stop
 
Yes
Play
Close
Stop
Yes
Play
Fast-forward
Play → stop → fast-forward
Yes
Play
Rewind
Play → stop → rewind
Yes
Play
Seek forward
Play → stop → play
Yes
Play
Seek backward
Play → stop → play
Yes
Play
End of stream
Stop
Yes
Play
Stream switch

(next, previous, first, last)
Play → stop → play
Yes
Fast forward
Pause

Yes
Fast forward
Stop

Yes
Fast forward
Close
Stop
Yes
Fast forward
Play
Fast-forward → stop → play
Yes
Fast forward
Rewind
Fast-forward → stop → rewind
Yes
Fast forward
Seek forward
Fast-forward → stop → fast-forward
Yes
Fast forward
Seek backward
Fast-forward → stop → fast-forward
Yes
Fast forward
End of stream
Stop
Yes
Fast forward
Stream switch

(next, previous, first, last)
Fast-forward → stop → fast-forward
Yes
Rewind
Pause

Yes
Rewind
Stop

Yes
Rewind
Close
Stop
Yes
Rewind
Fast-forward
Rewind → stop → fast-forward
Yes
Rewind
Play
Rewind → stop → play
Yes
Rewind
Seek forward
Rewind → stop → rewind
Yes
Rewind
Seek backward
Rewind → stop → rewind
Yes
Rewind
Beginning of stream
Stop
Yes
Rewind
Stream switch

(next, previous, first, last)
Rewind → stop → rewind
Yes
Pause
Pause

No
Pause
Stop

No
Pause
Close

No
Pause
Seek backward

No
Pause
Seek forward

No
Stop
Stop

No
Stop
Close

No

Only one of these logs is submitted to the server when the player transitions from a playing to a nonplaying state. If a user hits pause three times (play → pause, play → pause, play → pause) followed by stop, four client render logs are sent, one for each play → pause transition and one for the play → stop transition. Seeking to a different point in the on-demand content also causes a log entry.

Windows Media Player 9 Series or later will submit a client render log if the content is cached. This means that the content was stored into a temporary local cache file on the computer running Windows Media Player. A player that reads a file from its local cache will submit a client render log to indicate that it has played the content. This type of log contains the following special attributes:
  • No network statistics because the content is playing back from the cache.
  • Network protocol is "Cache."

When a client render log is submitted, a connection is made upstream to the origin server (or a configured proxy server). The log is then submitted. If a connection is not available, then the player does not send a log; however, the player can render the content until it expires.

Client Stream (Receive) Logs

Windows Media Services enables content to be cached on the client side (by using the Microsoft Internet Explorer cache). This is a byproduct of the Fast Cache feature. This feature must be enabled on the server running Windows Media Services to enable clients to cache on-demand content; it is enabled by default. Content is streamed to the client and stored in a client-side cache file. The client then reads the content from the cache file. When content is streamed into a client's cache, the result is actually two logs: a typical client rendering log, and a client stream log.

The client stream log indicates how the client received the data, but not how it was rendered. This particular log is just like a client render log except that the values represent how the client received data. Therefore, the client may send the stream log long before the client actually finishes rendering the content.

For a playlist, the Fast Cache feature will cache only the missing items, not all of the items. After caching the requested on-demand content, if the user has less than 100 megabytes (MB) of free disk space, the client will not cache it and will only stream and render (play) content simultaneously like previous players. If the cached content is expired, the client will recache the content from the server.

An ICP can use this log to determine how much content was actually streamed to the player as well as how the networking experience was. This information can be used to determine network usage as well as to troubleshoot network bottlenecks and other problems.

Client Combination Logs

A client may submit a log containing values from both the client stream and client render logs. A combination log is sent in either of the following situations:
  • The player is based on an SDK earlier than Windows Media Format 9 Series SDK.
  • Windows Media Services and players based on the Windows Media Format 9 Series SDK are not using the Fast Cache feature for one of these reasons:
    • Server does not support it.
    • Server has it disabled.
    • Scenario does not support it, such as a live stream.

In this case, the log will appear to be identical with logs from a server running Windows Media Services 4.1. The exception to this is that the log entry for the server running Windows Media Service 9 Series or later will contain an additional eight fields.

Server Logs

Server logs are new to Windows Media Services. Unlike client logs, these logs indicate how a distribution server received content. Server logs are submitted for distribution servers and cache/proxy servers.

Distribution Server Logs

A distribution server log is generated when the downstream client is a distribution server. The distribution configuration is a Windows Media server (the distribution server) with a publishing point that is configured to source from an upstream server (the origin server). When the distribution server stops receiving data (by either the distribution or origin server's behavior), it sends a distribution server log.

This log does not indicate any rendering data as a client render log does; instead, it indicates the quality and streaming duration of content that was received.

The log that is sent is formatted for either a server running Windows Media Services 4.1 or Windows Media Services 9 Series or later, depending on the version of the upstream server.

Cache/Proxy Server Logs

To decrease the traffic between an intranet and Internet, a cache/proxy server can be used. Clients in the intranet will connect to the Internet through this cache/proxy server. If the requested content is already in the cache and has not expired, the cache/proxy server can use it instead of getting content from the actual server each time. Cache/proxy servers are also very beneficial for stream splitting.

A downstream cache/proxy server can receive data from an upstream origin server in a few different ways:
  • Streaming content into its cache.
  • Streaming content from an upstream server through the cache/proxy server to a downstream client (on-demand proxy).
  • Streaming content for broadcast splitting.

Just like distribution server logs, these logs are streaming logs and do not indicate any rendering data as a client render log would. Instead, the cache/proxy logs indicate the quality and duration of content that was received. Also, like distribution server logs, the log is sent when the downstream client no longer is receiving content. The value of the s-proxied field for these logs will be set to 1.

Client Logs Generated by the Server

Under certain circumstances, the Windows Media server will generate a log event even though the client has not sent a log. This occurs when the client does not send a log but the server recognizes that it should have. Client logs are typically generated by the server in the following situations:
  • When the client is Windows Media Player 6.4 and it reaches the end of each playlist item. This version of the Player does not submit a log during a playlist entry change (200 log code).
  • When the client is Windows Media Player 6.4 and it enters a never-ending buffering state at the end of a broadcast (408 log code).
  • When the client abnormally disconnects from the server and does not send a log (408 log code).
  • When a server disconnects its clients or encounters an internal error (500 log code).
  • When the URL or content requested by a client does not exist (404 log code).
  • When the client does not have the authentication or authorization to access the server, publishing point, or content (401 log code).

When the server generates logging data, it uses the server-side values that are available and any client values that were transferred at the beginning of the session. All of the client-side values that are transferred from the client to the server at logging time are missing (such as c-bytes, c-pkts-received, c-pkts-lost-net, and so on).

Note
  • In the case of Windows Media Player 6.4 and a server-side playlist, the Player will only send its log at the very end, when the playlist stops, or when the Player enters a nonplaying state. The log will contain the total number of bytes and the total number of packets received, representing the entire playlist. The server, however, will have reset its counters for each playlist entry. Therefore, when the playlist ends and the Player sends its log (the server will not have to generate the last one), the c-bytes and various c-pkts-xxxx fields will report values that represent the entire playlist, not just the last playlist entry. The server-side statistics will only report the last playlist entry's values, which may be considerably less than the client-side statistics. However, the x-duration for this log will be modified by the server so that it represents the duration only for the last playlist item and not the accumulated value.

Cases When a Server Collects Data

You may sometimes see the same field listed in both the server and client columns in the tables provided in this section. This means the server also keeps track of that data, and either the client or server data is used, depending on the situation or scenario.

As a rule of thumb, the server expects a log from players and downstream servers for each streaming session. If a player or downstream server does not submit a log, the server generates a log with the information it has for the session by using the connect time data and the server's streaming data. The server is also able to update some field values if they are missing or incorrect in the client log.

Start of the Connection

The information in the following table is collected by the server at the beginning of the client connection. This information is static, which means it does not change throughout the session. The server adds this data to the logs it receives from clients. In the event that a client does not submit a log, the server can still generate a log containing the connection time data. The following fields are known at client connection time.

Determined by server (at connection time)Sent by client (at connection time)
c-ip
cs-uri-stem
date
c-playerid
time
c-playerversion
filelength
cs(User-Agent)
filesize
cs-url
protocol
c-os (RTSP only)
transport
c-osversion (RTSP only)
s-ip
c-cpu (RTSP only)
s-dns

cs-user-name

s-session-id

s-content-path


For nonstreaming codes, such as 401 (access denied) and 404 (file not found), only connection time data is available. Clients do not send a log for these cases; however, the server generates the log to keep a record. For 401 and 404 codes, streaming did not happen, so any streaming-related fields are not available (they will contain a hyphen (-) or a zero because they do not apply), and only the connection time data is logged.

For RTSP, Windows Media Player 9 Series or later provides these additional fields at connection time: c-os, c-osversion, and c-cpu. So for the 408 (client disconnection) and 500 (server internal error) codes, these three fields are also available. Other protocols, such as HTTP (1.0 and 1.1) and MMS, do not provide this information at connection time.

The server provides the filesize and filelength fields to the client in the header, and then the client sends this information back in the log. The server fills these fields in only if the client does not report the information correctly (for example, some earlier players). The server also logs 408 and 500 codes.

During the Connection

Although clients cannot send log information dynamically while streaming, the server still collects information throughout the streaming process. This information is logged along with the information collected at the beginning of the connection in the event that the client does not submit a log. The fields in the following table are collected dynamically during a session.

Collected by server dynamicallySent by client dynamically
sc-bytes
c-rate
s-pkts-sent
c-status
avgbandwidth

x-duration

c-starttime

c-rate

c-status


Clients do not send a log in these three cases: for a 408 code (client disconnection), 500 code (server internal error), and 200 code (playlist change in Windows Media Player 6.4). The server generates the logs with these status codes, and because the server was streaming, it also logs the server-side dynamic streaming data.

Note
  • Windows Media Player 6.4 does not support server-side playlists and the ability to switch to the next item in a playlist. The server generates logs for instances of Windows Media Player 6.4 that are connected to a publishing point, sourcing from a server-side playlist.

End of the Connection

The client-side information in the following table is typically sent to the server with the client's logging information at end of a connection. This information can be either dynamic or static.

Provided by serverSent by client
avgbandwidth
c-starttime
sc-bytes
x-duration
s-total-clients
c-playerlanguage
s-cpu-util
cs(Referer)
cs-media-name
c-hostexe
cs-media-role
c-hostexever
s-proxied
c-os

c-osversion

c-cpu

audiocodec

videocodec

c-bytes

c-pkts-received

c-pkts-lost-client

c-pkts-lost-net

c-pkts-lost-cont-net

c-resendreqs

c-pkts-recovered-ECC

c-pkts-recovered-resent

c-buffercount

c-totalbuffertime

c-quality

cs-media-name

cs-media-role

Note
  • Only players based on the Windows Media Format 9 Series SDK or later send the cs-media-name and cs-media-role values to the server. The server fills these values in for earlier players.

Categorizing Fields

"Legacy" logs (those sent by a Player earlier than Windows Media Player 9 Series) are also called combination logs and contain both streaming and rendering (playing) data. When the Fast Cache feature is used in players based on the Windows Media Format 9 Series SDK, the logs have streaming and rendering data separated. When the Fast Cache feature is not used or enabled, the data is combined like "legacy" logs. Logs sent by distribution servers do not have the rendering data because the distribution server just streams content for its clients and does not play it.

The following streaming and rendering data is collected from clients.

Streaming-related fieldsRendering (playing)-related fields
x-duration
c-starttime
c-rate
x-duration
c-starttime
c-rate
sc-bytes
audiocodec
s-pkts-sent
videocodec
avgbandwidth

c-bytes

c-pkts-received

c-pkts-lost-client

c-pkts-lost-net

c-pkts-lost-cont-net

c-resendreqs

c-pkts-recovered-ECC

c-pkts-recovered-resent

c-buffercount

c-totalbuffertime

c-quality



Back to the top of this pageBack to Top


Logging in Windows Media Services 4.1 vs. Windows Media Services

Windows Media Services 9 Series or later supports earlier version of Windows Media Player (for example, versions 6.4, 7.x, and 8.x), but the best logging information is obtained for players based on the Windows Media Format 9 Series SDK and a server using Windows Media Services 9 Series or later.

Logging Feature Comparison Chart

The following table provides a comparison of logging features available in each version of Windows Media Services.

FeatureWindows Media Services 4.1Windows Media Services 9 Series or later
Number of fields in a log entry
44
52
Enables logging at the server level
Yes
Yes
Accepts HTTP/1.0 and the W3C standard text log
Yes
Yes
Accepts MMS binary log
Yes
Yes
Accepts HTTP/1.1 and RTSP XML logs
No
Yes
Enables logging at the publishing point level
No
Yes
Sends logs to an upstream server for distribution and supports cache/proxy scenarios
No
Yes
Supports plug-in architecture (custom logging plug-ins)
No
Yes
Supports multiple logging plug-ins for the same publishing point
No
Yes
Supports duplicate logging plug-ins for a publishing point
No
Yes
Date and time values
When the log was received by the server
When the client started to stream from the server. Note that this value is more accurate because network delay may offset the log receive time. Also, you have to make calculations to determine when the client started to stream.
Information collected for cs-uri-stem
The entire URL
Just the stem part. There is a new field that has the entire URL.
Information collected for c-dns
The value reported by client
Always a hyphen (-) for privacy and performance reasons
Recognized c-status codes
200, 401, 404, 408
200, 401, 404, 408, 210, 500, 420
Cycle period uses Coordinated Universal Time (UTC) date and time
Yes (always)
Cycle is based on the log file format value: UTC or local time. Logs files for "legacy" formats (Windows Media Services 4.1), always use UTC for a cycling period.
Protocols supported
HTTP/1.0, MMS, asfm (multicast). For the multicast protocol, logs are sent to an Internet Server Application Programming Interface (ISAPI) logging program running on an Internet Information Services (IIS) server.
HTTP/1.0, HTTP/1.1, MMS, asfm, RTSP, and caching

New Logging Fields in Windows Media Services

Windows Media Services 9 Series or later contains 52 logging fields by default. Eight new fields were introduced in this version, which are provided by the server.

Field nameDescription
cs-username
Domain\UserName for authentication and authorization cases.

For anonymous users, this value will contain a hyphen (-).
s-session-id
Session number associated with the stream. For server-side playlists, the client will send a log for each item in a playlist, all with the same session number. For player operations, such as play, pause, seek, fast-forward, rewind, skip to previous or skip to next playlist item, the logs will have the same session number. So you can track a user's actions by using the s-session-id values. HTTP/1.0 opens a new connection for each operation, which means each user action will have a different session ID. This issue is fixed with HTTP/1.1.
s-contentpath
The actual path to the content. If an encoder is the source, the value is the encoder's URL; for example, http://encoder-machine.com:8080. For server distribution, the value is the remote publishing point; for example, rtsp://myserver.com/publishingpoint. For an on-demand source, the value is the full path to the file.
cs-url
The entire URL requested by the client, including the query string.
cs-media-name
For sourcing from a file, the default value is the file name. For sourcing from an encoder, the default value is slash (/). For a remote publishing point, the default value is the remote URL; for example rtsp://myserver.com/pubpoint. A default value can be overwritten by using the mediaName tag in the .wsx file.
c-max-bandwidth
Maximum available bandwidth of the client in bits per second.
cs-media-role
This field helps filtering advertisement logs. For non-advertisement logs this is always a hyphen (-). You can assign role values in the server-side (.wsx file) or client-side (.asx file) playlist. A sample value is ADVERTISEMENT.
s-proxied
Used to indicate if a client is connected through a cache/proxy server or Web server. The distribution log sent by a cache/proxy server and the client log will have s-proxied set to 1.

Windows Media Services 4.1 Logging Highlights

  • This version of Windows Media Services has the ability to log client usage statistics to a log file.
  • Format of these text log files is based on the W3C standard.
  • Logging is enabled only at the server level.
  • This version cannot send logs for distribution and cache/proxy scenarios.
  • Logs have 44 fields in the log file.
  • Can accept and understand HTTP text logs (W3C format summary logs), and MMS binary logs.

Windows Media Services Logging Highlights

  • Logging in Windows Media Services 9 Series or later is a superset of version 4.1 logging, capable of logging everything that version 4.1 can, and much more.
  • The ability to log was moved to a plug-in model. A logging plug-in is included, which monitors events occurring on the server and appends client statistics to a log file. You can write your own logging plug-in and register to receive log events. You can also output logs to any storage container, such as a text file, database, or application window. Other provider's plug-ins are available on the Service Provider page at the Microsoft Web site (http://www.microsoft.com/windows/windowsmedia/service_provider/Software/default.aspx).
  • You can enable a logging plug-in at the server or publishing point level. An instance of the plug-in is created for each publishing point on a server that the plug-in is associated with, and one instance is created at the server level. If the logging plug-in is enabled for both a publishing point and the server it is associated with, the log entries associated with that particular publishing point will show up in both the global log file and the publishing point specific log file.
  • When a new publishing point is added, the associated logging plug-in is not enabled by default. Default properties, such as cycling the log file daily and logging in UTF-8 text format, are initially set for the plug-in when it is enabled. These initial default values are not carried over from the server instance to the publishing point specific instance. When you install Windows Media Services 9 Series or later, logging is disabled at the server and publishing point levels. To receive logs, you must enable the plug-in.
  • A logging plug-in is not restricted to how it performs its logging. One plug-in may log to a file, another may log to a computer running Microsoft® SQL Server™, and another may ignore all logging unless some criteria is met, such as when the average bandwidth used is larger than the specified limit. In which case, the event may be logged somewhere such as the Microsoft Win32® event log.
  • This version can accept all previous logs (HTTP W3C summary and MMS binary), and can accept and understand XML structured logs, which are sent by players based on the Windows Media Format 9 Series SDK or later or by a Windows Media server used as a distribution or cache/proxy server.
  • You can duplicate any plug-in in Windows Media Services, which means you can duplicate a logging plug-in for the same publishing point (or at the server level) and configure and enable them separately. You can also have multiple logging plug-ins associated with a publishing point (or at the server level). For example, if you want to filter logs by the cs-media-role field, you can set a logging plug-in to output only if it is an advertisement log, and you can set another logging plug-in to log all other media roles.

Fields That Changed in Windows Media Services

The following fields are changed in Windows Media Services 9 Series or later.
  • cs-uri-stem. In Windows Media Services 4.1, the cs-uri-stem field logged the entire URL. This field now logs only the stem part of URL, and a new field, cs-url, logs the entire URL. For example, if a client is connected to a URL, http://www.MyServer.MyDomain.com:8080/live?param=value, then the cs-url field logs this entire URL, and cs-uri-stem logs only the stem part of the URL, which is /live. The following table defines the various parts of the sample URL.
    URL partExample
    Protocol
    http://

    (Other possible values are mms:// and rtsp://)
    Host name
    www.MyServer.MyDomain.com
    Port
    8080

    (If not specified explicitly, the default port for HTTP is 80)
    Stem
    /live
    Query
    ?param=value

    In Windows Media 9 Services Series, cs-uri-stem identifies which publishing point is connected by removing the protocol, host name, port, and the query. Sometimes cs-uri-stem is a publishing point name, and sometimes it is a publishing point and relative path to file on the publishing point; for example, /movies/birthdayparty.wmv. The default publishing point is denoted by a slash (/), so the entry /AudioFile.wma means the AudioFile.wma file is associated with the default publishing point.
  • date and time. In Windows Media Services 4.1, the date and time fields record the time at which a log was received by a server. The date and time fields now log the client connection time or stream start time. This value is more useful because the time at which a log is received by the server might be offset as a result of network delay, and you do not have to make calculations to determine when the client started to stream. The logged date and time values are the stream start time, and the x-duration is how many seconds the client streamed. For server-side playlists, the logged date and time values are reset for each playlist item after each stream switch.
  • c-dns. The DNS entry for a client is now always logged as a hyphen (-). Even if earlier versions of clients send this entry, the Windows Media server does not log it because of client privacy. This change increases server performance because the server does not need to do reverse DNS lookup anymore.
  • c-rate. In Windows Media Services 4.1, the play or stream rate field can have only the values 1 (play), 5 (fast-forward), and -5 (rewind). This value can now be any number because of the Fast Cache feature, which allows clients to stream and download on-demand content faster or slower than real time. Depending on a client's network connection speed and available bandwidth, this field can contain values like 2, 3, 10, 20, and so on. The c-rate value is rounded up to the closest integer; hence, you cannot see fractions. For an actual rate of 0.4, zero (0) is logged; for a rate of 1.5, 2 is logged.
  • c-status. The c-status codes in Windows Media Services 4.1 (200, 401,404, and 408) are still supported and new c-status codes (500, 210, and 420) are introduced.
    CodeDescription
    200
    Client successfully streamed and submitted the log.
    210
    Client disconnects and then reconnects. After reconnecting, the client sends a log for the session before losing the connection, and starts a new session. Players built on the Windows Media Format 9 Series SDK are the first to have the reconnect mechanism.
    401
    Access is denied. This can occur when a client is not authenticated or authorized. Authentication is asking for a user name and password. Authorization is whether a user is allowed to access a specific publishing point or content on the server. For 401 logs, the cs-user-name is left as a hyphen (-). The administrator is advised to refer to the Win32 security event log to determine which user name failed.
    404
    Publishing point or content was not found.
    408
    Abnormal client disconnection. Client failed to submit a log either because the client disconnected or terminated.
    420
    Client reconnection failed. The client was disconnected and attempted to reconnect but failed. The client connects again and starts a new session. This status code reflects the client's statistics when it was originally disconnected. For each log entry with this status code, there should be a 408 code that has the same session ID.
    500
    Server internal error. Server disconnected the clients, or the encoder encountered a problem, and so on.

  • protocol. In addition to supporting HTTP/1.0 and MMS, Windows Media Services supports three new protocols.
    • Cache. This is for the Fast Cache scenario where Windows Media Player 9 Series or later plays content from a local cache instead of actually streaming from a Windows Media server, assuming the content was streamed and cached on the client with HTTP/1.1 or RTSP. The transport value is always a hyphen (-) for Cache.
    • RTSP. This protocol can use both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) transport protocols.
    • HTTP/1.1. This protocol keeps the connection between the client and server throughout the session; whereas HTTP/1.0 closes the current connection and opens a new one for each client action (for example, seeking and pause). HTTP/1.1 enables clients to send requests and data to a server while receiving data on the same connection.
    The multicast protocol (asfm) is not logged for a Windows Media server. The only place you can view the asfm protocol value is in the logs written by the ISAPI log application (wmsiislog.dll) on an IIS server.
  • x-duration. This value is the streaming or rendering (playing) time or both:
    • Streaming duration. This is the streaming time for the distribution server and Fast Cache logs. In these two cases, content is streamed but not rendered (played). For streaming logs, rendering-related fields such as audiocodec and videocodec will contain a hyphen (-).
    • Playing duration. When the Player plays the content, it will send a log to the server with the duration of play. If the end of the content is loaded into the Player's buffer, a log is sent automatically even if all content is not played yet.
    • Combination duration. For versions of Windows Media Player earlier than 9 Series, content streams and plays simultaneously so the duration is both the play and stream time. If the end of stream is reached in the buffer of the Player, the Player will send a log automatically, causing a little offset (depending on the buffer size) in the duration of the play time. When Fast Cache is not used in Windows Media Player 9 Series or later, the duration is both the streaming and playing time.
  • c-playerid. This value is reported by both clients and servers. A player ID is a Globally Unique Identifier (GUID) value. An embedded player also uses the standalone player's settings for sending the player ID. There are different types of GUIDS:
    • Distribution server GUID. This is always a series of zeros (00000000-0000-0000-0000-000000000000). If you want to track distribution servers, rely on c-ip values.
    • Anonymous GUID. If a client does not want to be identified uniquely, it can use the anonymous ID, which is 3300AD50-2C39-46C0-AE0A-xxxxxxxxxxxx. In an anonymous GUID, only the last part changes for each session. If the Send unique player ID check box is cleared in the Player, an anonymous GUID is sent. Macintosh players always send anonymous GUIDs.
    • Unique GUID. If a client is set to use a unique identifier, then a unique GUID (Player ID) is sent (the Send unique player ID check box is selected in the Player).
  • avgbandwidth. It is possible that content is streamed very fast: if the content is too short, a client is connected for a short duration, or Fast Cache is used and the connection is fast. In these cases, avgbandwidth might have a zero value.
  • c-quality. The minimum quality experienced by the client throughout the session; not the average quality. For example, if a client is streaming for ten minutes and there is a bad network connection for ten seconds, the c-quality value drops to 60 percent, and it does not go up again for the current session. So the c-quality value might be misleading sometimes. You should also look at the lost and recovered packets values, the total buffer time, and the buffer count to make a proper decision about the quality of the streaming. Do not just rely on the c-quality value alone.

Log File Entries Reference

The following is a comprehensive list of logging fields in Windows Media Services 4.1 and Windows Media Services 9 Series or later (in the order in which the fields appear in a log file).

Each entry contains the following information:
  • The field name
  • A description of the field
  • A sample value
  • Whether the data in the field is reported from unicast clients, multicast clients, or both.
  • What versions of Windows Media Services use the field. (If a field was used in both versions, but the usage of the field changed in Windows Media Services 9 Series or later, this is also noted.)

For more information about fields that changed their usage, see Fields that changed in Windows Media Services.

Fields that are new in Windows Media Services appear at the end of the table; there are 44 fields used in both versions, with 8 new fields added in Windows Media Services 9 Series or later, for a total of 52 fields.

Field nameDescriptionSample valueClient data reportedUsed in Windows Media Services 4.1 and Windows Media Services 9 Series or later
c-ip
The source Internet Protocol (IP) address of the connected socket. This may be the IP address of a proxy server or firewall.
157.56.219.146
Unicast

Multicast
Both
date
Date when a client connected (in international date format).
2001-04-19
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
time
Time when the client connected. The time format is either in Coordinated Universal Time or local time, depending on how the logging plug-in is configured.
15:30:30
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
c-dns
This field is always blank.
-
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
cs-uri-stem
The path (requested URL without the schema, host, port number, and question mark) to the content that was requested. See cs-url for the full URL. Note that this represents a change from Windows Media Services version 4.1, in which this field contained the full URL.
/test/sample.wmv

or

/broadcast
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
c-starttime
Timestamp (in seconds, no fractions) indicating the point in the stream when the client started to render content. For live broadcasts, this field is set to 0.
39
Unicast

Multicast
Both
x-duration
Length of time (in seconds) of the data received by the client. For player log entries, the value does not include buffered data. For distribution server log entries, the value includes all time spent receiving data, including any buffering.
31
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
c-rate
The rate at which data is sent from the server to the client. Possible values:

0.5: Half of the real-time rate.

1: Real-time rate

2: Twice as fast as real-time

5: fast forward

-5: fast rewind

If you are using Fast Streaming, these values could be considerably higher or lower depending on the content and the available bandwidth.
1
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
c-status
Codes that describe client status. Possible codes:

200: The connection was successful.

210: The client reconnected (after first disconnecting).

400: The requested URL was not valid.

401: The client was denied access.

404: The requested content was not found.

408: The client failed to submit a log because the client disconnected.

420: The client was disconnected and attempted to reconnect but failed. The client will then connect again starting a new session. This code reflects the client's statistics when it was originally disconnected. For each log entry with this code there should be a 408 that has the same session ID.

500: The Windows Media server encountered an internal error and stopped streaming.
200
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
c-playerid
Globally unique identifier (GUID) of the client. For player log entries, if the player is configured not to send unique player identification information to content providers, the value is: {3300AD50-2C39-46c0-AE0A-xxxxxxxxxxxx}, where x is the session ID of the client. For distribution server log entries, this value is always a series of zeros.
{c579d042-cecc-11d1-bb31-00a0c9603954}
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
c-playerversion
For player log entries, this field represents the version number of the player. For distribution server log entries, this field represents the version number of the distribution server.
6.2.5.415
Unicast

Multicast
Both
c-playerlanguage
Language and country/region code of the player.
en-US
Unicast

Multicast
Both
cs(User-Agent)
Browser type used if the player was embedded in a browser. If the player was not embedded, this field refers to the user agent of the client that generated the log.
Mozilla/4.0_(compatible;_MSIE_4.01;_Windows_98)
Unicast
Both
cs(Referer)
URL to the Web page in which the player was embedded (if it was embedded). If this is unknown, this field is blank.
http://www.example.microsoft.com
Unicast
Both
c-hostexe
For player log entries, the host program (.exe) that was run. For example, a Web page in a browser, a Microsoft Visual Basic applet, or a stand-alone player. For distribution server log entries, the name of the distribution server's service program (.exe) that was run.
iexplore.exe

vb.exe

mplayer2.exe

WMServer.exe
Unicast

Multicast
Both
c-hostexever
Host program (.exe) version number.
4.70.1215
Unicast

Multicast
Both
c-os
Client operating system.
Windows_NT
Unicast

Multicast
Both
c-osversion
Version number of the client operating system.
4.0.0.1381
Unicast

Multicast
Both
c-cpu
Client CPU type.
Pentium
Unicast

Multicast
Both
filelength
Length of the digital media file (in seconds). This value is zero for a stream delivered from a broadcast publishing point.
60
Unicast
Both
filesize
Size of the digital media file (in bytes). This value is zero for a stream delivered from a broadcast publishing point.
86000
Unicast
Both
avgbandwidth
Average bandwidth (in bits per second) at which the client was connected to the server. The value is calculated across the entire duration of the connection.
24300
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
protocol
Actual protocol used to access the content (may differ from the protocol requested by the client). A value of "Cache" indicates that a client played the content from its disk-based cache. A value of "asfm" indicates that the content was delivered using multicast transmission.
MMST
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
transport
Transport protocol used to stream content. Multicast content is always streamed using UDP.
UDP

TCP
Unicast

Multicast
Both
audiocodec
For player log entries, the audio codecs used to encode the audio streams the client accessed. If multiple codecs were used, the values are delimited by a semicolon. This field contains a hyphen (-) in distribution server log entries.
Microsoft_Audio_Codec
Unicast

Multicast
Both
videocodec
For player log entries, the video codecs used to encode the video streams the client accessed. If multiple codecs were used, the values are delimited by a semicolon. This field contains a hyphen (-) in distribution server log entries.
Microsoft_MPEG-4_Video_Codec_V2
Unicast

Multicast
Both
channelURL
URL to the multicast information file. This field contains a hyphen (-) in a client receiving content as a unicast stream unless the unicast stream is a result of a unicast rollover from a multicast stream.
http://www.example.microsoft.com/channel.nsc
Unicast

Multicast
Both
sc-bytes
Total number of bytes the server sent to the client. The value does not include any overhead that is added by the network stack. However, protocols such as MMS, RTSP, and HTTP may introduce some overhead. Therefore, the same content streamed by using different protocols may result in different values.

This field contains a hyphen (-) in propagated cache/proxy logs and in multicast log files.
30000
Unicast
Both
c-bytes
Number of bytes received by the client from the server. The value does not include any overhead that is added by the network stack. However, protocols such as MMS, RTSP, and HTTP may introduce some overhead. Therefore, the same content streamed by using different protocols may result in different values. If c-bytes and sc-bytes are not identical, packet loss occurred.
28583
Unicast

Multicast
Both
s-pkts-sent
Number of content packets sent by the server to a connected client. The value does not include TCP or UDP packets. This field contains a hyphen (-) in propagated cache/proxy logs and in multicast log files.
55
Unicast
Both
c-pkts-received
Number of packets from the server (s-pkts-sent) that are received correctly by the client on the first try. Packets that are not received correctly on the first try can be recovered if they are resent through the UDP protocol. Packets that are not recovered through UDP resend are considered lost in the network. You can recover these packets if error correction is enabled. The value does not include TCP or UDP packets.
50
Unicast

Multicast
Both
c-pkts-lost-client
Packets lost that were not recovered at the client layer through error correction or at the network layer through UDP resends, during transmission from server to client. These packets are sent by the Windows Media server but never played by the client. The value does not include TCP or UDP packets.
5
Unicast

Multicast
Both
c-pkts-lost-net
Number of packets lost on the network layer. You can still recover these packets if error correction is enabled. The value does not include TCP or UDP packets.
2
Unicast

Multicast
Both
c-pkts-lost-cont-net
Maximum number of continuously lost packets on the network layer during transmission from server to client. If the value is high, the network conditions were bad, with long periods of time during which the client received no packets. The value does not include TCP or UDP packets.
2
Unicast

Multicast
Both
c-resendreqs
Number of client requests to receive new packets. This field contains a zero unless the client is using UDP resend.
5
Unicast

Multicast
Both
c-pkts-recovered-ECC
Packets lost in the network (c-pkts-lost-net) that were repaired and recovered at the client layer because error correction was enabled. Error correction is the only means of packet recovery for multicast streams. Packets repaired and recovered at the client layer are equal to the difference between c-pkts-lost-net and c-pkts-lost-client. The value does not include TCP or UDP packets.
3
Unicast

Multicast
Both
c-pkts-recovered-resent
Number of packets recovered because they were resent through UDP. The value does not include TCP or UDP packets. This field contains a zero unless the client is using UDP resend.
5
Unicast

Multicast
Both
c-buffercount
Number of times the client buffered while playing the stream.
4
Unicast

Multicast
Both
c-totalbuffertime
Time (in seconds) the client used to buffer the stream. If the client buffers more than once before a log entry is generated, c-totalbuffertime is the total amount of time the client spent buffering.
6
Unicast

Multicast
Both
c-quality
The lowest amount of stream quality reported by the player during the playback of the stream.
96
Unicast

Multicast
Both

This field changed in version 9. See the previous section of this document.
s-ip
IP address of the server that received the log file. For multicast log files, this value will be the IP address of the Web server on which Wmsiislog.dll is installed.
224.24.41.189
Unicast

Multicast
Both
s-dns
Domain Name System (DNS) name of the server that received the log file. This field contains a hyphen (-) in multicast log files.
media.server.company.com
Unicast
Both
s-totalclients
Number of clients connected to the server (but not necessarily streaming) at the time the event was logged. This field contains a hyphen (-) in propagated cache/proxy logs and in multicast log files.
20
Unicast
Both
s-cpu-util
Average load on the server processor (0 to 100 percent). If multiple processors exist, this value is the average for all processors. This field contains a hyphen (-) in propagated cache/proxy logs and in multicast log files.
40
Unicast
Both
cs-username
The user name the client provided during authentication. This field contains a value only if authorization and authentication plug-ins are enabled. If an anonymous authentication method is used, this field will contain a hyphen (-).
JSmith
Unicast
Windows Media Services 9 Series or later
s-sessionid
A session identifier the server uses to track a stream session. This is important for tracking multiple log entries to the same session. Note that if Windows Media Player version 6.4 received content over HTTP, the s-sessionid value will change for each log entry, even if the entries are for the same session.
123456
Unicast
Windows Media Services 9 Series or later
s-contentpath
The actual content that streamed. A plug-in may resolve a requested path to another path. If the client was redirected, this field represents the location to which the client was redirected.
file://C:\WMPub\WMRoot\Encoder_ad.wmv

or

http://www.example.microsoft.com/speech.wma
Unicast
Windows Media Services 9 Series or later
cs-url
The actual URL requested by the client.

For multicast clients, this value is the multicast IP address and port. However, Windows Media Player 9 Series or later and Windows Media Player 9 Series ActiveX control multicast clients submit the multicast IP address and port, followed by the IP address of the network interface from which the server broadcasts the multicast.
mms://microsoft.com/mycontent.wmv

asfm://206.73.118.254:26502

-or- (for Windows Media Player 9 Series or later)

asfm://multicast IP address:port/Server IP address
Unicast

Multicast
Windows Media Services 9 Series or later
cs-media-name
If the client was receiving content from a playlist, the media element the client was receiving. The value is derived from the mediaName attribute of the playlist media element. If the mediaName attribute is not present, the value in this field is derived from the file name value. This field is blank if the client was not receiving content from a playlist.
/ads/MyAd2.asf
Unicast
Windows Media Services 9 Series or later
c-max-bandwidth
The maximum bandwidth rate (in bits per second) of the client. This value can be used to determine whether clients have the capacity for higher bandwidth content. The value recorded for this field can have the following types of values:

a) a valid number of bps reported from the client, such as 38400.

b) an undetermined amount, logged as 0.

c) a very large amount that cannot be accurately measured but is greater than 1000000 bps but less than 1000000000 bps, logged as a hyphen (-).

d) a hyphen (-), when a file is being played from the local cache and no bandwidth is used.
384000
Unicast

Multicast
Windows Media Services 9 Series or later
cs-media-role
A user-defined value that identifies the role of a media element in a playlist. Typically, this field is used to enable advertisement logging.

If the media element does not have a role attribute, or if the client was not receiving content from a playlist, this field is blank.

Alternatively, this entry can be specified in the announcement file to classify logs according to user or content.
Ad
Unicast
Windows Media Services 9 Series or later
s-proxied
Indicates whether the client connected through a cache/proxy server. A value of "0" indicates no cache/proxy server was involved. A value of "1" indicates a cache/proxy server was involved.
1
Unicast
Windows Media Services 9 Series or later


Back to the top of this pageBack to Top


Fields Verified or Modified by the Server

The following table provides the fields in the log file that the server verifies or modifies.

Field nameDescription
c-ip
If an instance of the Player earlier than 9 Series sends its c-ip in the log, the server removes it for the client's privacy.
date and time
For Windows Media Services 9 Series or later, the time the stream started.

For "legacy" format (Windows Media Services 4.1), the time the log was received.
c-starttime
If this is live broadcast publishing point, set c-starttime to zero because instances of the Player earlier than 9 Series do not report it correctly.

If the c-starttime value is not reported by the client, indicated by a hyphen (-), the server value is used.
c-rate
If the client does not report a value, indicated by a hyphen (-), the server value is used.
x-duration
If the client does not report a value, indicated by a hyphen (-), the server value is used. If the value is reported as zero by Windows Media Player 9 Series or later, then that value is used. If the value is reported as zero for a version of the Player earlier than 9 Series, then the server duration value is used.

For a live broadcast publishing point (which means sourcing from the encoder) and client logs connected to server (which means excluding the cache/proxy-propagated client logs and rendering logs from Windows Media Player 9 Series or later), if the difference between a client's duration and a server's duration is greater than two minutes, the server's x-duration value is used.

For other types of publishing points (non-live ones: broadcast and on-demand publishing points) and clients connected directly to the server, the server compares the x-duration reported by the client with filelength. If the difference is more than two minutes, then the server's duration value is used.

For cache/proxy propagated logs and rendering logs from Windows Media Player 9 Series or later (for these logs there is no server-side data available because there is no active session for these logs) and for a live broadcast publishing point, the maximum duration allowed is 2,147,483,647. If it is larger than this value, replace it with no value (-).

For cache/proxy propagated logs and rendering logs from Windows Media Player 9 Series or later, and for on-demand and broadcast publishing points, if a client's duration is greater than filelength + 2 minutes, replace it with no value (-).

For 200 code values, the server generates fake logs for playlist items for all connected Windows Media Player 6.4 clients. When Windows Media Player 6.4 sends a log, it sends an accumulated x-duration value. The server replaces this value with the duration value for only the last playlist item.

For clients that have security update MS06-078 for Windows Media Player 6.4 installed, if c-starttime + x-duration is greater than filelength, c-totalbuffertime is zero, and c-starttime = x-duration, use the server's x-duration value. If the c-bytes value is zero, use the server's x-duration value. For more information about this security update, see Microsoft Security Bulletin MS06-078.
c-dns
No value is reported, indicated by a hyphen (-), even if some earlier clients report it. This is to protect the client's privacy.
c-os
Earlier players do not support new operating systems. So, if a client reports c-os incorrectly, it is corrected on the server side by looking at the c-osversion value.
avgbandwidth
If no value is reported by the client, the server's avgbandwidth value is used.

If the value reported by the client is valid then use it; otherwise, replace it with server's avgbandwidth data.
filelength and filesize
If this is a live broadcast publishing point, then set this value to zero because earlier players do not report it correctly.

For 401 and 404 codes, these fields do not apply and are filled in by the server as either no entry (-) or zero.

If clients report no data, then the field is filled by the server's data.
cs-media-name
Versions of Windows Media Player earlier than 9 Series do not report this field, so the server fills in this information.

If no value is returned from Windows Media Player, the server value is used. If the Player reports a value, it is used. (For example, for 408 or 500 codes, the server fills in this field because the client does not send a log for these cases.)

The media name is the digital media file's name by default. For the encoder, it is slash (/), and for a remote publishing point, it is the remote URL. You can change this in the .wsx file with the mediaName attribute.
cs-media-role
Versions of Windows Media Player earlier than 9 Series do not report this field, so the server fills in this information.

If no value is returned from Windows Media Player, the server value is used. If the Player reports a value, it is used. (For example, for 408 or 500 codes, the server fills in this field because the client does not send a log for these cases.)

You can set the role in the .wsx file with the role attribute or in the .asx file (Windows Media Player 9 Series or later only) with a parameter like:

<PARAM NAME="Log:cs-media-role" VALUE="Ad">
c-max-bandwidth
Rendering logs for Windows Media Player 9 Series or later are always blank (-) because the Player plays it back from a local cache and does not stream from a server.

If no value is reported in this field by a client, the server value is used.

If a valid value is reported from the client, the server uses that value.

For undetermined values, zero is logged.

For a large bandwidth that cannot be accurately measured, greater than 1,000,000 bits per second (bps) and less than 1,000,000,000 bps, the value is logged as 2147483647 or a hyphen (-).


Back to the top of this pageBack to Top


Windows Media Services Logging Plug-in Architecture

The logging plug-in is just an event plug-in that registers to receive particular events, and then writes information regarding the event to a log file. This gives the logging plug-in the ability to log authentication and authorization failures, cache hits and misses, and so on.

The WMS Client Logging plug-in is included in Windows Media Services. It is really an event plug-in that listens for log events and saves information gathered by that event to text log files. You can create custom plug-ins that perform similar functionality (such as logging server events) and store the reported information in different locations and formats. For example, you can create a logging plug-in that reports log information for an HTML page or submits reports to a computer running SQL Server.

Plug-ins written with .NET and COM technology are both supported. For example, you can write your custom logging plug-in in programming languages such as C++, C#, and Microsoft Visual Basic® .NET. You can find sample plug-ins written with these languages in the Windows Media Services 9 Series SDK.

You can install such event monitoring plug-ins at the server and publishing point level. At the server level, the plug-in receives notification of log events from all publishing points. At the publishing point level, the plug-in receives events that are related to the current publishing point only.

The WMS_EVENT_LOG event is sent when a log is received or generated for scenarios in which the client is connected directly to the server and streaming (for example, the client is not connected through a cache/proxy server, distribution server, or not playing back from a local cache). This event is also sent for distribution and cache/proxy servers streaming from another server.

The WMS_EVENT_REMOTE_CACHE_LOG event is raised when a Windows Media server receives a log from a cache/proxy server from which clients have requested content. Multiple cache/proxy servers can sit between the client and the origin server, which is called a multi-tier scenario. For a multi-tier scenario, the log is propagated up by all cache/proxy servers until it reaches the origin server, which provides the actual content. The WMS_EVENT_REMOTE_CACHE_LOG event is also raised and a log is sent to the server when a client is playing back from its local cache (for example, it is not streaming from the server). If you want to receive logs with this information, you have to subscribe to both events, and whenever these events are fired you will have access to the log data.

Back to the top of this pageBack to Top


Server Provides Logs in XML Format to Plug-Ins

The logging data provided by a server running Windows Media Services 9 Series or later to logging plug-ins is in XML format and represented as Unicode characters. The time and date of the log is in UTC format.

Starting with Windows Media Player 9 Series, the server logs are sent by using both the traditional W3C standard "summary" line in addition to an XML structure. The XML data represents the same information as in the "summary" line except that it is separated using XML constructs. This is beneficial because logging data is no longer under the limitations of W3C standards (for example, white spaces no longer have to be converted to underscores).

The data is submitted from the client to the server, and the "summary" line is actually a node within the XML data itself. XML format is flexible, so it will be compatible with any future logging formats that define new fields.

Here is the general structure of the XML log that is received by plug-ins:

<XML>
<Summary>0.0.0.0 2002-01-16 01:43:45 …</Summary>
<c-ip>...</c-ip>
<date>...</date>

...

<s-proxied>...</s-proxied>

<ContentDescription>
<field1>...</field1>
<field2>...</field2>
...
</ContentDescription>

<Some3rdPartyNamespace>
<field1>...</field1>
<field2>...</field2>
...
</Some3rdPartyNamespace >
...
</XML>
The actual log provided to a logging plug-in is between the <Summary> tags, which uses W3C format, allowing 52 space-delimited fields. After the <Summary> tag, each field is separated. These separate fields do not necessarily have the same data as in the <Summary> node. The fields contain the data that is sent by a client, if applicable. Some of the fields sent by a client are just a placeholder and are filled in by the server (for example, the bytes and packets sent). Also, if the server does not find the client's data reliable, it replaces it with its own data. So in the <Summary> node, you will have this final log after the server's modifications; however, you can access the data sent by the client in the separated fields. The separate <date> and <time> tags provide the time the log was received, which is used for the 4.1 compatibility mode in the logging plug-in included with Windows Media Services.

You are not allowed to change or add new fields to the Summary section. It is designed to have 52 fields and only the server can add information to this section. Following the 52 separate field tags is the Content Description section, which includes data such as the author, title, and copyright. The content description section can be followed by any number of custom namespaces and fields.

How to Define Custom Namespaces and Fields in an XML Log

If you need to append additional log data to the XML log structure, you can achieve this by using .asx files. After the Content Description section, you can define any number of custom namespaces and name-value pairs.

Example 1

The following code provides an example of how to add the cs-media-role field by using a .asx file with Windows Media Player 9 Series or later.

<ASX version="3.0">
<ENTRY>
<TITLE> My Title </TITLE>
<Author> My Author </Author>
<PARAM NAME="Log:cs-media-role" VALUE="Advertisement" />
<REF href="http://www.MyServer.MyDomain.com/live" />
</ENTRY>
</ASX>
The client (in an .asx file) is not allowed to overwrite any information defined by the server (in a .wsx file). If cs-media-role is not defined on the Windows Media server in the .wsx file (server-side playlist file), the cs-media-role field defined in the .asx file gets logged on the server as the standard (default) namespace. The cs-media-name field is not logged by the .asx file for the standard namespace because the server always sets a value for cs-media-name, and the client is not allowed to overwrite it. This means that for the default log data, you can only set the cs-media-role data within the .asx file. In this example, when you play the .asx file, the client will connect to MyServer.MyDomain.com and stream. When the client sends the log, it will set the cs-media-role field in <Summary> and <cs-media-role> in the XML log to Advertisement. Note that you have to start the parameter name with "Log:" to add fields to the log. If you want to log additional fields beside the default 52 fields by using .asx files, you have to define new namespaces for these additional fields. To add a new namespace, besides prefixing with "Log:" you also have to add a namespace name, as seen in Example 2.

Example 2

The following code provides an example of how to add another party's namespace and fields by using a .asx file with Windows Media Player 9 Series or later.

<ASX version="3.0">
<ENTRY>
<TITLE> My Title </TITLE>
<Author> My Author </Author>
<PARAM NAME="Log:my-field1:MyNameSpace" VALUE="Value1" />
<PARAM NAME="Log:my-field2:MyNameSpace" VALUE="Value2" />
<REF href="http://www.MyServer.MyDomain.com/live " />
</ENTRY>
</ASX>
When an XML log is sent for this .asx file to a server, a new namespace is added after the Content Description section. The logging plug-in included in Windows Media Services will not output this data, it will just ignore it. However, you can write a custom logging plug-in to process and output the appended namespace and name-value pairs. So in the XML log, you will have the following code:

<XML>
<Summary>0.0.0.0 2002-01-16 01:43:45 …</Summary>
<c-ip>...</c-ip>
<date>...</date>

...

<s-proxied>...</s-proxied>

<ContentDescription>
<field1>...</field1>
<field2>...</field2>
...
</ContentDescription>

< MyNameSpace>
< my-field1>Value1</ my-field1>
< my-field2>Value2</ my-field2>
</ MyNameSpace>
</XML>
This feature is supported by Windows Media Player 9 Series or later. Previous versions of the Player (6.4, 7.1, and 8.0) do not support this feature.

How to Log Additional Data By Using .wsx Files (Server-Side Playlists)

Another way of adding additional data to the XML log structure is by using .wsx files. In the .wsx files, you can add additional information to the client data section. This data is sent to the clients and when a client sends a log to the server, it also sends this additional data in the Content Description section. However, the logging plug-in included in Windows Media Services ignores this section and does not write the data to the log file. You will need a custom logging plug-in to access this new data in the XML structured log and output it.

The following example shows how to generate additional data from a client:

<?wsx version="1.0"?>
<smil>
<media src="industrial.wmv"/>
<clientData newLogField = "Its-Value" />
</smil>
In the client data section, a new field, newLogField, is added and its value is "Its-Value". You must use a custom logging plug-ins to write this data to the log file if you want to access the data. When a client streams the server-side playlist and sends a log at the end of the stream, the log will contain this "newLogField" data in the content description section as seen in the following example.

<XML>
<Summary>0.0.0.0 2002-01-16 01:43:45 …</Summary>
<c-ip>...</c-ip>
<date>...</date>
...
<s-proxied>...</s-proxied>

<ContentDescription>
<field1>...</field1>
<field2>...</field2>
...
<newLogField>Its-Value</ newLogField>
</ContentDescription>

...
</XML>
The following example shows how to add the media name and media role fields to the .wsx file:

<?wsx version="1.0"?>
<smil>
<media src="industrial.wmv" mediaName="My media name" role="Advertisement"/>
</smil>
This feature is not supported by versions of Windows Media Player earlier than 9 Series.

Back to the top of this pageBack to Top


About the WMS Client Logging Plug-in

Windows Media Services includes a default logging plug-in, WMS Client Logging. This plug-in can subscribe to both WMS_EVENT_LOG and WMS_EVENT_REMOTE_CACHE_LOG events. When the server raises a logging event for the subscribed publishing point (or server), the plug-in gets the XML-formatted log data and outputs the W3C standard space-delimited log into a text file. The log file consists of two parts: the header and log fields.

Default Settings for the Logging Plug-In

SettingDescription
Log file path
%SystemRoot%\System32\LogFiles\WMS\<V>\WMS_<Y><m><d>.log
Log cycle period
Daily
Time format
Coordinated Universal Time (UTC)
Buffer
Buffers log entries
File format
Unicode characters (UTF-8)
Log format
Windows Media Services format
Request log entries from clients connected to the server
Selected by default
Request log entries from sessions played from the player cache or cache/proxy server
Not selected by default
Save player statistics
Selected by default
Save distribution server statistics
Selected by default
Filter player statistics with the Role attribute value
Not selected by default
Free space quote
Default is 10, meaning 10 percent. Client will stop logging if it has less than 10 percent of free space on the hard disk. You can change this setting through the object interface.

WMS Logging Plug-in Highlights

  • If you have scripts to analyze the logs of a server running Windows Media Services 4.1, you can modify them to read and analyze logs from a server running Windows Media Services 9 Series or later. Additional header lines are included that start with a number sign (#). You can ignore these lines. Each log line will have 52 fields instead of 44.
  • Whenever you make a change to the properties and event subscription of a logging plug-in through the object interface or MMC snap-in, it will not take effect until you re-enable the plug-in (disable and enable the plug-in).
  • For security reasons, a server running Windows Media Server 9 Series or later runs under a "Network Service" account and not an "Administrator" account; therefore, the logging plug-in does not allow logging to a mapped drive. However, you can use UNC paths to log a remote computer. You have to give write permissions for this UNC path on the remote computer to the computer running Windows Media Services, and then you can use a path like the following:
    \\RemoteComputerName\LogPath\WMS_<Y><m><d>.log
    In this path three templates (wildcards) are used <Y> is the four-digit year, <m> is month, and <d> is day. For example: \\RemoteComputerName\LogPath\WMS_20030530.log
  • To define the log file path, you can use environment variables and wildcard characters. The default path is:
    %SystemRoot%\System32\LogFiles\WMS\<V>\WMS_<Y><m><d>.log
    <V> is the current publishing point name, <Y> is the four-digit year, <m> is month, and <d> is day. For example:
    C:\WINDOWS\System32\LogFiles\WMS\[Global]\WMS_20030206.log
    WMS Client Logging Properties General tab
    For the full set of wildcards you can use, see Logging Wildcard Characters Reference.
  • You can define six cycle periods in a log file: hourly, daily, weekly, monthly, when a file size is reached, or to never cycle. The default is a daily cycle. For local time, this value is midnight. For UTC time, this value may vary depending on your location relative to Greenwich, UK.
    Log cycle period
    For example, Pacific Time (GMT-08:00) is 8 hours behind Greenwich. So when it is 4:00 PM in Pacific Time, the UTC time will be midnight and the log file is going to cycle for a daily period.
  • Although the server always provides the date and time in the XML log structure in UTC format, the logging plug-in can output it in UTC or local time. When you select local time, the plug-in converts the date and time fields from UTC standard to the local computer date and time.
  • There are two options for writing logs to a hard disk: buffering logs before writing, and writing logs immediately. The logging plug-in buffer logs and writes them when the buffer is full. Buffering logs first is better for performance reasons because data is not written to the hard disk for each log received. Instead data is written to disk when the computer's buffer is full or a certain amount of time has passed. Buffering may not be the best option to use in case the server experiences a catastrophic failure, which will cause you to lose the buffered logs. The other option is to write logs immediately, which means logs are written immediately to the hard disk when they are received. The default setting is to buffer before writing.
  • The log file format can be ANSI or UTF-8 (Unicode). If you use ANSI format, non-ANSI characters will be lost. Using ANSI or UTF-8 does not make a difference for ASCII characters (0-127); however, for non-ASCII characters (128-255), ANSI still uses one byte where UTF-8 uses at least two bytes. If you are expecting Unicode characters in the log file, always use UTF-8 (Unicode) format, which is the default value.
    WMS Client Logging Properties Advanced tab
  • The WMS Client Logging plug-in can also generate log files in legacy format (Windows Media 4.1 server mode). One reason to use this mode is if you have tools that you are using for server logs in Windows Media Services 4.1, and you want to continue to use them in the transition mode until you have new or updated tools for server logs in Windows Media Services 9 Series format. In the 4.1 compatibility log mode, the logging plug-in outputs only 44 fields and ignores the eight new fields. The plug-in also uses the date and time values for the log-receive time instead of the stream-start time. And the cs-uri-stem field will have the whole URL, including the query part (just like the cs-url field). To benefit from the information in the eight new fields, you should use the Windows Media Services 9 Series format, which is the default value.
  • By using the logging plug-in's properties (through the object interface or the Microsoft Management Console (MMC) snap-in), you can set which events you want to subscribe to. If you select the Clients connected to the server check box, the server will subscribe to the WMS_EVENT_LOG event and will receive logs from clients that are connected directly to the server; this setting is selected by default.
    WMS Client Logging Properties Log Entries tab
  • If you select Sessions played from player cache or a cache/proxy server, the server will subscribe to the WMS_EVENT_REMOTE_CACHE_LOG event; this is not selected by default.
  • You can also filter logs received by the server according to their cs-media-role fields. For example, you can specify that logs be written only when the cs-media-role value is "Advertisement". The cs-media-role value can be assigned in a .wsx file or .asx file (versions of the Player earlier than 9 Series do not support defining the cs-media-role field in .asx files). Filtering is turned off by default.
  • Filtering player logs (player statistics) is possible. By default, the logging plug-in writes player logs. However, if you want logs for only distribution servers, clear the Player statistics check box on the Properties dialog box for the plug-in.
  • Filtering distribution server logs is also possible. This setting is selected by default, which means distribution server statistics (distribution servers and cache/proxy servers connected directly to the Windows Media server) are collected. If the Distribution server statistics check box is cleared, distribution logs are discarded.
  • If there is less than 10 percent of free disk space on the client's hard disk, the logging plug-in stops logging and the logs are dropped until more space is available on the disk. However, sometimes 10 percent of the disk can be a lot; for a 100-gigabyte (GB) hard disk, this is 10 GB. Ten percent is the default value, which you can change only through the object interface of the logging plug-in. The property for this is FreeSpaceQuota. You can set the value to any number between 0 and 100. You have to re-enable the logging plug-in by cycling it (through the MMC snap-in or object interface), disabling and re-enabling it, or restarting the server. For sample scripts, see the Windows Media Services 9 Series SDK.

Logging Wildcard Characters Reference

You can add wildcard characters to a log file name if you want to change the name to suit your needs. Wildcard characters must be delimited by the less than (<) and greater than (>) characters. For example, the log file name template WMS_<a><B><Y>.log might correspond to the log file name WMS_MonApril2007.log.

The following table lists and describes the wildcard characters.

CharacterDescription
a
Abbreviated name for the day of the week (three letters).
A
Full name for the day of the week.
b
Abbreviated month name (three letters).
B
Full name for the month.
c
Date and time representation appropriate for the location of the server generating the log file.
d
Day of month in two-digit format (01 to 31).
H
Hour (24-hour format) in two-digit format (00 to 23).
I
Hour (12-hour format) in two-digit format (01 to 12).
j
Day of year in three-digit format (001 to 366).
m
Month in two-digit format (01 to 12).
M
Minute in two-digit format (00 to 59).
N
A four-digit sequence that starts at 0 and increases every time a new file is needed. The counter resets to 0 when the rest of the file name changes in any way.
p
The indicator for 12-hour format (AM or PM) of the server generating the log file.
S
Seconds in two-digit format (00 to 59).
T
The computer name of the server generating the log file.
U
Week of the year in two-digit format (00 to 53, with Sunday as the first day of week).
V
The name of the publishing point for which data is being logged. If data is being logged for a server, the word "[Global]" is inserted in the log file name. If data is being logged for the default publishing point, the word "[Default]" is inserted in the log file name. If the publishing point name contains a forward slash (/) character, the character will be replaced with an underscore (_) character in the log file name. If the publishing point is renamed, the log file will automatically cycle to reflect the new name.
w
Day of the week in one-digit format (0 to 6, with Sunday as 0).
W
Week of the year in two-digit format (00 to 53, with Monday as the first day of the week).
x
Date representation for the location of the server generating the log file.
X
Time representation for the location of the server generating the log file.
y
Year in two-digit format (00 to 99).
Y
Year in four-digit format.
Z
Time zone name or abbreviation. There are no characters if the time zone is unknown.


Back to the top of this pageBack to Top


Logging with the ISAPI Extension (wmsiislog.dll)

Windows Media Services includes an ISAPI extension (wmsiislog.dll) that runs on an IIS server and accepts logs for multicast scenarios and LogURLs defined in the .asx and .wsx files.
  • The log is stored in a text file and is in W3C standard space-delimited format and has 52 fields. The logs on an IIS server do not contain server-side data. You cannot view server-generated log entries (401, 404, 408, 500, and 200 generated for Windows Media Player 6.4 when playing a server-side playlist); you can only view client-generated log entries (200 and 210 log entries).
  • You can install the ISAPI extension from Control Panel. Click Add or Remove Programs, click Add/Remove Windows Components, click Windows Media Services, click the Details button, and then select the Multicast and Advertisement Logging Agent check box. When you install it, it is copied to %SystemDrive%\WMPub\WMIISLog\ and registered. Just copying and registering wmsiislog.dll is not sufficient because the write permission is granted for the log folder during setup. If you install IIS and Windows Media Services on the same computer, make sure you use different port numbers because they cannot use the default port (80) at the same time.
  • Multicast streaming is more for intranet use than Internet use. The current Internet infrastructure does not support multicast streaming either because all switches do not support it or it is not enabled on all switches. However, in an intranet, it is easier to configure a network to enable multicast streaming.
  • There are some registry keys that you can use to control the ISAPI extension. You can find the properties for the registry key in:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media\Server\ISAPI\Logging
    Caution
    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
      PropertyDescription
      FreeSpaceQuota
      Default is 10 percent. If the client has less than 10 percent of free disk space, the server will stop logging until the client has more free disk space. You can set values between 0 and 100.
      LogDirPath
      Default is %SystemRoot%\System32\LogFiles\WMS_ISAPI

      This is the path where logs are created. If you change this path, you must ensure that appropriate permissions are given to the directory.
      UseLocalTime
      Default is 0. Output is in UTC when the value is 0, and local time when the value is set to 1.
      UseUnicode
      Default is 1. Output is in Unicode (UTF-8) format when the value is 1, and ANSI format when the value is 0.


For more information about how to set up a multicast scenario and ISAPI extension, see Windows Media Services Help.

Back to the top of this pageBack to Top


Logging Scenarios

This section provides information and illustrations of the various logging scenarios.

Basic Streaming Scenario

In this scenario, clients are connected to a Windows Media server directly. They send their logs directly to the Windows Media server at the end of session.

Basic streaming scenario flowchart

Fast Reconnect Scenario

Windows Media Player 9 Series or later contains the Fast Reconnect feature, which automatically reconnects it to a server running Windows Media Services 9 Series or later if it gets disconnected because of a temporary network or server problem. If there is a problem (for example, the encoder stream for a live publishing point is temporarily not available), the Player will use Fast Reconnect and try to reconnect to the server periodically until it reconnects or times out. If the Player times out, it will stop; otherwise, it will reconnect and continue to receive a stream. Whenever the Player reconnects to the server, it sends a log for the session before reconnecting (210 status code). If the Player reconnects multiple times, the Player will send a 210 status code for each reconnection. When the Player reconnects again, it will send another log (200 status code) for the session. This feature is not supported by earlier versions of the Player.

Fast Reconnect scenario flowchart

Fast Cache Scenario

Fast Cache is supported only by Windows Media Player 9 Series or later and the Windows Media Format 9 Series SDK for on-demand content. Fast Cache is not supported for live scenarios (sourcing from an encoder). When a client requests a digital media file or playlist and the content source is a publishing point, the Player will first check to see if the content is already in its cache. If the content is in the client's local cache and has not expired, the Player will play it and send the rendering log to the server (this is called a Player-Cache Hit scenario). If the content is not in the local cache or has already expired, the content is streamed and cached and the Player will play it from the local cache (this is called a Player-Cache Miss scenario). The Player sends both streaming and rendering logs in this case. There are some other factors that determine if Fast Cache is used or not:
  • The client must have extra available bandwidth to download and cache the content faster than normal speed.
  • If the client will have less than 100 MB of free disk space after caching the requested on-demand item, it will not cache the content and will only stream and render it simultaneously like earlier versions of the Player.
  • Fast Cache downloads and caches only missing files for a playlist. If a playlist item is already in the client's local cache, it will not cache it again and will only play it back.
  • Fast Cache must be enabled on the server, which is enabled by default.
    Fast Cache scenario flowchart

Distribution Scenario

In this scenario, a distribution server is located between clients and the origin server. A publishing point was created on the distribution server sourcing from the origin server's publishing point. For broadcast publishing points, there is only one connection between the origin and distribution server, regardless of how many clients connect to the distribution server to access content on that broadcast publishing point. For broadcast streaming, the distribution server splits the stream to its clients (if the origin server allows stream splitting, which is the default setting). For on-demand streaming, the distribution server opens a new connection to the origin server for each connected client.

Connected clients send their logs to the distribution server, and then the distribution server writes these logs but does not propagate them to an upstream server. The distribution server sends logs for its own connections to the upstream server. These types of logs are not propagated any further if there are multiple upstream servers between the distribution and origin server (multiple distribution servers exist between the client and the origin server). Distribution server logs do not have any rendering-related fields (such as audio and video codec fields) because the distribution server just streams the content for its clients and does not render the content itself.

Distribution server scenario flowchart

Cache/Proxy Scenario

Windows Media Services supports cache/proxy plug-ins, which enables the Windows Media server to act as a cache/proxy server. These features are not mutually exclusive; a Windows Media server can be configured as an origin server, a distribution server, and a cache/proxy server at the same time. What a server acts as depends on how clients are connected to the server's publishing points (directly, through a cache/proxy, or through a distribution server).

Cache/Proxy server scenario flowchart

This illustration shows a cache/proxy server located between clients and an origin server. The clients are configured to use the cache/proxy server for network streaming connections. And from the clients, a URL is opened on the origin server. For a broadcast publishing point, only one connection exists between the origin and cache/proxy server (this is identical to a distribution server stream splitting scenario) regardless of how many clients are connected through the cache/proxy server for that broadcast publishing point. For broadcast streaming, the cache/proxy server splits the stream to its clients (if the origin server allows stream splitting, which is the default setting). When a client requests content from an on-demand publishing point, the cache/proxy server checks its own cache for the content, and if it is there, the server streams the content from its cache (cache-hit scenario). If the content is not in the cache, then the cache/proxy server connects to the origin server, which proxies the content to the cache/proxy server and downloads the content to the cache/proxy server's local cache (if the origin server allows the content to be cached to cache/proxy servers).

The cache/proxy server sends logs for its own connections to an upstream server, similar to the logs that a distribution server sends to the origin server. The cache/proxy server sends two separate logs, one for caching and one for proxying the on-demand stream. When a client sends a log to a cache/proxy server, the cache/proxy server writes this log to its own log file and also propagates this log to the upstream server; however, the cache/proxy server removes information in some fields before sending it to the upstream server (for example, s-cpu-util and s-totalclients to protect its own privacy).

Multiple cache/proxy server scenario flowchart

If multiple cache/proxy severs are located between the client and origin server, the client's log is propagated continuously until it reaches the origin server. A logging plug-in must subscribe to the WMS_EVENT_REMOTE_CACHE_LOG event to receive such propagated logs.

Back to the top of this pageBack to Top


Multicast Logging Scenario and LogURL in Playlist Files

Multicast is connectionless broadcasting, which means that there is no direct connection between clients and the Windows Media server. After creating the multicast publishing point on the server, you must export an .nsc file, which contains information for clients that enables them to receive the multicast stream and the URL of the ISAPI logging application running on a server running Internet Information Services (IIS). Windows Media Services includes an ISAPI logging application that can receive log lines and output them to text file in World Wide Web Consortium (W3C) format.

Multicast logging scenario flowchart

It is also possible to send unicast logs to the ISAPI logging application by defining one or more LogURL values in client-side playlist files (.asx files) or in server-side playlist files (.wsx files). In the client-side playlist, you can define a LogURL for each playlist item or one LogURL for the entire playlist. It is also possible to send the same log file to multiple LogURL values. Windows Media Player 9 Series or later sends both rendering and streaming logs to the ISAPI logging application if a LogURL is defined in an .asx or .wsx file. An example of a typical LogURL is http://myserver/scripts/wmsiislog.dll.

Security Zones and LogURL

Differences in client, Windows Media server, and IIS server security zones may affect what information is logged. Some information, such as the Referrer URL field cs(Referer), may be set to a hyphen (-) if the server is in a less trusted security zone. This particularly affects LogURL in .asx and .wsx files. For example, if the LogURL directive specifies a server that is in a different security zone than the Windows Media server, then the LogURL directive may be ignored.

Where You Can Define LogURL Values

In Server-Side (.wsx) Playlist Files

<?wsx version="1.0"?>
<smil>
<media src="industrial.wmv"/>
<clientData logURL="http://logserver/scripts/wmsiislog.dll" />
</smil>
Players before Windows Media Player 9 Series cannot process the clientData section in the .wsx file, so they will not send a log for the LogURL defined in the file. Windows Media Player 9 Series or later or a player based on the Windows Media Player 9 Series SDK will send logging information.

In Client-Side (.asx) Playlist Files

<Asx Version = "3.0" >
<LOGURL href="http://LogServer1/scripts/wmsiislog.dll" />
<LOGURL href="http://LogServer2/scripts/wmsiislog.dll" />
<Entry>
<Title > "Title of the content" </Title>
<Ref href = "rtspu://wms-e2ev5/content/welcome2.asf"/>
<LOGURL href="http://LogServer3/scripts/wmsiislog.dll" />
</Entry>
</Asx>
This example defines LogURLs for both the entire playlist and also for individual playlist entries. Each entry's logging information is sent to the global LogURL. If the playlist entry has an entry-level LogURL, logging information is also sent to that address. You can also define multiple LogURLs for each playlist entry or for the entire playlist. Windows Media Player 6.4 cannot process LogURL information in .asx files. Thus, Windows Media Player 6.4 and players based on the Windows Media Player 6.4 SDK cannot send log information to LogURLs in .asx files. Windows Media Player 6.4 can, however, send logging information to LogURLs defined in .nsc files.

In Multicast Information Files

You can define LogURL values in multicast information (.nsc) files for multicast streams. The only way you can define this type of LogURL is through the wizard included with Windows Media Services. The .nsc file is encrypted, but can be read by Windows Media Player 9 Series or later and players based on the Windows Media Player 9 Series SDK. Currently, you can define only one LogURL in the .nsc file. To be able to define multiple LogURLs, you can wrap .nsc file in an .asx file that has multiple LogURLs defined.

Multicast publishing points are connectionless broadcast publishing points. A user that is streaming from a multicast publishing point can only stop the player and cannot control playback by pausing, seeking, fast-forwarding, rewinding, or skipping playlist items. A multicast publishing point can source from encoders (live sources), files (with .asf, .wma, .wmv, and .mp3 file name extensions), server-side playlist files (with .wsx file name extensions), or remote publishing points.

If a multicast publishing point is sourcing from server-side playlist, Windows Media Player versions 7 and later send one log entry for each playlist item. However, Windows Media Player 6.4 sends only one log entry when the user stops the stream. The logging information contains the accumulated data for all playlist items; Windows Media Player 6.4 and earlier does not send a log entry for each playlist item.

The ISAPI Logging application does not have any information about the streams; thus, it cannot fill in the server-side information such as the number of bytes sent or the number of packets sent. In addition, you cannot see server-generated logs (such as 404 file not found, 401 access denied, 408 client abnormal termination, and 500 server internal error).

Back to the top of this pageBack to Top


Distributing Log Files to Customers

If you host content, you may have customers who want to receive log files for their content. Windows Media Services offers the following two methods to accomplish this: you can add a LOGURL tag to the client-side playlist file (also called the announcement file) for your customers' content or you can use the logURL attribute in a server-side playlist to send log files to your customers.

Client-side playlists

The LOGURL tag has the syntax <LOGURL href="URL" />, where URL is the path to a directory specified by your customer. The LOGURL tag within an announcement file can be used with clients running Windows Media Player 7.0 or later.

To process the log data, your customers can use the Multicast and Advertisement Agent Internet Server Application Programming Interface (ISAPI) extension (wmsiislog.dll). They can also write a Common Gateway Interface (CGI) script or develop an ASP page to process the log data.

You must use HTTP or HTTPS for the LOGURL tag. You can add the tag to the ASX scope or to the ENTRY scope. If you add the tag to the ASX scope, the tag applies to all content referenced in the announcement file, including content that is referenced by secondary announcement files. If you add the tag to the ENTRY scope, the tag applies only to the content referenced in the ENTRY scope. Therefore, only client actions associated with content in the ENTRY scope are logged.

You can add multiple LOGURL tags. If you do so, data is logged to each URL you specify. The ENTRY scope inherits tags from the ASX scope. Therefore, if you add one URL to the ASX scope and another to the ENTRY scope, data for the content in the ENTRY scope is logged to both URLs. If you add the same URL to both the ASX and ENTRY scopes, the data is logged only once to the URL. If the announcement file references secondary announcement files, the secondary announcement files inherit any LOGURL tags that are in the primary announcement file. Therefore, LOGURL tags in the primary announcement file also apply to entries in the secondary ASX scopes.

After you add the tag, when Windows Media Player submits a log entry, it performs an HTTP Get first to the URL that was specified in the LOGURL tag to guarantee that the URL is valid. After an acceptable header is returned, Windows Media Player reconnects to the HTTP server and uses an HTTP Post tag to the same URL. The fields logged by the Multicast and Advertisement Logging Agent are the same as the fields logged by the WMS Client Logging plug-in. The only exception is that there are no server statistics because Windows Media Player is only submitting client data.

To provide the customer with more flexibility in sorting and classifying log files, you can specify the values for some of the log file entry fields in the announcement file. When a player connects to the server, the player receives this information in the form of a Content Description List (CDL). When the player sends log information back to the server, it also returns some fields with the values you specified. The cs-media-name and cs-media-role fields can be specified in this manner.

Server-side playlists

The logURL attribute is an attribute of a clientData element in a server-side playlist. The clientData element is a child element that associates text information, banner images, and logging information to the parent media element. Using the logURL attribute of a clientData element is helpful when streaming content from several different sources, each of which need to receive content-specific logging information. The logURL attribute only directs log data that is specific to the media elements in the playlist that have associated clientData elements. If the client is running Windows Media Player for Windows XP and earlier, the clientData element information will be ignored. For more information, see Windows Media Services SDK clientData.

Back to the top of this pageBack to Top


Additional Information About Logging

  • Streaming content protected by using digital rights management (DRM) does not affect logging. Digital rights management determines whether you can stream the content or not. If the server can stream the content, it will be able to log data about the stream; if it cannot stream the content, the server will not log any data. Content protection does not affect any fields in the log.
  • The Windows Media Services Fast Start feature does affect some log fields. For example, Fast Start affects the avgbandwidth field because the server fills the Player buffer very quickly when the server first starts streaming. In addition, the c-totalbuffertime value may also be low depending on the amount of extra bandwidth that is available. The Fast Start feature is only available for on-demand content.
  • During stress test scenarios, the percentage of CPU capacity used for logging operations was much less than one percent. Since Windows Media Services can determine whether a logging plug-in is enabled, it will not waste CPU cycles for logging processing operations if there is no logging plug-in enabled.
  • If the client's buffer reaches the end of the stream, the client will send logging data automatically, even if it has not finished rendering the content. Depending on the buffer capacity of the client (which is 10 seconds by default, but can be up to 120 seconds), there may be some variation in the log's x-duration values if the client does not render all the content. For example, if the client buffer capacity is 30 seconds and the buffer reaches the end of stream, the user may stop the client at the beginning of buffer (meaning that 30 seconds of the content was never rendered). The client already sent logging data to the server because it reached the end of stream, and the x-duration value is equal 30 seconds more than the actual rendering time.
  • In Windows Media Player 9 Series or later, users can change the play speed settings. For example, a play speed setting of 1 is normal play speed, 0.5 is slow, and 1.4 is fast, and so on. The play speed setting value determines both the playback speed and also the streaming rate, which affects the c-rate field in the log. Because this field is rounded up to the nearest whole number, the c-rate value for a play speed setting of 0.5 will be 1, the c-rate value for a setting of 1.5 will be 2, and so on.
  • You can enable the Active Script Event Handler plug-in on the server level or the publishing point level using Visual Basic Scripting Edition, Microsoft JScript®, or Perl, and then subscribe to logging events. When one of the subscribed events occurs and your script is going to run, you have access to the associated session data and can process the data in real time. Due to the limitations of scripting languages, a script only has access to a subset of the information that a logging plug-in can access. However, scripting still might be very useful to fulfill some needs. For example, you can use a script to keep track of the number of logs sent by clients, the number of 408 logs generated, the number of 401 logs generated, the number of people connected with anonymous globally unique identifiers (GUIDs), and so on. You will know when a logging event occurs, and you can do additional processing with the provided session data. In addition, writing scripts is easier than writing event plug-ins, and you can use these scripts to process real-time data. For more information about the Active Script Event Handler plug-in, see Windows Media Services 9 Series Help and the Windows Media Services 9 Series SDK.

Back to the top of this pageBack to Top


Known Logging Issues for Previous Versions of Windows Media Player

  • When Windows Media Player 6.4 streams server-side playlists, the server generates a 200-status log entry for each playlist entry. The Player also sends its own log data when it reaches the end of the playlist or when the user clicks Stop. In the log, the bytes/packets received values are much greater than the bytes/packets sent values because the Player reports the accumulated data for the entire playlist.
  • When Windows Media Player 7.x streams on-demand playlists, the c-quality value for the first playlist item is logged as zero.
  • When Windows Media Player 7.x streams on-demand or broadcast server-side playlists, the bytes/packets received values are logged as zero.
  • If Windows Media Player 6.4 connects to a publishing point on the server by using HTTP and then connects to a different URL or publishing point without ending the first connection, the server records a 408 log entry for the first connection.
  • For several playback operations, such as play, fast-forward, and stop, HTTP/1.0 creates a new connection, which causes each log entry from Windows Media Player 6.4, Windows Media Player 7.x, and Windows Media Player for Windows XP to contain a new session-id value. This issue is resolved beginning with Windows Media Player 9 Series because that version of the Player uses HTTP/1.1.
  • When the Windows Media server streams content too quickly to Windows Media Player 6.4, the Player sends a message to the server to stop streaming for awhile. The Player then opens another connection and changes the session ID value, but it does not send logging information to the server. Thus, the server generates a 408 log entry for the previous session.
  • Clients running Windows® CE cannot send logging information to a server running Internet Information Services (IIS) (for multicast and LogURLs in .asx and .wsx files) because there is no logging agent (the application that sends logs to the IIS server) in Windows CE.

Back to the top of this pageBack to Top


Distinguishing Between Log Types

Log typeCriteria
200 log for Windows Media Player 6.4 streaming a server-side playlist
  • c-status is 200
  • c-player version starts with 4.1 or 6.4
  • c-bytes is (-), and c-pkts-received is (-)
  • c-os is (-), and c-quality is '-'
  • All other client sent streaming related fields are (-)
Multicast log
  • protocol is asfm
  • channelURL is not (-)
Distribution log
  • c-hostexe is WMServer.exe
  • audiocodec is (-), and videocodec is (-)
  • cs(User-Agent) starts with WMServer/9
  • c-playerid is {00000000-0000-0000-0000-000000000000}
Cache/Proxy server log
  • c-hostexe is WMServer.exe
  • audiocodec is (-), and videocodec is (-)
  • s-proxied is 1
  • cs(User-Agent) starts with WMCacheProxy/9
  • c-playerid is {00000000-0000-0000-0000-000000000000}
Windows Media Player 9 Series or later or player based on Windows Media Player 9 Series SDK streaming log
  • audiocodec is (-), and videocodec is (-)
  • cs(User-Agent) is one of the following values: WMFSDK/9.*_WMPlayer/9.*, WMPlayer/9.*, NSPlayer/9.*
  • Streaming-related fields are not (-)
Log for Windows Media Player 9 Series or later or player based on Windows Media Player 9 Series SDK with Fast Cache turned off
  • audiocodec and videocodec are not (-)
  • cs(User-Agent) is one of the following values: WMFSDK/9.*_WMPlayer/9.*, WMPlayer/9.*, NSPlayer/9.*
  • Streaming-related fields are not (-)
Windows Media Player 9 Series or later rendering log
  • protocol is Cache
Cache/Proxy propagated client log
  • s-cpu-util is (-), and s-totalclients is (-)
  • s-proxied is 1
401 log
  • c-status is 401
408 log
  • c-status is 408
500 log
  • c-status is 500
404 log
  • c-status is 404
200 log
  • c-status is 200
210 log
  • c-status is 210
6.4 client log
  • c-playerversion is 6.4 or 4.x
7.x client log
  • c-playerversion is 7.x
8.x client log
  • c-playerversion is 8.x
9.x client log
  • c-playerversion is 9.x
Browser embedded client log
  • cs(Referer) is not (-)
  • cs(User-Agent) contains browser info (for example, "Mozilla/")
  • c-hostexe has the browser application name (for example, IExplore.exe)
Live broadcast publishing point log
  • filesize is 0
  • filelength is 0
Stream has audio log
  • audiocodec is not (-)
Stream has video log
  • videocodec is not (-)
Server generated log
  • 200 log for Windows Media Player 6.4 and server-side playlist log, or
  • c-status is one of the following values: 401, 404, 408, and 500.
LogURL in ASX File
  • channelURL is (-), and the log is on a server running Internet Information Services (Multicast Application)
  • Server-side fields are all hyphens (-)
Web-proxied log
  • s-proxied is 1
  • c-hostexe is not WMServer.exe


Back to the top of this pageBack to Top


Known 408 Log Reasons and Issues

Unless otherwise specified, these issues relate to all current Windows Media Player versions.
  • Windows Media Services version 4.1 does not send log information for a distribution scenario
    A code 408 log is generated for each distribution connection to a server running Windows Media Services version 4.1, since that version is not able to send log information.
  • Stopping/closing/seeking while buffering in Windows Media Player 6.4 with HTTP
    A code 408 log is generated if you stop, seek, or quit Windows Media Player version 6.4 and earlier while buffering using the HTTP protocol.
  • Time out occurs because of bad network conditions
    When Internet traffic levels are very high, the client receives a time out, which generates a 408 log.
  • Client times out because the Windows Media server is overloaded
    When the Windows Media server load is very high, the client receives a time out, which generates a 408 log. The Windows Media server may also drop clients, generating additional 408 logs. Generally, if the server CPU usage nears 100 percent, the server may be forced to drop a large number of clients. This scenario is likely to happen if the administrator does not put a bandwidth or client limit on the server. To avoid this issue, administrators should make use of the available limits in Windows Media Services.
  • Player application is terminated abnormally
    If the user is having bad playback experience, he may quit the Player abnormally (for example, through Task Manager), which generates a 408 log. If the client computer stops responding or restarts, the Player will not be able to send log information, causing the server to record a 408 log.
  • User loses network connection
    If the client computer is disconnected from network, it will not be able to send log information to the server. When the server acknowledges that the client is no longer connected, the server generates a 408 log for the client. If the user unplugs the network cable or releases the Internet Protocol by using the ipconfig/release command, the client will lose its connection to the server.
  • Network problems
    The Windows Media server and clients may become disconnected due to network congestion, router problems, switch/hub problems, and Internet Service Provider problems. If a client becomes disconnected, the server records a code 408 log.
  • Encoder-related problems
    During a live broadcast, if the connection between the Windows Media server and the encoder is lost or the encoder stops streaming for some reason, the server may record 408 logs because clients are disconnected from the server.
  • Network Load Balancing using HTTP/1.0 with no affinity specified
    If clients connect to servers in a cluster by using HTTP/1.0, the clients that connect to a particular server in the cluster the first time will not necessarily connect to the same server during subsequent connections. As a result, the clients may send statistical results to a different server in the cluster and the original server may never receive the information. Therefore, the original server creates a 408 log as if the client had disconnected abnormally. In addition, the server could record a 408 log when a client switches bandwidths, attempts to fast-forward or rewind, or performs any action that requires opening a new connection to the server through HTTP/1.0.
  • Starting a new Windows Media Player 6.4 connection without ending the first one
    If Windows Media Player 6.4 connects to a publishing point on the server by using HTTP and then connects to a different URL or publishing point without ending the first connection, the server records a 408 log for the first connection. Similarly, if the user plays something by using Windows Media Player 6.4 and then plays it again by pressing the Play button, the server records a 408 log.
  • Fast-forwarding after playing causes 408 log with Windows Media Player 6.4 and earlier when streaming through HTTP
    If content is streamed through HTTP to Windows Media Player 6.4 and earlier and the user fast-forwards the content after playing it, the server generates a code 408 log.
  • Windows Media Player 6.4 goes into a wait state when a broadcast publishing point finishes streaming a file
    If you create a broadcast publishing point that uses an on-demand file as its source, Windows Media Player 6.4 goes into a wait state when the publishing point reaches the end of the on-demand file. The Player will not send log information to the server, thus causing a 408 log.
  • Fast Reconnect failure causes 408
    When the Fast Reconnect feature fails, the server records a code 408 log. Therefore, for each 420 status log (auto reconnect failure), there is a corresponding 408 log.
  • Server streams too fast for the 6.4 client
    When the Windows Media server streams content too quickly to Windows Media Player 6.4, the Player sends a message to the server to stop streaming. The Player then changes the session ID value, but it does not send logging information to the server. Thus, the server generates a 408 log for the previous session.
  • Embedded Windows Media Player 6.4 control in America Online browsers
    If a Windows Media Player 6.4 ActiveX® control embedded in an America Online browser attempts to connect to a Windows Media server, the server may record a 408 log.
  • Win16 clients
    Win16 clients (computers running Windows® 3.1 or earlier) may cause the server to record code 408 logs.
  • Macintosh clients
    Macintosh clients may cause the server to record code 408 logs.
  • UNIX clients
    UNIX clients may cause the server to record code 408 logs.
  • Proxy servers and firewalls
    Certain proxy server and firewall scenarios may cause the server to record code 408 logs.

Back to the top of this pageBack to Top


For More Information


Back to the top of this pageBack to Top



© 2014 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies
Microsoft