Infrastructure

Can you share the IP that requested the download, and/or a traceroute to
the mirror?

Note this is a public ticket, but if you prefer, you can share in
private with hostmaster@documentfoundation.org

IP address was same as I used to submit the bug.

You will note that the software on your mirror manual selection page did correctly detect the fact I was in UK (GB). As I told you, "On the manual mirror selection page, under "Found 3 mirrors which handle this country (GB)", I opted for.."

The three concerned did not include the 'recommended/1st choice' mirror.

I checked and saw that the error was corrected within the next few days, both in the mirror selection page and on the mirror map offered to me. I therefore assumed you had responded to my report and fixed the problem without replying to me.

I am tempted to believe that somewhere, someone setting up steering information used to select the recommended/1st choice mirror managed to confuse GB (Great Britain) with BG (Bulgaria). I seem to remember that there is no mirror in Bulgaria, so the Czech Republic, which is relatively near to it, might quite possibly be seen as the best mirror for Bulgarian users.

--------------------------------------------
On Fri, 16/9/16, The Document Foundation Redmine <generic@redmine.documentfoundation.org> wrote:

Subject: [Infrastructure - Task #2038] British (UK) User Requesting LibO 5.2.1 Download Directed to (Extremely slow) Mirror in Czech Republic
To:
Date: Friday, 16 September, 2016, 13:20

--- Please reply above
this line ---
When replying, please ensure to use the e-mail address
associated with your account.
Otherwise, to prevent spam, messages will be silently
discarded.
Issue #2038 has been updated by Florian Effenberger.

Can you share the IP that requested the download, and/or
a traceroute to
the mirror?

Note this is a public ticket, but if you prefer, you can
share in 
private with hostmaster@documentfoundation.org

Task
#2038: British (UK) User Requesting LibO 5.2.1 Download
Directed to (Extremely slow) Mirror in Czech
Republic

Author: Mr R.D.

In England, 60 miles (100 Km) from London, using a local
cable connection;
On your standard download page, http://www.libreoffice.org/download/libreoffice-fresh/,
I requested LibreOffice 5.2.1 for Win x86
The request was met (after a significant delay) from the
server/file http://mirror.vutbr.cz/tdf/libreoffice/stable/5.2.1/win/x86/LibreOffice_5.2.1_Win_x86.msi
The download crept like a snail, so I abandoned and opted to
choose a mirror manually.

I found that, according to the list of mirrors on page I
was shown, the 'preferred mirror' for my location
was mirror.vutbr.cz. I also saw on that page "Found 1
mirror very close..
..http://mirror.vutbr.cz/tdf/libreoffice/stable/5.2.1/win/x86/LibreOffice_5.2.1_Win_x86.msi" 
- yes, really close eh?
I looked on your map of mirrors and was shown that it
indicated that mirror as '1' for me, despite the
existence of servers in London (100Km away), France,
Netherlands etc etc.

On the manual mirror selection page, under "Found 3
mirrors which handle this country (GB)", I opted  for
http://mirror.catn.com/pub/tdf/libreoffice/stable/5.2.1/win/x86/LibreOffice_5.2.1_Win_x86.msi
which downloaded at a steady 1.9MB/s. (B, not b)

However, I then tried to download the en-GB Help-pack
(LibreOffice_5.2.1_Win_x86_helppack_en-GB.msi) by going back
and clicking the appropriate button on the 'normal'
download page. I was yet again directed to
mirror.vutbr.cz.

I did not see any option to circumvent this on
the'manual mirror selection page, so I went to the
directory (luckily accessible) whence LibO itself had
downloaded
(mirror.catn.com/pub/tdf/libreoffice/stable/5.2.1/win/x86)
and tried the en-GB help file link there. Since it was a
'.msi.asc' file, that was no help. However, I
discovered that taking its address, removing the
'.asc' from the end, and submitting the resulting
address to the browser, I was able to download the en-GB
Help pack.

Then, since I have two Win systems,  I had to go through
the whole rigmarole for x64 versions. Same story but at
least, when mirror.vutbr.cz was again thrust at me, I was
prepared for it and knew how to get both files from the
correct local and much faster site.

I suppose that many UK users would not have realised
what was happening to them and would have sat fretting while
their files came, extremely slowly, from entirely the wrong
mirror.

In summary: Using default download route, UK user was
served LibO 5.2.1 from unusually slow Czech mirror instead
of local UK mirror which was very much faster.

The Document Foundation
Redmine: https://redmine.documentfoundation.org

The Document Foundation, Kurfürstendamm 188, 10707
Berlin
Gemeinnützige rechtsfähige Stiftung des bürgerlichen
Rechts
Legal details: http://www.documentfoundation.org/imprint

IP address was same as I used to submit the bug.

Can you let me know the address? There's no way for me to see this. ;-)

I checked and saw that the error was corrected within the next few days,
both in the mirror selection page and on the mirror map offered to me. I
therefore assumed you had responded to my report and fixed the problem
without replying to me.

So it's fixed now for you, and this ticket can be closed, is that right?

Florian Effenberger wrote:

IP address was same as I used to submit the bug.

Can you let me know the address? There's no way for me to see this. ;-)

There must be a reason why your system doesn't show my IP.. I don't hide it.

Anyway, as is clear, the process used in the manual mirror selector main process was able to correctly determine my location without trouble, correctly displaying my presence in GB and showing three possible mirrors in GB. It was the 'best choice' subsystem on that page and on the map which produced a result completely at variance with all the rest of that. The mirror that the 'best choice' chose was not even in the three which the main system correctly located, two of which were in London and the third at a similar distance.

I checked and saw that the error was corrected within the next few days,
both in the mirror selection page and on the mirror map offered to me. I
therefore assumed you had responded to my report and fixed the problem
without replying to me.

So it's fixed now for you, and this ticket can be closed, is that right?

If you're not interested in pinning down the exact cause of the problem so it can't happen again.

I must say, in your position, I would be at least interested in the GB/BG confusion possibility and see if that showed up in your system change control records.

Can you send me the output of

http://download.documentfoundation.org/libreoffice/stable/5.2.1/win/x86/LibreOffice_5.2.1_Win_x86.msi.mirrorlist

so we can investigate further?

Florian Effenberger wrote:

Can you send me the output of

http://download.documentfoundation.org/libreoffice/stable/5.2.1/win/x86/LibreOffice_5.2.1_Win_x86.msi.mirrorlist

so we can investigate further?

On that page (which is the manual mirror selection page for x86), the information relevant for me is currently all correct, as, I have already said, it has been since some time after the original problem occurred. Hence it would not give you any more information relevant to the original problem reported.

If you believe anything useful would still show up in that current listing, perhaps you could tell me exactly what field values are of interest to you and how to locate them and I can give you those.

So, to re-assess that: The problem does not exist anymore, is that
correct? Seems the misunderstand is in this question. ;-)

Florian Effenberger wrote:

So, to re-assess that: The problem does not exist anymore, is that
correct? Seems the misunderstand is in this question. ;-)

Correct. For me, at present, the problem I reported does not exist. In my personal case, it can be closed.

However, if you don't know how it happened, you cannot prevent a future recurrence. Nothing has been done to cure the underlying problem so what I reported could happen again. If you have any record to show you how it happened, then you would be able to prevent any future recurrence.