HD Video Download Issues

Jeff jefro at coolcave.co.uk
Sun Jan 16 05:48:10 EST 2011

On 15 January 2011 14:01, Robin Bowes <robin.bowes at yo61.com> wrote:
> On 14/01/11 11:45, Mikey O'Toole wrote:

> I saw sometihng similar last time I tried to download an HD stream
> (Jools' Hootenanny). See the "Annoying Download Problem" thread.
> I didn't find a resolution - I just kept re-trying and it eventually
> downloaded the whole thing.

This is exactly what I found in the past, however I am wondering if
this is something different as a  few programmes consistently fail to
download now.

Howard Chu, when responding to the suggestion that there was a bug in
RTMPDump relating to a test of this problem said in


fs ck wrote:
> OK, I found there is a bug of some sort. Maybe FMS behavior has
> changed as this was not happening to BBC iPlayer streams until
> recently. (my previous post is probably worth ignoring as I think this
> is the root cause)
> Using latest r555 (although this happens with v2.3 in my tests also)
> on ubuntu 10.10 amd64.
> Here is how I can reproduce the problem:
> I use get_iplayer using following cmd:
> get_iplayer --modes=flashhigh 'bbc weather' -g --debug
> I partially download the file to, say, 34 seconds into a 148 second
> program by using 'ctrl-c'.
> I now have an flv file
> BBC_Weather-07_01_2011--b00x8cmb-default-flashhigh.partial.mp4.flv of
> size 3683570 bytes. It got to "3403.710 kB / 34.920 sec (23.4%)"
> I then re-run the same get_iplayer command
> It says "Resuming download at: 3403.710 kB / 34.920 sec (23.4%)" which
> is expected.
> It then errors twice with "WARNING: Stream does not start with
> requested frame, ignoring data..."
> Then proceeds to download the resumed stream at the end of the partial flv file.
> The problem is that the percent counter (and seconds counter) both
> erroneously start from zero.
> We then get problems when the rtmp stream is completed because
> rtmpdump is still expecting the final 23.4%. It reports "14359.304 kB
> / 113.76 sec (76.4%)" but actually it has it all.
> If I playback the file all the video is there but of course the player
> gives loads of errors because the timestamps are wrong.
> Basically the resume doesn't initialize the TS offset correctly for
> the resumed frames. I cannot determine whether this is due to FMS
> mis-reporting the TS or rtmpdump not setting it correctly.

rtmpdump doesn't create the timestamps, it just records what the server sent.
> Either way this causes havoc and endless retries in get_iplayer !!

Then get_iplayer is broken. It should be checking for a return code of zero
from rtmpdump and stopping at that point. rtmpdump will exit with code zero if
it gets a "Play Complete" message from the server, and the server always sends
that if it reaches the end of whatever it was playing.


According to him it appears there is a bug in get_iplayer

More information about the get_iplayer mailing list