Red Button now on iPlayer

RS richard22j at zoho.com
Mon May 15 07:47:15 PDT 2017


>From: tellyaddict
>Sent: Monday, May 15, 2017 14:18

>I'm not sure if my output is the same as yours because they can vary but my 
>verbose output for --info on b08r3nv4 tells me that hvfxsd2 comes from 
> >Limelight which seems to be quite a slow server and this is from past 
>experience as well.

>I can't really comment on hvfxsd1 which comes from Bidi because Bidi is a 
>new server to get_iplayer and I haven't had much chance to try it yet. Your 
> >test indicates though that again it may well be a slow server but 
>marginally faster than Limelight.

>Both hlsvhigh1 and hvfxsd5 are served by Akamai. Akamai is by far the 
>fastest server out there which would explain why you got good results with 
>that >mode set in your command.

hvfxsd2 is indeed Limelight.  The sequence is
1 Bidi https
2 Limelight https
3 Bidi http
4 Limelight http
5 Akamai http
6 Bidi https
7 Akamai http
8 Limelight http
9 Bidi http

I seem to remember Vangelis's saying that Akamai was faster than Limelight, 
but I didn't realise the difference was so great, although I have had a 10 
to 1 difference in radio modes.  In this case 4 sub-modes would need to fail 
before Akamai was reached if a sub-mode was not specified.  I was thinking 
it would be necessary to work out a pattern, but if it can change that's no 
good.

I should have read the release notes for v3.00 more carefully.  They mention 
the Bidi CDN.   Also there is a reminder about --exclude-supplier so we 
could use
--exclude-supplier=limelight,bidi
although Vangelis says here
http://lists.infradead.org/pipermail/get_iplayer/2016-January/008576.html
a different form may be needed for DASH.





More information about the get_iplayer mailing list