Stream corrupt error and then rtmpdump goes nuts!

[Neill Mitchell]

Hi.

I'm running the latest git versions of get_iplayer and rtmpdump on 
Ubuntu 12.10. I am regularly having failures downloading programmes now.

The downloads always fail at 0.1 or 0.2%. About one in 3 downloads are 
now failing. I see the following:

DEBUG: RTMP_ClientPacket, received: invoke 30755 bytes
DEBUG: (object begin)
DEBUG: Property: NULL
DEBUG: (object end)
DEBUG: HandleInvoke, server invoking <_onbwcheck>
DEBUG: Invoking _result
DEBUG: RTMP_ClientPacket, received: invoke 40995 bytes
DEBUG: (object begin)
DEBUG: Property: NULL
DEBUG: (object end)
DEBUG: HandleInvoke, server invoking <_onbwcheck>
DEBUG: Invoking _result
192.827 kB / 0.84 sec (0.1%)
WARNING: Stream corrupt?!
ERROR: Wrong data size (4112373), stream corrupted, aborting!
256.827 kB / 941744.03 sec (155634.7%)
DEBUG: RTMP_ReadPacket, m_nChannel: 76d3
DEBUG: RTMP_ReadPacket, m_nChannel: c6fb
DEBUG: RTMP_ReadPacket, m_nChannel: c1a0
DEBUG: RTMP_ReadPacket, m_nChannel: 15d4
DEBUG: RTMP_ReadPacket, m_nChannel: 7e69
DEBUG: RTMP_ReadPacket, m_nChannel: 37cd
DEBUG: RTMP_ClientPacket, received: bytes read report
DEBUG: RTMP_ReadPacket, m_nChannel: aa6d
DEBUG: HandleChangeChunkSize, received: chunk size change to 4102
DEBUG: RTMP_ClientPacket, unknown packet type received: 0x00
DEBUG: RTMP_ReadPacket, m_nChannel: 7b1d
DEBUG: RTMP_ReadPacket, m_nChannel: a18e
DEBUG: RTMP_ReadPacket, m_nChannel: 8127
DEBUG: HandleChangeChunkSize, received: chunk size change to 554422015
DEBUG: RTMP_ClientPacket, unknown packet type received: 0xb0
DEBUG: RTMP_ClientPacket, unknown packet type received: 0x4f
DEBUG: RTMP_ClientPacket, unknown packet type received: 0xf0
DEBUG: RTMP_ClientPacket, unknown packet type received: 0x63
DEBUG: RTMP_ClientPacket, unknown packet type received: 0x98


and then rtmpdump goes nuts and starts burning 100% of my CPU. Often I 
have to hit the reset button as the PC become unresponsive. Obviously 
this is not good!

There does not seem to be any pattern to it. If the download gets past 
the 0.2% stage then it is always fine. Some sort of threading race 
condition perhaps?

Any ideas?

Thanks!