I've discovered the following problem using banshee (originally discovered in 1.4.1, but I've replicated the problem with the recent SVN version, too):

Always, when a new episode of a podcast was published and banshee tried to download it, it crashed due to a stack overflow.

The reason is, that the following two functions calls each other in an endless recursive loop until the stack is completely filled up:
  at Migo.Syndication.Feed.CheckForItemsToDownload () <0x003c5>
  at Migo.Syndication.Feed.Save (bool) <0x00159>
  at Migo.Syndication.Feed.Save () <0x0000c>
  at Migo.Syndication.Feed.CheckForItemsToDownload () <0x003c5>
  at Migo.Syndication.Feed.Save (bool) <0x00159>
  at Migo.Syndication.Feed.Save () <0x0000c>
  at Migo.Syndication.Feed.CheckForItemsToDownload () <0x003c5>
  at Migo.Syndication.Feed.Save (bool) <0x00159>
  at Migo.Syndication.Feed.Save () <0x0000c>


How to reproduce:
- the problem is in banshee 1.4.1 as well as in the latest (2009-02-05) SVN checkout
- have your linux configured to timezone CET
- subscribe to the following podcast: http://www.tagesschau.de/export/video-podcast/tagesschau
- because the problem is timing related, you have to start banshee e.g. about 9.30pm CET ;-)
- a new episode is usually published around 9.10pm CET
- banshee tries to download it, but at the same time it uses up to 100% CPU due to the loop between the mentioned functions
- after some seconds (once the stack us full) it will finally crash


I've looked into the problem a little bit and I've added some debug to the Migo.Syndication/Feed.cs:

Entering Save, LastBuildData:2/1/2009 11:58:35 PM, LastAutoDownload:2/1/2009 10:05:06 PM
in CheckForItemsToDownload, item.PubDate: 2/1/2009 11:04:28 PM, LastAutoDownload: 2/1/2009 10:05:06 PM
in CheckForItems, attempt to call Save, set LastAutoDownload to: 2/1/2009 10:05:06 PM
Entering Save, LastBuildData:2/1/2009 11:58:35 PM, LastAutoDownload:2/1/2009 10:05:06 PM
in CheckForItemsToDownload, item.PubDate: 2/1/2009 11:04:28 PM, LastAutoDownload: 2/1/2009 10:05:06 PM
in CheckForItems, attempt to call Save, set LastAutoDownload to: 2/1/2009 10:05:06 PM
Entering Save, LastBuildData:2/1/2009 11:58:35 PM, LastAutoDownload:2/1/2009 10:05:06 PM


The dates from banshee (LastAutoDownload) seems to be in localtime.
However, LastBuildData and PubData (which are taken from the rss feed) seems to be wrong.
The original pubDate from the feed is:
<pubDate>Sun, 01 Feb 2009 21:04:28 +0100</pubDate>
So, the date is different between the feed (9.04pm CET) and banshee's interpretation: 2/1/2009 11:04:28 PM.

If dates are compared they should be in the same time zone. According to the other date related functions I assume that banshee usually uses the local time for this purpose (e.g. LastAutoDownload = DateTime.Now;).
This means, that there is a problem in the conversion routing when the rss file is parsed.

So I've looked into Migo.Syndication/Rfc822DateTime.cs:
        public static DateTime Parse (string dateTime)
        [...]
                if (timeZone != String.Empty) {
                    ret += ParseGmtOffset (timeZone);
                }

                return ret.ToLocalTime ();

This routine seems to convert an rfc822 time stamp into localtime:
1. a DateTime object is generated from the plain numbers (localtime at the origin of this number)
2. the timezone offset is _added_ (to get the time in UTC)
3. ToLocalTime() is used to convert the DateTime (which is in UTC) into the local time of the host
However, step 2 is wrong. Assume the example:
<pubDate>Sun, 01 Feb 2009 21:04:28 +0100</pubDate>
1. DateTime object for the date/time 9.04pm
2. 9.04+1h = 10.04pm 
This is intended to be in UTC, but this is wrong.
9.04pm CET = 8.04pm UTC

So, after I've change the code to:
                if (timeZone != String.Empty) {
                    ret -= ParseGmtOffset (timeZone);
                }
it worked fine for me. :-)

here is the corresponding debug output - sorry, that it was for the next day

in CheckForItemsToDownload, item.PubDate: 2/2/2009 9:04:31 PM, LastAutoDownload:
 2/1/2009 11:11:08 PM
 *** in CheckForItems, attempt to call Save, set LastAutoDownload to: 2/2/2009 9:
 50:30 PM
 Entering Save, LastBuildData:2/2/2009 9:49:24 PM, LastAutoDownload:2/2/2009 9:50
 :30 PM
 Entering Save, LastBuildData:2/2/2009 9:49:24 PM, LastAutoDownload:2/2/2009 9:50
 :30 PM
 Entering Save, LastBuildData:2/2/2009 10:54:11 PM, LastAutoDownload:2/2/2009 9:5
 0:30 PM

Ok, final conclusion:

1. The attached patch fixes a bug in the Rfc822 parser.

2. However, it looks like that if a podcast would set its pubDate to the future banshee would still get into a recursive endless loop.
So it is necessary to take additional precaution (e.g. by not letting the pubDate in the future).

I hope I could help with this report and I would be glad if you could apply my fix.

Thanks!