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