Microsoft RSS Blog

I'm using IE7 and the feed list to manage the podcast I listen to and the auto-downloads work well.  Except for trying to get WMP to autodiscover the new media.  Right now I'm using a manual process.

1) Setup the feed to auto-download

2) Click the "view files" button and copy the folder to the clipboard

3) Go to WMP and add a new folder to monitor.  Paste the path from the clipboard.

4) Setup a Auto-Playlist to include the new podcast

5) Setup the sync to my portable player (a Sprint PPC-6700)

Any suggestions for simplifying this process?  

Are there events that an app could respond to notice that new feed is downloading attachments?

Is there a way to define the directory for downloads? It would be so much better for findnig the files later.

Hi guys,

Is there perhaps a registry hack to extend the 15MB limit? We have work-related podcasts we're trying to download that are just outside that range, and so we have to manually download them.

That will place a serious limitation on the Internet Explorer browser for feeds that contain video since it doesn't take much video to pass 15MB.  This will adversly impact not only video bloggers, but all public media content producers.

Just as more and more public broadcasting stations are adopting RSS feeds for sharing their local content, you're capping the file size in way that prevents most video and nearly any full-length audio program.  There has to be a better alternative than HTTP-Range checking.

The point of RSS is to make this kind of content syndication simple.  RSS is an XML format and should be totally independant of the server.

A number of companies including mine absolutley hate that you all decided to continue using BITS it completly destroys stats reporting of downloads and puts ridiculous loads on servers that are serving the data.

Here is why instead of having to deal with one file request and serving it at once thus one call to our databases servers that are managing file distribution for load purposes you all send 100's of request for one single file.

One service provider is so pissed at the way Bits is abusive to those of use serving the data that they have BLOCKED BITS releated transfers.

All of consider the protocol to not be friendly to us serving up data and you continue to not win friends in your utilization of bits. You should have talked to the people really serving data!

It's intresting what you did with the security model, but I think you should allow "infinte" sized simple HTTP GET downloads for enclosures that come from the same server who supplied the feed.

So if I am reading all of this correctly.  IE7 is really not an aggragator in that it does not actually download all of the shows and then place them with your other Rich Media.  

The real reason podcasting took off - was not that you could add an enclosure and have some one subscribe and download to it.  Rather it went a crucial step further (or at least Adam Curry did) it was setup such that the files after being downloaded were placed with all of your other rich media files so the subscriber could easily find and consume the media.  

With out that crucial step - it is not podcasting.  It is just downloading via RSS.  At least if the file size is less than 15 Meg.  

Which by the way most podcasts are well over 15 Meg in size.

So when is MS coming out with a truly intergrated Podcasting solution for the subscriber?

Rob @ podCast411

How about a new year's resolution for the RSS team:

Allow users to choose the maximum size of enclosure to download and let them decide whether or not to trust the server.

If you are feeling really virtuous, how about another one: Allow users to set the download location for enclosures.

I know that Microsoft is always being lambasted for not catering to the lowest common denonminator but these two things are pretty vital to achieving the functionality needed to make IE7 achieve its objectives.

How clever to aviod DoS attacks the size of the enclosure is limited to 15MB. Nobody would ever have a podcast bigger than that surely?

Check out: http://msdn.microsoft.com/msdnmag/podcast/default.aspx

8 podcasts, 4 of which would not be automatically downloaded by IE7. What internet vandal would host such large files?

Does the feed manager recognise links with the micro format rel=enclosure as enclosures or does it look for the <enclosure> tag? What about Atom enclosures?

Please make it possible to set the download location of enclosures!

One more request for the ability to specify a download folder for each feed. Without this I am left with iTunes or manually downloading my podcasts so I can burn them to CD for listening in the car.

Dann

Walter  -

You're not being misunderstood. You need to make it so that this does not bother users by not allowing them to download podcasts. Here's a better way of preventing bandwidth wastage: Monitor the feeds bandwidth usage pattern and inform the user of any abnormalities that appear. This will actually turn a stupid restriction into a useful feature.

