Video download problems (Windows Web PVR)

[dinkypumpkin]

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.