This occurs with all of my podcasts using RC-1 as well. The download starts, but never finishes.

I can confirm all valid podcasts cease to download after 60 seconds.

Confirming this as well running 1.2 from the official Banshee repos for Hardy.

There were some problems with CacheFly servers about two months ago (not Banshee related, all HttpWebRequests were failing.)  I'm running the Hardy 1.2.0 packages as well and I'm not having any issues downloading episodes.

I can also confirm that I'm seeing this issue with 1.2.0 on openSUSE 11.0. It doesn't appear to be related to the CacheFly issue, as this is with all podcasts (not just those hosted on CacheFly) and it does appear to be random, but I'm noticing some patterns that can cause it to almost always fail: 

1. If it's a large podcast file. So video podcasts are out of the question, even longer/larger-sized audio podcasts will fail after a certain amount of time.

2. If it's downloading multiple podcasts, usually every one except for one will fail, and one will be downloaded. Other times I've seen it fail on every one. What I have never seen it do is download all of them (and by multiple I mean as little as two in some cases)

3. It's (usually) random. Often I'll try to download a podcast and it will fail the first time, but the second time it completes the download. But occasionally it will continue to fail, time after time (again, usually happens with the larger podcasts).

4. I can stream these files. That's the screwy part to me ;-), I can stream a whole podcast that Banshee can't download.

Hope that helps with trying to figure out this issue ;-).

That's a pretty fair description of what I'm seeing as well.  This bug is my only real remaining frustration with Banshee, though it still rocks enough that I use it over all competitors :)

For example, NPR's "This American Life" will consistently fail to download the day it's released (when, presumably, their server is pegged).  The next day, however, when the download speed is 5-10x faster, it completes with no problem.

Their feed is at http://www.thisamericanlife.org/podcast.xml

I suppose there's a bug and a feature request in this.  The bug, obviously, is the failed download.  The feature request would be for partial downloads to be squirreled away in a temp directory somewhere, and resumed on the next attempt.

*** Bug 563376 has been marked as a duplicate of this bug. ***

*** Bug 541618 has been marked as a duplicate of this bug. ***

Still present in 1.4.2, highly annoying. Needs investigation.

*** Bug 573901 has been marked as a duplicate of this bug. ***

I was able to reproduce this several times with the feed given by the last duplicate :
http://www.astrosociety.org/education/podcast/sval.xml

The network captures show that the server sends a RST packet, which abruptly closes the connection.
I don't know what banshee sees in that case, will try to keep digging.

Is it possible that Banshee is having problems with slower connections?  I recently upgraded to Verizon FiOS with 10 Mb/s down and Banshee has yet to fail in downloading any podcasts, whereas my previous 1.5 Mb/s DSL line would fail 90% of the time.

Created attachment 129973 [details] [review]
Do not swallow exceptions

It turns out that the download code was explicitly ignoring exceptions in a specific place.
This patch changes that, so that in this case the download is handled as a failed one : the item is not marked as downloaded, the file is not saved.
The exception is written to the log file. The one I'm seeing is :
System.IO.IOException: EndRead failure ---> System.Net.Sockets.SocketException: Connection reset by peer

Please test this patch and confirm if you were seeing the same problem.

I rolled up a 1.4.2 rpm with this patch and tried downloading. The following is seen when running with --debug

 HttpDownloadTask The Silicon Valley Astronomy Lectures Podcasts - Prospecting for Water on the Moon: The Upcoming LCROSS Mission Error:  System.IO.IOException: EndRead failure ---> System.Net.Sockets.SocketException: Connection reset by peer
  at System.Net.Sockets.Socket+SocketAsyncResult.CheckIfThrowDelayedException () [0x00029] in /builddir/build/BUILD/mono-2.2/mcs/class/System/System.Net.Sockets/Socket.cs:146 
  at System.Net.Sockets.Socket.EndReceive (IAsyncResult asyncResult, System.Net.Sockets.SocketError& errorCode) [0x00074] in /builddir/build/BUILD/mono-2.2/mcs/class/System/System.Net.Sockets/Socket.cs:2387 
  at System.Net.Sockets.Socket.EndReceive (IAsyncResult result) [0x00000] in /builddir/build/BUILD/mono-2.2/mcs/class/System/System.Net.Sockets/Socket.cs:2363 
  at System.Net.Sockets.NetworkStream.EndRead (IAsyncResult ar) [0x00017] in /builddir/build/BUILD/mono-2.2/mcs/class/System/System.Net.Sockets/NetworkStream.cs:316 
  --- End of inner exception stack trace ---
  at System.Net.Sockets.NetworkStream.EndRead (IAsyncResult ar) [0x0002a] in /builddir/build/BUILD/mono-2.2/mcs/class/System/System.Net.Sockets/NetworkStream.cs:318 
  at System.Net.WebConnection.EndRead (IAsyncResult result) [0x0006f] in /builddir/build/BUILD/mono-2.2/mcs/class/System/System.Net/WebConnection.cs:746 
  at System.Net.WebConnectionStream.EndRead (IAsyncResult r) [0x0003c] in /builddir/build/BUILD/mono-2.2/mcs/class/System/System.Net/WebConnectionStream.cs:356 

I've come across no errors or problems with this patch: podcasts are downloading and playing as expected without it resetting mid-download.

Tried the patch against 1.4.3 and now I can confirm that it works.

and when will I learn to test more than one download before confirming. A number of the Silicon Valley podcasts do not get added to Banshee's database (don't get the little blue dot), but they do download. 

