I've had another timeout this morning and have followed your instructions. I will post a bug if you wish but first I'd like to check something.

tcpdump when I killed it reported 11230 packets captured, 17780 received by filter and 6550 packets dropped be kernel. That last one sounds suspicious.

I also noted a few times that when the timeouts were allowing me to make no progress, the only way to recover was to reconnect the wireless. Does the above and this not perhaps point to this being my problem?

This timeout was the second timeout of the session at 56% after one at around 30% which I wasn't capturing. The throughput was much higher during this one, reported at 300KiB/s plus (my service is best in the early morning).

Tapping Download again led to no movement. Cycling offline and online again causing the wireless to reconnect and then tapping Download led to the file resuming at good speed.

This now gets more confusing. it didn't time out again, but it decided it was finished at 97%. I checked the show and it was definitely missing the end.

On deleting the show and trying again to download it it timed out many more times, until one point when I cycled the wireless it went through to 100% in one go.

Here are the headers from the earlier timeout:

GET /shows/RBR-06-19-09.mp3 HTTP/1.0
Host: redbarradio.com
User-Agent: gPodder/0.16.1 (+http://gpodder.org/)
Range: bytes=27574272-

HTTP/1.1 206 Partial Content
Date: Sat, 20 Jun 2009 06:19:36 GMT
Server: Apache/1.3.41 (Unix) mod_log_bytes/1.2 mod_bwlimited/1.4 mod_ssl/2.8.31 OpenSSL/0.9.8b
Last-Modified: Sat, 20 Jun 2009 06:19:36 GMT
ETag: W/"6d04234-4c437ef-4a3c9f0a"
Accept-Ranges: bytes
Content-Length: 52393967
Content-Range: bytes 27574272-79968238/79968239
Connection: close
Content-Type: audio/mpeg

Let me know what you think.

Cheers,
Tom.