XM Radio Player Part I : Fiddling

I’ve had an XM radio subscription for a couple years now but I’ve never been entirely happy with any of the options for XM Radio Online. XM’s online player has changed very little over the years, and it is missing many simple features you can find in other third party players and real radio hardware – like artist and song notifications. A couple days ago I started to think about just writing my own XM radio player for the heck of it.

The first step was to see what goes on between the browser and the server when streaming music. Note: this is an attempt to build a legitimate custom player to use with an XM subscription – not an attempt to get XM programming for free.

Fiddler

Fiddler is my tool of choice for web traffic sniffing. If you are just looking for tools to monitor the JSON payload sizes for an AJAX-ified web page, then there are a million tools and plug-ins with this functionality. Fiddler goes well beyond the entry level sniffing tool and touts itself as an HTTP debugger. You can set breakpoints, tamper with requests, build requests (from scratch, or by dragging and dropping a request from the list of previous requests), force requests to trickle (to simulate slow networks – great for testing SIlverlight splash screens),  and extend Fiddler with managed code. There is also a CustomRules.js file that one can use to quickly extend and customize Fiddler using JScript.NET. As an example, the following code will place a new “Hide CSS” option in the Fiddler Rules menu and declare a variable to store the state of the menu item:

public static RulesOption("Hide CSS requests")
var m_HideCSS: boolean = false;

To hide CSS requests when the menu item is checked, add the following to the OnBeforeRequest function:

if(m_HideCSS) {
  if(oSession.uriContains(".css")) {
    oSession["ui-hide"] = "hiding css";
  }
}

There are dozens of other useful rules in the Fiddlerscript cookbook.

Perhaps the most unknown feature in Fiddler is the QuickExec box (or at least I didn’t know about QuickExec until recently). QuickExec is the little black box at the bottom of the recorded session list. The box serves as a command line interface to Fiddler, and you can use QuickExec to filter the session, perform string matching, set breakpoints, launch a web browser, and more. There is a video demonstration for QuickExec available, and a list of default commands. If you use Fiddler regularly it’s worth your time to learn QuickExec and find the shortcuts that make your job easier.

Fiddler and XM

It only takes a few minutes with Fiddler to figure out the four important endpoints for XM radio online.

• A “login servlet” that requires a POST with user credentials in the payload. A successful login will respond with an auth cookie that needs to be sent along on subsequent requests. In ASP.NET we’d call this forms authentication.
• A “channel data” servlet that returns the available XM channels in JSON.
• A “now  playing” servlet that returns the artist and song currently playing on each XM channel (again in JSON).
• A “play media” servlet that accepts a channel number in the query string and returns HTML. Buried in the HTML is an object tag that instantiates media player and includes the URL to the music as a parameter (actually the URL parameter points to an endpoint that returns an ASX playlist which media player understands – the actual mms:// endpoint is in the ASX). The URL includes what looks like an encrypted auth token - the auth cookie isn’t required anymore, but the streaming server can still determine if the user is authorized to steam music.

This was enough information to decide that building a custom player isn’t terribly difficult. The next step was to write some .NET code just to prove there wasn’t any technical hurdles in walking through these 4 endpoints. We’ll look at that in Part II.