Large downloads slowing/stopping as they progress

[Vangelis forthnet]

On Sat May 9 10:02:59 BST 2015, Jim web wrote:

>> Was using --start 02:00:00 to avoid having to  fetch
>> a file for a program that was over 4 hours in total.
>
> This time with a start at 2:45:00, as the previous try
> had provided me with the section from 2h to about 3h.
> ... I was getting a looping error
> File contains neither video or audio exit code 1 (raw code = 256)
>
> So I did a ctrl-C and shut the terminal, then looked at the resulting flv.
> As came, it will play with VLC, but as with earlier results, showed the
> wrong duration and would crash out if I tried to jump to a later section
> whilst playing.

 Hi Jim...
This is a known issue with "flash" modes (both TV & radio) when
one attempts partial recordings of a programme by using either
--start, --stop or both; please read issue #137of the GitHub
issue tracker at:
https://github.com/get-iplayer/get_iplayer/issues/137

It is down to rtmpdump; the resulting FLV file has wrong metadata
(headers) written to it when --start is used... Better avoid --start
then with flashmodes... You should better try the HLS modes
instead (flashvhigh -> hlsvhigh - NB: No hlshd mode with GiP 2.92)!
Do note that the HLS modes use ffmpeg (not rtmpdump) and
take (much) longer to fetch...
I am not permitted to access TV files, but with the command:

perl get_iplayer-292.pl --type=radio --pid=b05tks7z --modes=hlsaac --start 
3600 --stop 7200 --force --tag-podcast-radio

I got me a perfectly playing recording of the "middle" hour of a 3hr long 
radio show...

NOTE TO DINKYPUMPKIN:
The help file for 2.92+ needs to be amended to reflect
that --start & --stop could be applied for HLS;
currently, under "Recording Options" both switches
are marked as "rtmp and realaudio only".

> I guess this may be the norm for the raw flv's?

Raw FLVs play fine with any decent software player
when they are the result of a complete (full) download
of an on-demand file; when --start (other than 0) was
employed, expect problems with seeking/incorrect
duration reported etc.
If for some reason you want to stick to that "partial"
FLV, there are ways to fix the bad metadata injected
by rtmpdump - if your system has PHP installed (I
know many Linux flavours have - also MacOS),
excellent results have been reported by using KSV's
(a Russian developer) FlvFixer.php script:

https://github.com/K-S-V/Scripts/raw/master/FlvFixer.php

Then simply run:

php FlvFixer.php --in problem.flv --out fixed.flv --nometa

Else, as you've already found and Roger correctly pointed out,
a lossless change of container (remux) will create a trouble-free
(hopefully) new file; personally I choose to extract both video &
audio elementary streams with FLVExtract and then mux to MP4
via MP4Box, but this is just me...

Regards,
Vangelis.