I agree with Dann, being able to specify (different) download folders for different auto downloaded  feeds would be a great advantage. Also feeds that are different auto downloaded go to Temporary Internet Files and so could easily be deleted forgetting that there are feeds downloaded.

لوتسمح هل من الممكن توضع رابط تنزيل لا الشرح وحدة لا يكفي ولك مني جزيل الشكر .

It's intresting what you did with the security model, but I think you should allow "infinte" sized simple HTTP GET downloads for enclosures that come from the same server who supplied the feed.

Thanks Walter, Good to know. 15mb limit would be useless for our guys. I see what you've done now, it's starting to make sense. Thanks again.

A number of companies including mine absolutley hate that you all decided to continue using BITS it completly destroys stats reporting of downloads and puts ridiculous loads on servers that are serving the data.

Here is why instead of having to deal with one file request and serving it at once thus one call to our databases servers that are managing file distribution for load purposes you all send 100's of request for one single file.

One service provider is so pissed at the way Bits is abusive to those of use serving the data that they have BLOCKED BITS releated transfers.

All of consider the protocol to not be friendly to us serving up data and you continue to not win friends in your utilization of bits. You should have talked to the people really serving data!

How about a new year's resolution for the RSS team:

Allow users to choose the maximum size of enclosure to download and let them decide whether or not to trust the server.

If you are feeling really virtuous, how about another one: Allow users to set the download location for enclosures.

I know that Microsoft is always being lambasted for not catering to the lowest common denonminator but these two things are pretty vital to achieving the functionality needed to make IE7 achieve its objectives.

That will place a serious limitation on the Internet Explorer browser for feeds that contain video since it doesn't take much video to pass 15MB.  This will adversly impact not only video bloggers, but all public media content producers.

Just as more and more public broadcasting stations are adopting RSS feeds for sharing their local content, you're capping the file size in way that prevents most video and nearly any full-length audio program.  There has to be a better alternative than HTTP-Range checking.

The point of RSS is to make this kind of content syndication simple.  RSS is an XML format and should be totally independant of the server.

I'm using IE7 and the feed list to manage the podcast I listen to and the auto-downloads work well.  Except for trying to get WMP to autodiscover the new media.  Right now I'm using a manual process.

1) Setup the feed to auto-download

2) Click the "view files" button and copy the folder to the clipboard

3) Go to WMP and add a new folder to monitor.  Paste the path from the clipboard.

4) Setup a Auto-Playlist to include the new podcast

5) Setup the sync to my portable player (a Sprint PPC-6700)

Any suggestions for simplifying this process?  

Are there events that an app could respond to notice that new feed is downloading attachments?

How do I change the default directory for downloads?

You cant! You must wait for the soft update.

Thanks for very interesting article. btw. I really enjoyed reading all of your posts. It’s interesting to read.

it is really good article, I found the reason for my problem!!

Thanks

Thanks for the article. I really enjoyed reading all of your posts.

Thanks for very interesting article.

It's easy to overcome the 15 MB limit - just set the registry value HKCU\Software\Microsoft\Feeds\MaxEnclosureSize (DWORD) to a suitable value (in kB). There is a similar value for the maximum XML size (also 15 MB by default). If you are writing a podcast app that uses the common feed list, this is easy enough to adjust. More details are on MSDN.

@LFERC - Here's what I do:

1. From the command line, type

mklink /j %userprofile%\Music\Podcasts %localappdata%\Microsoft\Windows\Temporary Internet Files\Enclosure"

This will make the podcasts visible to WMP.

2. In WMP, create an auto playlist with a filename that contains "Music\Podcasts".

Now all you have to do is sync that playlist to your audio player. It works great!

now I get the multiple-requests subject. thanks! ;-)

Great article. It`s realy worth reading. I wish you further successes

It's intresting what you did with the security model, but I think you should allow "infinte" sized simple HTTP GET downloads for enclosures that come from the same server who supplied the feed.