Random stalling

[Steve]

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 <web at audiomisc.co.uk> 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
> get_iplayer at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer