Download speed and progress indicator

[RS]

From: Ralph Corderoy
Sent: Tuesday, November 7, 2017 5:25 PM

>Do you physically sit at all of these machines' screens, or access some
>over a network?  What OS are they running?  If Linux, are you using the
>same terminal emulator on all of them?  xterm(1) is a good standby for
>testing.

Hi Ralph and Jeremy

Thanks for the repIies.  I am looking at the screens directly, not over a 
network.  The OS is Windows 10.  The terminal emulator is the Windows 
command prompt.

From: Jeremy Nicoll - ml gip
Sent: Tuesday, November 7, 2017 5:46 PM

>> The relevant code seems to be between lines 7206 and 7224.  It calls
>> main::logger with a string formatted by sprintf.  If I don't set
>> --verbose, so the else code is executed, all machines display a single
>> continuously updated line.  In both cases the line appears from the
>> code to end with CR LF unless {crlf} doesn't mean what it appears to.

>It doesn't mean what it looks like.  There a line of code (in 3.06, if
>that's what you use) that says:

>  my $crlf = ( $hide_progress || $opt->{logprogress} ) ? "\n" : "\r";

>ie setting it to either LF or CR depending on whether those named vars
>are set or not.  You'd need to look more closely at the perl to find
>out under what circumstances they're set one way or another.

Thanks for the explanation of my $crlf and {crlf}.  I had been looking for 
it in the sprintf documentation.

One thing that has occurred to me is that my desktop monitor is wider than 
the laptop screens.  The --verbose speed and progress indicator in v3.06 has 
more information than the corresponding indicator in v3.02 and earlier.  In 
particular it shows the current and final segment numbers.  It may be that 
the line length is alright for the desktop monitor but too long for the 
laptop screens.  It could be that Windows is inserting a CR LF as a line 
break but the  text overflowing to the next line is overwritten when 
get_iplayer generates a CR.

The else limb generates a much shorter line, so there is no risk of 
overflow.

I'll have to try reducing the number of items displayed and reducing the 
font size.

Best wishes
Richard