[Warn  00:36:08.413] HttpDownloadTask The Silicon Valley Astronomy Lectures Podcasts - Estimating the Chances of Life Out There Error:  System.IO.IOException: EndRead failure ---> System.Net.Sockets.SocketException: Connection reset by peer
  at System.Net.Sockets.Socket+SocketAsyncResult.CheckIfThrowDelayedException () [0x00041] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/Socket.cs:149 
  at System.Net.Sockets.Socket.EndReceive (IAsyncResult asyncResult, System.Net.Sockets.SocketError& errorCode) [0x00074] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/Socket.cs:2398 
  at System.Net.Sockets.Socket.EndReceive (IAsyncResult result) [0x00000] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/Socket.cs:2374 
  at System.Net.Sockets.NetworkStream.EndRead (IAsyncResult ar) [0x00017] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/NetworkStream.cs:316 
  --- End of inner exception stack trace ---
  at System.Net.Sockets.NetworkStream.EndRead (IAsyncResult ar) [0x0002a] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/NetworkStream.cs:318 
  at System.Net.WebConnection.EndRead (IAsyncResult result) [0x0006f] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net/WebConnection.cs:749 
  at System.Net.WebConnectionStream.EndRead (IAsyncResult r) [0x0003c] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net/WebConnectionStream.cs:395 
[Warn  00:37:30.342] HttpDownloadTask The Silicon Valley Astronomy Lectures Podcasts - Dark Energy and the Runaway Universe Error:  System.IO.IOException: EndRead failure ---> System.Net.Sockets.SocketException: Connection reset by peer
  at System.Net.Sockets.Socket+SocketAsyncResult.CheckIfThrowDelayedException () [0x00041] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/Socket.cs:149 
  at System.Net.Sockets.Socket.EndReceive (IAsyncResult asyncResult, System.Net.Sockets.SocketError& errorCode) [0x00074] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/Socket.cs:2398 
  at System.Net.Sockets.Socket.EndReceive (IAsyncResult result) [0x00000] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/Socket.cs:2374 
  at System.Net.Sockets.NetworkStream.EndRead (IAsyncResult ar) [0x00017] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/NetworkStream.cs:316 
  --- End of inner exception stack trace ---
  at System.Net.Sockets.NetworkStream.EndRead (IAsyncResult ar) [0x0002a] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net.Sockets/NetworkStream.cs:318 
  at System.Net.WebConnection.EndRead (IAsyncResult result) [0x0006f] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net/WebConnection.cs:749 
  at System.Net.WebConnectionStream.EndRead (IAsyncResult r) [0x0003c] in /builddir/build/BUILD/mono-2.4/mcs/class/System/System.Net/WebConnectionStream.cs:395 

David, are you sure those are fully downloaded?  Seems weird they would be considering the "Connection reset" error.  Can you wget an episode and compare file sizes?

Bertrand, your patch doesn't fix the connection/underlying problem, right?  Just prevents it from being ignored and it looking like the download worked?

(In reply to comment #18)
> Bertrand, your patch doesn't fix the connection/underlying problem, right? 
> Just prevents it from being ignored and it looking like the download worked?

Yes, that's it.
I don't know if there's much we can do if the connection is prematurely closed by the server. Except restart the download, maybe ?

Ok, thanks.

This bug is a good argument for not developing software 10 minutes at a time.

When I look at those lines I just see a haze.  I could have looked at the code 1000x (and probably have over the last three years) and completely ignored that code block every time.  

Thanks for tracking this down.

Those 12 lines have a story and need to be addressed.  Unfortunately, any of the fixes are going to take a good chunk of time to do right.

I committed my patch.
I'm keeping this bug open, because this still needs to be properly fixed.

I recompiled banshee w/ the above patch, I'm seeing warning like these:

[Warn  15:20:45.860] HttpDownloadTask WNYC's Radio Lab - Open Outcry Error:  System.Net.WebException: The operation timed out

even when there's no apparent lost of connectivity. 

I wonder how gPodder works out these issues.

Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address.  It's usually quite apparent who is working on a given bug by the comments and/or patches attached.

Anybody still having issues with this?  If so, can you please include the log messages (or just attach the whole log)?

I think that I've been having this problem. I have worked around it by increasing the HTTP timeout from 1 minute to 5 minutes:
diff --git a/src/Libraries/Migo/Migo.DownloadCore/HttpFileDownloadTask.cs b/src/Libraries/Migo/Migo.DownloadCore/HttpFileDownloadTask.cs
index d84586c..4bb1acd 100644
--- a/src/Libraries/Migo/Migo.DownloadCore/HttpFileDownloadTask.cs
+++ b/src/Libraries/Migo/Migo.DownloadCore/HttpFileDownloadTask.cs
@@ -344,7 +344,7 @@ namespace Migo.DownloadCore
                 //Console.WriteLine ("Adding Range:  {0}", wc.Range);
             }
 
-               wc.Timeout = (60 * 1000);
+               wc.Timeout = (5 * 60 * 1000);
                wc.DownloadFileCompleted += OnDownloadFileCompletedHandler;
                wc.DownloadProgressChanged += OnDownloadProgressChangedHandler;
                wc.ResponseReceived += OnResponseReceivedHandler;       


There's another problem though. Once a podcast has failed to download I can't get it to try again without quitting. Asking Banshee to download it again silently fails.

Thanks, Ian; committed.  This will be in our 1.5.6 release, which hopefully I'll get out today.

I filed bug #613427 for the must-restart-to-re-download issue.

I'm going to close this bug.  Please re-open if any of you still have issues with git master or >= 1.5.6.