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 <[email protected]>, C E Macfarlane <[email protected]> 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 _______________________________________________ get_iplayer mailing list [email protected] http://lists.infradead.org/mailman/listinfo/get_iplayer
