[cheche]

if a download takes too long rtmpdump (http://all-streaming-media.com/record-video-stream/rtmpdump-freeware-console-RTMP-downloading-application.htm) exits with this message:
Caught signal: 13, cleaning up, just a second...
ERROR: WriteN, RTMP send error 32 (42 bytes)
ERROR: RTMP_ReadPacket, failed to read RTMP packet body. len: 68763
20194.415 kB / 134.13 sec (59.5%)
Download may be incomplete (downloaded about 59.50%), try resuming

errno 32 is EPIPE. the error appears both compiled with openssl or gnutls (not tested with polarssl).
the Wireshark (http://all-streaming-media.com/find-stream-URL/Wireshark-free-network-protocol-analyzer.htm) trace looks like this:
http://img299.imageshack.us/img299/6445/wireshark.png

if i play the video with the player on the website it doesn't cut the connection.
rtmpe link:
rtmpe://cp10740.edgefcs.net/ondemand/mtvnshrdstor/_!/mtvi/bands/j/juvenile/drop_that_thang_full_640x360_1200.mp4
swf player:
http://media.mtvnservices.com/mgid:uma:video:mtv.com:526372

thanks in advance

[cheche]

if i resume the download the file is corrupted
thanks in advance

[Ed999]

I am using RTMPDUMP v2.1d on Windows 98. Later versions of the software may differ, particularly if run on a different Operating System.

The RTMPDUMP program provides a number of options that might help you with the type of problem described above.

The obvious switch to add to the Command line is --resume to force a resumption of a partially downloaded RTMP file. But you can also use it with the --timeout 10 switch, to reduce the length of time before the connection times out (in this example, it would time out after 10 seconds of inactivity).

The significance of the --timeout switch is that, in my experience (others may differ), letting the connection sit open for the default period of 120 seconds is an open invitation to the RTMPDUMP program to crash. The shorter the timeout period, the fewer times it crashes on me.

A typical crash closes the file being downloaded improperly, typically corrupting either the file header or the last frame that was downloaded before the cut-off occured. If the crash only corrupts the last frame, you can use the --resume switch by also adding the switch --skip 1 to skip the last 1 frame when resuming. You can try any number, e.g. --skip 10 will skip the final 10 frames when resuming. This will get your download going again.

If the crash corrupts the file header, so that it gives a (false) file size that is greater than the file size on the RTMP server, then you can't resume the download under any conditions, because the server deems you to have got the full file already.

However, I recommend this trick: if your download stops, copy the file to another directory (e.g. to the Desktop) before trying to resume. If you are successful on the resume, you've now got a partial download up your sleeve. Do this EVERY TIME the download breaks!

If the download now crashes, you have made yourself a file that you can use to resume from the point where the last non-fatal break occured. Just delete the broken partial download file, and then copy (note: COPY, do NOT move!) the last backup from the Desktop, to replace it. This way you don't go back to the beginning every time. You've always got in hand a partial download to resume with.

I find that, on average, only about one break in six is a fatal crash (only of RTMPDUMP, not of Windows!) that corrupts the file. So I find this trick quite effective.