Download speed and progress indicator

[RS]

Does Perl distinguish between desktop and laptop machines?

If I run get_iplayer with --verbose I can get an instantaneous download
speed indicator similar to the one we used to have.

If I run it on my desktop machine it displays a single line which is
continuously updated, like the indicator we used to have by default. If I
run it on any of my laptops each update is on a new line. I presume that in
the first case the line is terminated with a CR and in the other cases with
a CR LF.

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.

All machines are running the version of Perl dated 15 Jan 2017. They are
all running various versions of 64-bit Windows 10, Home and Professional,
1709, 1703 and 1607.

Any ideas on what is causing the different behaviour?

[Ralph Corderoy]

Hi Richard,

Post by RS
Does Perl distinguish between desktop and laptop machines?

No. :-)

Post by RS
Any ideas on what is causing the different behaviour?

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.

[Jeremy Nicoll - ml gip]

Post by RS
Does Perl distinguish between desktop and laptop machines?

I wouldn't think so.

Do you run these commands in a Windows cmd.exe command window, or do
you by any chance use some other form of terminal?

Post by RS
If I run get_iplayer with --verbose I can get an instantaneous
download speed indicator similar to the one we used to have.
If I run it on my desktop machine it displays a single line which is
continuously updated, like the indicator we used to have by default.
If I run it on any of my laptops each update is on a new line. I
presume that in the first case the line is terminated with a CR and in
the other cases with a CR LF.
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.

[RS]

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

Post by Ralph Corderoy
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

Post by Ralph Corderoy

Post by RS
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
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

[Jeremy Nicoll - ml gip]

Post by RS
One thing that has occurred to me is that my desktop monitor is wider
than the laptop screens.

Actually that's not the width that matters. The terminal window also
has
a width (and depth) and if it's set wider than your screen then you just
have to scroll it sideways.

In XP and W8.1 and presumably W10 too, if you click the icon at the top
left of the window (on the titlebar) then choose Properties -> Layout
you can set the size of the buffer lines in which output is stored, and
also the maximum width of the terminal window. I typically have

screen buffer width 150 columns height 9999 rows
window size 150 height 42 rows

You can also set colours and other options.

Those settings only apply to that window, or - if it was started by a
shortcut - to the way the window will open when next started by the same
shortcut.

There is also a Defaults option on the icon menu, with all the same
options, but that saves system defaults so that any command window
opened in the future (unless opened with a shortcut which had its
own options saved) will get the values you have set.

It's overly complicated, I think.

[RS]

From: Jeremy Nicoll - ml gip
Sent: Tuesday, November 7, 2017 9:52 PM

Actually that's not the width that matters. The terminal window also has
a width (and depth) and if it's set wider than your screen then you just
have to scroll it sideways.
In XP and W8.1 and presumably W10 too, if you click the icon at the top
left of the window (on the titlebar) then choose Properties -> Layout
you can set the size of the buffer lines in which output is stored, and
also the maximum width of the terminal window. I typically have
screen buffer width 150 columns height 9999 rows
window size 150 height 42 rows

Thanks, that is indeed the answer. My desktop machine has a screen buffer
size width of 131 and the window size width is the same, and one laptop has
a screen buffer size width and window size width of 113.

If I look at the output on the laptop more carefully, I can see each line
ends "remai" and the last line is "ning" so it is 4 characters too short.

I was aware of the Properties on the command prompt window in Windows 10,
but I wasn't aware of it in XP (nor until a few minutes ago was I aware that
there was distinction between the NT cmd.exe and the DOS prompt). I have
been using it to change the font size. The default 6x12 pixels Consolas
font is very small, so I have been changing it to 9x20.

I have just been experimenting and the default width appears to be 80
characters for both screen buffer and window size, but it gets recalculated
if the font size is changed and if the window is made full screen (which is
what I normally use).

When I change the font size I have always got an error message telling me it
was unable to modify the shortcut. Suggestions I have found from searching
, including making the change as administrator, have not worked. I have
just found by accident that if the font size is 8x18 or less it can be
saved.

If I reduce the font size to 8x18 on the laptop the line does display
correctly.

As you say, it's complicated.

Best wishes
Richard