Hi - this is the output I get when trying

Really? You couldn't be bothered to excise the 120 lines generated because you mistyped the command?

OP's post has now been edited to remove unnecessary lines.

Darren13 - perhaps you can sympathise with user-2, you obviously didn't want to read for yourself the voluminous output you posted here or you would have seen the very obvious connection time out. Noticing that would have lead you to the numerous posts on this forum and around the web describing the sensitive nature of RTMPdump and how it often has these sorts of issues for no good reason.

When posting this sort of information you should, at the very least, wrap the pasted info in code tags so it displays in some sense of order. This can be done by selecting the text and clicking the 'code' button available in strip above the input box.

For large outputs you should paste the output into a text file, save it as a .txt and attach it to your post.

Apologies for the snark.

Bottom line: rtmpdump is guaranteed to fail sometimes, and it doesn't always signal to get_iplayer that it failed, thus you're left with a truncated file. Read about the option in the 2.87 release notes. It gives you an easy way to see that a file was truncated.

Appreciate the apology, but no offence taken. It's a support forum, it's not like it's going to wreck anyone's life ;-)

I've no idea what's relevant for you re: debugging / spotting stuff that isn't an error. I did take time to look through what I was pasting as feedback, but it's all Greek to me.

Again, grateful for get_player, so thanks for your efforts, and apologies for the 120 lines that caused you offence.

I take issue with the way that the RTMP_ReadPacket function is implemented in 2.3 and 2.4. I have the same problem that you do, so I changed a few lines of code and it works much better. The first time I used it and got that error...it retried about 24 times, got the right packet and went merrily on its way. No CPU spinning out of control, no retrying, no corrupted file. Forgive me if I think the code was just written wrong.

You can get the code from sourceforge, untar the archive and set up a compile directory. I'm going to assume you can find out how to compile or that you don't want to, but for those that can/will, these are the changes to the code.

All the changes are in librtmp/rtmp.c There are only about 3 lines of changes, but I'll include all of both affected functions so you don't have a problem finding where the change is.

EDIT: new code attached to following post

Crap; I just realized I could have attached the new code. It's just the one file to be changed, librtmp/rtmp.c You can overwrite it with this one, recompile and Bob's yer uncle!

BTW, if you're ever recording something like a live sporting event, this is a really critical change. I do 8 hour cricket matches, the four day SS in Australia, and the last thing you want is to come into the room 4 hours into the match to hear the CPU fan cranked to max and nothing being recorded. With this fix you miss about 30 seconds, no tight loops.

Did you really get that code from SourceForge? If so, you should provide the link. The diff between your code and the upstream master branch is way more than 3 lines, and your code reintroduces one bug that was patched 18 months ago, so I think you patched a rather old version. That doesn't mean it won't work for some people, but you should say exactly where you got the code you patched, so that anyone who applies your changes is forewarned that old bugs might resurface. But you really should patch the latest source.