Could GiP handle RTMPDUMP partial downloads better?

[Jeremy Nicoll - ml get_iplayer]

In the last couple of days I've had quite a few tv downloads which have
resulted in incomplete programmes.  The RTMPDUMP output in those I've
examined has contained something like:  

INFO: Connection timed out, trying to resume.

DEBUG: RTMP_SendPause, 1, pauseTime=1028245
DEBUG: Invoking pause
DEBUG: RTMP_SendPause, 0, pauseTime=1028245
DEBUG: Invoking pause
Resuming download at: 189420.574 kB
DEBUG: RTMPSockBuf_Fill, recv returned -1. GetSockError(): 10054 (Unknown
error)
ERROR: WriteN, RTMP send error 10054 (46 bytes)
ERROR: RTMP_ReadPacket, failed to read RTMP packet header
189420.574 kB / 0.00 sec
DEBUG: RTMP_Read returned: 0
Download complete
DEBUG: Closing connection.

INFO: Command exit code 0 (raw code = 0)

INFO: Command: "ffmpeg.exe" "-i" ...

I realise that it's harder for GiP to see a problem when RTMPDUMP stupidly
sets an exit code of 0 (which is meant to signify a successful download)
when RTMPDUMP clearly knows that something went wrong.  

Is there any scope for GiP to trap/redirect output from RTMPDUMP and read it
looking for "ERROR:" literals - or (if they occur in situations that
RTMPDUMP can recover from), look for common fatal problem error messages? 
Or for GiP to sanity check the size of each downloaded file?

-- 
Jeremy Nicoll - my opinions are my own.