Last time I used get_iplayer (V2.79, August 2012) I could easily locate and download Radio 3 broadcasts (episodes of Late Junction to be precise) without any problem. I still have many *'flv or *.aac broadcasts in my on-line music library, under Linux. I say 'download' because they is what that seemed to be: the whole thing would be copied to my PC within a few minutes.

This week I have returned to get_iplayer - now Version 2.85 - with the same version of Ubuntu (12.04) but, even though I can find the latest Late Junction recordings, get-iplayer fails to download them. It has 2 attempts, the second using the option --modes=wma. Both attempts fail.

If I try the same action with latest windows version, under WinXP, then the first attempt fails, as under Ubuntu, but the second attempt succeeds: I end up with a large *.wma file on my PC.

But there is one huge difference from what happened in 2012: download now takes as long as the original broadcast. It seems as if get_iplayer is running as a 'recorder' of the Late Junction episode, which is being broadcast again (but only to me, and, btw, not at the same quality as the original broadcast).

Why is the Linux version failing to download the item?

Why does the Windows version need 2 attempts?

Why does it take so long?

Any suggestion gratefully received

Regards

GreatbRidge

(ps, contrary to appearances, honestly, I'm not a spammer; no, seriously, I'm not; trust me on this. btw would you like some cheap male-virility-enhancing pills? I can do you a good price....)

Don't include wma in --modes. If it was left in your settings from the old version of get_iplayer, remove it. It is not longer included by default, so I presume it's a leftover. WMA downloads are real-time only, as you've seen, so it is useless for anything except live radio.

As for the more general issue of why it failed over to WMA, you've provided no information to work with. Re-run the download for ONE programme only and add the option. Post the output as an attachment. Do not - repeat - do not paste the output into your reply.

OK will do. A further update before I try this: ,y attempts to 'download' in Windows have all failed this evening with similar error messages to Linux.

I have no run get-ip for a single download and look to copy the voluminous out put to an attachment

OK, this forum rejected my attachment; Ill try it with a different file-type

Thanks. The problem is clear from the log:

ERROR: RTMP_Connect0, failed to connect socket. 110 (Connection timed out)

No problems downloading that program here, so presumably there is a network connectivity problem upstream from you. Another possibility is that you have blocked port 1935 (for rtmpdump) outbound on your router. Not much help we can offer in that department, I'm afraid.

One other thing: remove rtmptvopts from your settings as well. That is obsolete.

Thanks for the clear explanation: simply stated (but somewhat less simple for me to fix, I fear); this might also explain why the WinXP download failed too (the router being their only common point)

Router blocked port 1935 OUTBOUND - hmm, don't understand that: why would a blocked outbound port prevent a download (inbound, surely ?) from working?

"remove rtmptvopts from your settings" - I was not aware that there were any user-configurable settings for get-iplayer, nor do I have any idea where I might find them: any pointers?

Ooops_ too quick to ask somebody else to do the work; sorry. I found the options file location by the simple process of "RTFM"

I have now found a work-around to the problem, which has side effects - I assume. I'm writing this up here for the benefit of other Virgin Media (VM) Super Hub users who may be having a the same problem.

Enabling Port Forwarding on Port 1935 (Port number suggested by earlier post), using VN SuperHub Administration, is simple and well documented. Enabling forwarding on this port does NOT fix the problem.

Accessing VM SuperHub settings via <Administration><Security Settings><Firewall> and thnw setting the Firewall 'strength' from its default (Medium) to Low DOES fix the problem, but there is no indication of what additional risks to LAN-side security are thereby introduced. I will access the VM community to get some opinions on this.

Quote:Quote:Thanks for the clear explanation: simply stated (but somewhat less simple for me to fix, I fear); this might also explain why the WinXP download failed too (the router being their only common point)

That was my thought. It seems unlikely you would have done that, but I don't know your setup. Anti-virus can cause the same problem but - given it's happening on Linux as well - that seems less likely. If you're running anti-virus on Windows, you can temporarily switch it off to see it makes any difference.

Quote:Router blocked port 1935 OUTBOUND – hmm, don’t understand that: why would a blocked outbound port prevent a download (inbound, surely ?) from working?

It's outbound because rtmpdump connects from your machine to the media servers.

Another thing to do is to establish the consistency of the problem. Try 5-10 downloads (radio and TV) with , say, 12 hours apart to see if you get exactly the same error message.

You can also check your connectivity outside get_iplayer here (requires Flash):

http://www.therealtimeweb.com/index.cfm/...ort-tester

If test on port 1935 fails, rtmpdump won't work. That would at least confirm the problem is outside get_iplayer and rtmpdump.

Quote:Quote:
Enabling Port Forwarding on Port 1935 (Port number suggested by earlier post), using VN SuperHub Administration, is simple and well documented. Enabling forwarding on this port does NOT fix the problem.

Forwarding would apply to inbound connections, so not relevant here.

Apologies if this is looking like spam.

Further investigation and test shows that I can set VM SuperHub Firewall 'strength' to 'Medium' and still download via get_iplayer - if I set Port Blocking Rules on Port 1635 to 'delete' rather than 'enable'. I assume that the Firewall Medium setting has set the rule for this Port to 'block' but by adding a special rule for this port and setting that rule to 'delete', the port is then unblocked.

But what do I know?

Quote:Another thing to do is to establish the consistency of the problem. Try 5-10 downloads (radio and TV) with

Code:

--verbose

, say, 12 hours apart to see if you get exactly the same error message.

You can also check your connectivity outside get_iplayer here (requires Flash):

http://www.therealtimeweb.com/index.cfm/...ort-tester

If test on port 1935 fails, rtmpdump won’t work. That would at least confirm the problem is outside get_iplayer and rtmpdump.

Thanks for this. I tried the port tester with my latest SuperHub settings (FFirewal strength Medium; Port Block deleted on 1935): success on all tests under Linux (WinXP hors de combat temporarily while I run Vista instead) and downloads work now.

Thanks for guidance.

Does the port tester fail if you revert back to original router settings?

A bit of light googling seems to confirm your findings. AFAICT, if you bump SuperHub firewall to Medium, it blocks all but a few ports outbound. Firewall = Low opens all ports with stateful packet inspection enabled, which seems fine for most people. That apparently is the default, which I guess is why nobody has reported this before. It seems like the higher firewall settings only restrict what you can do with your connection.

I'm afraid that I'm more paranoid than most people (hah! how do I know that, eh, tell me that....) and so I prefer to run with the Medium setting for the Router firewall and I think that I may have found how to leave it that way and still let get_iplayer work (by luck, not by any exercise of skill or knowledge).

However an article on BBC News that I browsed today (in my very securely locked down iPHone) says that routers are,in general, prone to been hacked and certainly have been, very widely, in Poland. So now I'm going back on line to see what firmware updates there are for my device. Don't expect too much from VirginMedia, though...

Quote:<div class="d4p-bbp-quote-title">Quote:</div>Does the port tester fail if you revert back to original router settings?

Quote:<div class="d4p-bbp-quote-title">Quote:</div>Does the port tester fail if you revert back to original router settings?

I haven't explicitly tested it, but the port test failed until I changed the firewall 'aggression' from medium to low and continued to work with the medium setting but port blocking on 1935 deleted. This is not the same as the original settings, I know.