Audio/Video Out of Sync

[MacFH - C E Macfarlane]

Please see below ...

> -----Original Message-----
> From: get_iplayer [mailto:get_iplayer-bounces at lists.infradead.org] On
> Behalf Of MacFH - C E Macfarlane
> Sent: 14 August 2016 14:19
> To: 'tellyaddict'; 'get_iplayer'
> Subject: RE: RE: Audio/Video Out of Sync
> 
> Just FYI, all overnight downloads have been error-free since that one.

Further just FYI, I've now realised that this was an unwarranted and untrue
claim.  I was searching each night's log for the word 'error', but in fact
the missing segment messages come up as 'WARNING'.  It's not a big problem
now that I've realised my mistake, but I think that message ought to be
changed to 'ERROR', because it means that the resulting file will be
corrupted.

As there are too many other warning messages, I'm now searching for
'segment' instead, and found some messages the day before yesterday in a
Gaelic music programme aired on BBC Alba, so I redownloaded it yesterday,
have just watched it now, and it is corrupt again, and audio/video sync does
indeed get progressively worse after each glitch:
	Ceol Ulaidh/Castle Sessions ;
http://www.bbc.co.uk/programmes/b07pd3mt

So now I must try and find out what others have slipped through the net ...
Grrr!

Good to hear from Jim that things might be fixed soon.

As for the claim that it can't be download rates or server loading causing
the glitches because they are still there when one tries to download a
second time, that doesn't follow.  We know that download rates and/or server
loading are not the problem from Jim's previous information from the BBC,
but not for any other reason.  To explain: if server loading was a problem,
it would affect both storing stuff on the servers and downloading off them
equally unless specific, different runtime priorities have been assigned to
each type of activity.  Thus if the server hiccupped while segmenting and
storing a programme, that error in the resulting file(s) would be found by
each attempted download until the corrupted file(s) was/were recreated
somehow or other, while if the server hiccupped while serving a download,
that would essentially be a one-time error that in principle could be fixed
by redownloading and hoping that the server doesn't hiccup again on the
second attempt.  If download rates were the problem, the second type of
error ought to predominate, whereas in fact the first type predominates  -
the errors seem to occur mostly at the stage of creating the file(s) that
are used as the source of subsequent downloads.