|
E-mail us with your comments and feedback about this article. |
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
IntroductionFor 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 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 Top
Logging OverviewLog Formats Accepted by Windows Media ServicesFor 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).
| Protocol | Player/Distribution | Log 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 LogsWindows 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 LogsClient 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 state | Next state | Explanation/actual | Log |
|---|
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:
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:
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 LogsServer 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 ServerUnder 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).
NoteIn 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 DataYou 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 ConnectionThe 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 ConnectionAlthough 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 dynamically | Sent 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.
NoteEnd of the ConnectionThe 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 server | Sent 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
|
NoteCategorizing 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 fields | Rendering (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 Top
Logging in Windows Media Services 4.1 vs. Windows Media ServicesWindows 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 ChartThe following table provides a comparison of logging features available in each version of Windows Media Services.
| Feature | Windows Media Services 4.1 | Windows 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 ServicesWindows 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 name | Description |
|---|
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 HighlightsThis 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 HighlightsLogging 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 ServicesThe 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 part | Example |
|---|
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. | Code | Description |
|---|
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 ReferenceThe 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 name | Description | Sample value | Client data reported | Used 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 Top
Fields Verified or Modified by the ServerThe following table provides the fields in the log file that the server verifies or modifies.
| Field name | Description |
|---|
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 Top
Windows Media Services Logging Plug-in ArchitectureThe 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 Top
Server Provides Logs in XML Format to Plug-InsThe 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.
|
