Level3 CDN issue affecting RTMP HD downloads

[Jim web]

Afraid I didn't realise there was a wider problem (i.e. one extending over
the net more generally). Didn't see it in the earlier links I followed up
I'm afraid.

To me the current gip difficulties have two distinct symptoms.

1) That when I try to use akamai it tends to fail with 'random' error
messages at the start of the process. This has been the case for a long
time. i.e. since well before the start of this week. Hence by default I'd
changed to excluding akamai as a supplier. Which then led me into the new
symptom...

2) That limelight now seems not to serve 1280x720. So if I keep excluding
akamai I can only get 832x468... But if I include akamai I usually now get
the very familiar symptom (1).

In essence I've had to deal with (1) for a long time but my workaround for
it is now banjaxed by (2) !

In practice (1) seems dominated by some kind of confusion near the start of
the fetching process. As if packets are arrving out of order or with
unexpected content during the first second or two. Once I get the
percentage fetched to clock up steadily for a few seconds the fetch will
probably run on to completion OK.

I did try HLS but it was hopelessly slooooow. Not really usable, but I've
still not upgraded from 2.93 to 2.94 to see if that speeds up HLS. And am
wondering if I should simply await 2.95 which I hope will deal with the
above. Fingers crossed! :-)

In practice what I'm doing therefore is to repeatedly retry accessing
without excluding akamai and asking for tvmode=best. It seems to average
out around 70 - 90 percent of attempts fail in the first fraction of the
fetch. But in a minority of cases the fetch continues and runs to complete
OK at my usual rate of about x10 real time for 1280x720 files.

In the past I came to think of this behaviour as being like the weather,
and take now as "severe storm". It is a pest as I have to ctrl-C to abort
gip each time and then re-try by hand. 

On one occasion this morning a retry gave me *two* different versions of a
program from one gip command. The first was 1280x720 but the first fraction
of a second was corrupted and the 'partial' flv file wasn't converted.
Instead gip went straight on to get me the 832x468 version. I wonder if it
chained versions from akamai then limelight for some reason.

However the 'corrupted' version also have obvious lip synch problems. But
using ffmpeg I snipped the first second off it when converting to mp4 and
the result seems OK.

If a fix isn't imminent: Is there a gip 'timeout' option I don't know about
that will kill an attempt after, say, 20 seconds with no futher stream or
upon a warning/error that is 'terminal'? I could then simply have a list
tried to the end, then retry that weeded down rather than having to do
every fail and retry by hand.

Jim

In article
<PHEAIHCMJKHMHMOFBPOGOEOGCKAA.c.e.macfarlane at macfh.co.uk>, C
E
Macfarlane <c.e.macfarlane at macfh.co.uk> wrote:
> If you've read any of the associated links about the wider problem, you
> won't be surprised to hear that when, being unable to sleep, I came down
> in the middle of the night to check the progress of reconciling my NASs
> after a HD crashed in one, and, my laptop having finished backing up, I
> relaunched my browser, barely a tab loaded, all the rest gave "Server
> not found" messages, including ALL the BBC ones, even the weather, news,
> etc.

> www.macfh.co.uk/CEMH.html

-- 
Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc  http://www.audiomisc.co.uk/index.html