in Internet Services

Quicktime caching of Windows Media payloads

A while ago I wrote a post about how the Windows Media video experience is sub-optimal on non-Windows computers — in particular, Macintoshes — and why I think this will trigger a run towards Flash on-demand and eventually Flash live. Here’s a concrete example: over the last six months to a year, and perhaps longer, we’ve been dealing with a steady stream of user complaints that the nightly newscast of CBC’s The National (insert promotional tagline about “Canada’s most trusted news source, hosted by newly-announced Order of Canada member Peter Mansbridge”) is frequently “out of date”. While I haven’t totally nailed down why this might be the case, I do note that most complainants seem to be using Quicktime to play back the stream, with Flip4Mac (ugh) as the translation layer. I believe that with so many moving parts, something is inevitably going to go wrong.

If you deconstruct how we play back the video on the Latest Broadcast page, you’ll see that the ASX file link never changes. It is always The contents of the ASX file don’t change either: it’s a one-item playlist pointing to (WMCache=0 being appended to the query string in an analyst’s attempt to solve this problem). The mrl3 in the link indicates that the actual MMS link is going to be generated by our proprietary Media Resource Launcher software, which will in turn spit out a dynamically-generated playlist containing a link like this: mms:// This link is to our Akamai CDN which dynamically fetches content from our origin servers and replicates it to an edge server close to you. Part of the link includes a cache key which is generated from the mtime() of the file.

The phenomenon we have seen on some computers, particularly those running Flip4Mac and Quicktime to deliver the Windows Media stream, is that the dynamically-generated MMS link (in the last stage) is somehow cached on the computer if you’ve watched The National previously. If yesterday’s MMS link is cached by Quicktime, then upon replaying the stream, you will retrieve yesterday’s video from the edge cache, as opposed to today’s which will have a different cache key.

I’m not sure which software component is to blame for this strange behaviour, but we have done everything we can think of on the server side to ensure that newly-uploaded episodes of The National are available as soon as possible, have no server-side or edge-side caching directives (e.g. HTTP cache-control headers), and that MRL3 is working properly. So I’m open to entertaining suggestions — or even just commiseration along the lines of “yes, I’ve seen this before and it sucks.”!

On a somewhat related note, I will be attending the Akamai Customer Conference in Boston near the end of August and I would love to chat with other technical folks in the media/entertainment/broadcast industry. Let me know if you’re also going to be there!

Write a Comment


  1. > WMCache=0 being appended to the query string

    Change it to WMCache=DayOfWeek or WMCache=EpisodeNumber and see if that fixes things.