It's possible some of the randomness is due to the server that is 'chosen' when an the download attempt is made - using --exclude-supplier=limelight or --exclude-supplier=akamai might shed some light on that.
On 24 June 2015 at 09:53, Jim Lesurf <[email protected]> wrote: > I don't think the following is due to a flaw in gip. But it keeps happening > so I'd like to describe it and invite any comments regarding its cause or > what might be done. > > In general I run a small program to do a set of gip fetches each morning, > timed to complete before the 9am 'deadline' when BT start clocking data > against out 'cap' value. The program simply issues a sequence of command > line fetches using gip. This lets me write a text file which lists the pids > that my program reads and then uses these to issue the fetch commands via > system() one by one. > > Most mornings this works fine. But sometimes it doesn't. > > The most common symptom is that a command line fetch begins, but then halts > with the progress at 0.0%. More rarely, it halts after the Commencing... > > A ctrl-C generally simply causes the command to shut down the process it > had started and go on to the next fetch. This may or may not work. > > A point to make here is that the behaviour seems 'random' in the sense that > often issuing the same command in the same with the same PID shortly > afterward duly works fine. > > Occasionally when I ctrl-C the fetch it generates an 'error'. But again > these seem to vary 'randomly'. i.e. the same program fetch show this on > one try but not on another, or may clean up with no error, or a different > one. In the bulk of cases, a failure simply cleans up without any reported > error. > > I'm raising this now because I initially spent about 10 mins this morning > re-trying the same set of 5 PIDs and they kept failing. Then some worked. > Then some which had still refused worked. Only one persisted in stalling at > 0.0%. By then 9am approached and I was doing other things anyway, so I > stopped for the day. My guess is that if I try to fetch that program later > today it will fetch OK. > > My *guess* is that this is some analogue of 'leaves on the line' or 'the > wrong kind of snow' affecting my connections. I also sometimes get the > 'busy' page from the iplayer using firefox at times. Again, I suspect the > problem is that somewhere along the pipework between me and the BBC > servers enough other traffic is involved to disrupt things. Thus leaving > gip waiting for a packet whist the server is waiting for a request because > something got lost. > > If so, no idea if this is because I live north of Edinburgh, so in a > different world to the LBH machines, or if it is a local problem, or my > ISP. > > Again, most mornings I get no problems at all. Sometimes I get one problem > try. This morning was a struggle. There's no pattern I've noticed. > > Comments? > > Jim > > -- > 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 _______________________________________________ get_iplayer mailing list [email protected] http://lists.infradead.org/mailman/listinfo/get_iplayer
