I'm using the Windows Background Intelligent Transfer Service (BITS) as the technology for downloading podcasts in the background so that RSS Bandit doesn't hog too much bandwidth while downloading the latest Ze Frank video. However it came to my attention that there certain conditions that had to apply before BITS was able to be clever about downloading a file from a website in the background. The conditions are spelled out in the HTTP Requirements for BITS Downloads which states

BITS supports HTTP and HTTPS downloads and uploads and requires that the server supports the HTTP/1.1 protocol. For downloads, the HTTP server's Head method must return the file size and its Get method must support the Content-Range and Content-Length headers. As a result, BITS only transfers static file content and generates an error if you try to transfer dynamic content, unless the ASP, ISAPI, or CGI script supports the Content-Range and Content-Length headers.

This means you can't use BITS to download podcasts from the feeds of sites such as C|Net MP3 Insider because it doesn't provide a Content-Length header when retrieving podcasts. Due to this limitation I've had to implement a fallback mode where we use a direct HTTP download request to retrieve the podcast. This solution is problematic if large video files are being downloaded in this manner because all the PCs bandwidth may end up being consumed by this task. For this reason, I've borrowed a leaf from the RSS platform in IE 7 and will also only support this for podcasts that are 15MB or less.

I sampled a number of files over 15MB at http://audio.weblogs.com and didn't see many which were provided by a Web server that didn't meet the BITS requirements. Of course, I might be mistaken and there is some popular podcast which regularly provides files over 15MB and doesn't meet the conditions set forth by BITS. In that case, I'd consider upping the limit to something higher or providing some config file option to increase the limit.