I also have the same issue and it is due to poor internet connection in my case, I have just got used to quickly running forward to the last few minutes of the program to ensure it is complete.
All the best Ian On 26 March 2014 07:15, dinkypumpkin <dinkypump...@gmail.com> wrote: > On 26/03/2014 08:17, Dave Widgery wrote: >> >> Finally Peter, I have had a look at the --raw switch and I am not sure how >> this will help, unless I have misunderstood this will leave all my >> downloads >> in the format xxx-partial.mp4.flv whether they have successfully >> downloaded >> or not, at least at the moment I know that the xxx-partial.mp4.flv haven't >> downloaded correctly and the ones converted to mp4 might have downloaded >> correctly. > > > As you say, --raw won't help you. Your problem is that your connections are > being dropped, most likely by your VPN. Others have had the same problem. > But rtmpdump can't always detect that a stream was dropped. And when > rtmpdump exits without error, get_iplayer doesn't know any different. Skip > --raw and let ffmpeg re-mux the .flv file as normal. The output from ffmpeg > contains the duration of the input file, which should tell you whether or > not the file is complete. > > >> Is there a way of finding out the predicted download size so I can compare >> it with the resultant file? > > > Estimated mode sizes can be viewed with --info, but don't bother. The > estimates can be off by 10%. There is a nominal duration value in the > --info output that is usually more accurate, but then you already know how > long the programme should be. > > > > _______________________________________________ > get_iplayer mailing list > get_iplayer@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/get_iplayer _______________________________________________ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer