On 16/01/2013 19:32, Vangelis forthnet wrote:
wifi connection specifics...) failed and, to add insult to injury, GIP
assumed that the download was complete! Here is the console output:
[...]
262933.750 kB / 1431.96 sec (40.6%)
ERROR: RTMP_ReadPacket, failed to read RTMP packet body. len: 68430
262933.750 kB / 1431.96 sec (40.6%)
INFO: Connection timed out, trying to resume.
Resuming download at: 262933.750 kB
WARNING: HandleInvoke, Sanity failed. no string method in invoke packet
262933.750 kB / 0.00 sec
Download complete
Notice that when rtmpdump tried to resume, it assigned the already
downloaded 256.77 MB a timestamp of 0.00 sec (instead of the
correct timestamp 1431.96 sec (40.6%) at the point of connection
outage...).
The "0.00 sec" just means that rtmpdump couldn't find a timepoint in the
file to resume the download. The "Download complete" is of course
misleading here. In this case it really means that rtmpdump couldn't
figure out what was wrong and exited without setting an error code.
Also, the resume point wouldn't be exactly 1431.96 sec because rtmpdump
has to seek to the last usable keyframe before resuming.
From then on I proceeded by first renaming what had already been
downloaded, from FOO.flv to FOO.partial.flv - used the --raw option in
the initial command, and run a second time the same command in GIP;
the partially downloaded file was recognised, download resumed
correctly.
But when the next connection time-out happened
(when 83% of the stream was dumped), rtmpdump exhibited the same
faulty behaviour by saying that the by then downloaded chunk was only
40.5% of the full file, see this console excerpt:
537334.080 kB / 2927.00 sec (83.0%)
ERROR: RTMP_ReadPacket, failed to read RTMP packet header
537463.356 kB / 2927.64 sec (83.0%)
INFO: Connection timed out, trying to resume.
Resuming download at: 537463.356 kB / 1431.600 sec (40.5%)
537463.356 kB / 1431.60 sec (40.5%)
Download may be incomplete (downloaded about 40.50%), try resuming
INFO: Command exit code 2 (raw code = 512)
The "1431.60 sec" is the timepoint where rtmpdump attempted to resume
the stream, and that is 40.5% of the total length of the programme. The
"537463.356 kB" is just the size of the file on disk at the time
rtmpdump attempts to resume the stream. It isn't correlated with the
timepoint where rtmpdump resumes, so isn't correlated to the percent
complete value. This looks like an extreme case, but as you can see
from your log rtmpdump couldn't use 1431.60 sec as the resume point
since it threw an error and quit. Why it tried to use that value, I
can't say. It was the point at which the original download was
truncated, but that might mean nothing. The next attempt resumed at
2925.760 sec, which was the correct timepoint.
My current win32 rtmpdump binary
(rtmpdump-2.4-pu-81-g2872601-x86-static.svnpenn.20130103),
now sadly taken off-line by its author, does not suffer from this.
I can build from Steven Penn's code (assuming he keeps it available),
but you haven't demonstrated that it would behave any differently with
the sequence of errors in your test download. To be fair, the problems
you encountered with timeouts and garbled data aren't exactly
repeatable, so this would be difficult to demonstrate.
This time around, GIP (not rtmpdump!) retried successfully to
resume downloading & the stream was eventually fully dumped.
This is what normally happens in most cases. The times when rtmpdump
gives up without setting an error code and issues "Download complete"
are fairly rare. It may not be pretty, but AFAICT rtmpdump is working
as designed.
_______________________________________________
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
