Recent patches & proxy servers

[dinkypumpkin]

On 24/10/2012 17:17, John Crisp wrote:
> In the Search section with the plugin enabled if I right click Play and
> copy the link, or click to open it, the URL is as follows :
>
> http://my.server.net/iplayer/get_iplayer.cgi?ACTION=playlist&SEARCHFIELDS=pid&SEARCH=b01myl0t&MODES=flashaachigh%2Cflashaacstd%2Cflashaudio%2Cflashhigh%2Cflashstd%2Cflashnormal%2Crealaudio%2Cflashaaclow&PROGTYPES=tv&OUTTYPE=out.flv&STREAMTYPE=&BITRATE=&VSIZE=&VFR=
>
> With the plugin disabled I get the downloaded file with both Firefox and
> Chrome.

The above URL (which is correctly formed for a "Play" link) produces a 
M3U playlist which, depending on your browser settings, will either be 
downloaded as file or launched directly by a configured application or 
plugin.  If your plugin is somehow messing with the links in your 
browser, that's not nice.  I think that is irrelevant, though.  If you 
click a "Play" link in the search results and the result is an M3U 
playlist containing a correctly-formed URL - which is what you get 
AFAICT - the web pvr is working correctly.

> If I open the downloaded 'get_iplayer.cgi' (which is actually the
> palylist) It only show an icon and won't play, but I suspect that it is
> down to the following....

This is what you need to investigate.  The playlist just contains a URL 
pointing back to your web pvr.  When that URL is accessed by VLC, etc., 
the web pvr forks get_iplayer to access the stream from the iPlayer 
site, transcodes it (if default settings on), and pipes the stream back 
to the client connection managed by Apache.  That's why I said you need 
to check the Apache logs to see what happens when the web pvr attempts 
to perform that processing.  You should also set "verbose 1" in your 
options file before testing.  You need the verbose output to catch 
authentication errors from the media servers.  Several things could go 
wrong, so until you see the server logs, you can only guess at the cause 
of your problem.

> My guess that the proxy is used for recording, but isn't used for
> streaming, would appear to be correct though I am not sure why this
> would be the case.

That's not the case.  If the proxy option is set, get_iplayer uses it 
when necessary.  As far as proxy use is concerned, there is no 
difference between recording and streaming.

> I have used get_iplayer on the command line to record via my proxy, and
> can stream via a normal web browser with a manual proxy connection. I
> have done it this way for a while but I thought I would try and use the
> web interface so it was all nicely integrated.
>
> I would still have thought that get_iplayer itself when  called via the
> cgi would have picked up the proxy from the options regardless but I
> presume it is 'selective' when it uses it.

I would bet it does pick up the setting correctly, but it's unrelated to 
your problem.  You still haven't demonstrated the proxy option (or lack 
thereof) is the reason your "Play" link isn't working.

> Any way that the streaming COULD have an option to use a proxy ? I'd
> just like to use the web interface for it all !!!!

If you're recording, the output is dumped to a file.  If you're 
streaming (via "Play"), the output is written to a network socket. 
That's the only real difference.  The proxy option is irrelevant to 
media server access.