Attachment nvda(error_downloading_update).log added by ondrosik on 2012-05-17 09:25
Description:
Log file which shows the update error.

Comment 1 by jhomme (in reply to comment description) on 2012-05-17 10:41
Replying to ondrosik:

Hi,
If it is possible to allow installation without admin privileges, I selfeshly request that we be permitted to do that. If not, I tried. :)

Jim

When running NVDA without administration privileges, update process fail. With "error downloading update"

Step by step:

1. help>check for update

2. download update

3. don't donate

4. downloading

5. "error downloading update"

i tried this with administration privileges successfully. It will be better to inform muser that it is necessary to log on as an administrator or show the password dialog as for example during copiing settings to logon screen.

Comment 2 by jteh on 2012-05-17 21:27
Downloading the update does not require administrator privileges. If it does, the permissions on your user account are very broken, as it downloads to your user temporary directory. Please provide a log of the error; see ReportingIssues#ProvidingLogFiles.

Installing the update does and always will require administrator privileges, but you should be prompted for administrator access when installation begins.

Comment 3 by pvagner on 2012-05-23 06:30
I've been on phone with ondrosik yesterday regarding this issue.
I've collected the following data:

• He's running Windows XP and the %temp% variable correctly points out to his user specific temp folder.
• He does this logged in as the user named ondrej which has proper permisssions on the temp folder
• He has tried this multiple times in order to make sure this is not really a network issue
• while doing this logged in as an administrator it performs as expected

I'm unable to give further suggestion, here is the relevant part from the log he has attached

IO - tones.beep (11:09:43):
Beep at pitch 1532.1689914, for 40 ms, left volume 50, right volume 50
DEBUGWARNING - updateCheck.UpdateDownloader._bg (11:09:53):
Error downloading https://sourceforge.net/projects/nvda/files/releases/2012.2beta2/nvda_2012.2beta2.exe/download
Traceback (most recent call last):
File "updateCheck.pyo", line 276, in _bg
File "updateCheck.pyo", line 304, in _download
File "socket.pyo", line 380, in read
timeout: timed out

Comment 4 by jteh on 2012-05-23 07:37
The log indicates the connection to the server is timing out. If it really isn't a network issue, this suggests there is something specific to the user account which causes the connection to time out. One possibility is that there is a proxy configured for the user account which isn't configured for the administrator account and this is causing problems. Another is that https connections are being blocked by some sort of firewall for user accounts but not for administrator accounts.

Comment 5 by ondrosik (in reply to comment 4) on 2012-05-23 07:46
does this depends on installed internet browsers? Because when i type the URL to the firefox, it starts downloading automatically, explorer 8 shows blocking download and i have to enable it from the alt+n menu. Also free download manager is istalled on this machine.

Comment 6 by pvagner on 2012-05-23 08:16
I don't think browser / download manager combinations matter in this case.
According to the log it appears as downloads is already started and then somewhere in the middle of the downloading process it times out with error connecting to the server.
What about jamies idea in comment:4?
Are you running Eset smart security, or Eset nod 32 or something else what may monitor or do something with network connections?
Are you using any kind of proxy server or so called speed booster for usage with mobile internet?
I know a while back slovak careers were activelly offering such tools.

Comment 7 by ondrosik (in reply to comment 6) on 2012-05-23 08:23
I am using eset nod 32. Not sure about speed boosters but i didn't installed this. previously, when i posted this ticked i was updating on a school network. I tested it today on a mobile network with the same result. I will turn off Eset, we will see.

Comment 8 by ondrosik (in reply to comment 7) on 2012-05-25 06:01
Hi,
Turning of Eset nod 32 fixed the problem. But another one shows. I entered user name and password for administrator and during installation nvda shows dialog, that some file is in use and NVDA recomend to logout other users. But i am currently one user which is logged in. Also the nvda folder has about 520 MB and contains lot of stuff from windows\system32 like
bios1.rom
narrator.exe
netlogon.dll
xpsp1res.dll
Maybe another ticket is created for this. I will search through.

Comment 9 by pvagner on 2012-05-25 11:48
Originally I assumed os.getcwdu() what we are using in copyProgramFiles() returned something else than path to the folder where temporary version of NVDA has been unpacked. However then I've got in touch with ondrosik again and after further inspection it appears as there were NVDA files mixed with system32 files in the target directory. The install ended up unfinished and no startmenu shortcuts were created during that broken install.
Is that os.getcwdu() safe? wouldn't it change?

Comment 10 by pvagner on 2012-05-25 12:01
okay os.getcwdu() doesn't appear to cause an issue here as while running temporary copy of NVDA, os.getcwdu() called using the python console correctly gives path inside the users temp folder.
Trying to investigate further if I'm actually able to...

Comment 11 by pvagner on 2012-05-25 13:20
okay definatelly I have played with this on my system and I can 100% reproduce the original issue with update check not being able to download an update.
By experimenting with various settings I've found out the problem is with our download method and eset nod 32 4 http scanner.
After initial google search I am unable to find evidences of something similar.
I am just speculating we are always asking for download block size while retrieving the file since it all hangs at 99 percent of downloading. Do you think this might cause problem for antivirus? We are asking for more data than there is actually there at the end of the file.

Comment 12 by pvagner on 2012-05-25 15:06
Hopefully fixed in changeset:releases/2012.2,5229 .
On my system strategy proposed in comment:11 works fine. Also before applying the fix on my system the update download was failing even while logged as user with administrative privileges. It needs more testing.
The other issue where installer copies a lot of unnecessary files and fails should be filled and handled as a seperate ticket.
Changes:
Changed title from "Updating without administration privileges" to "Updating without administrative privileges fails with some antivirus apps running in background"

Comment 13 by pvagner on 2012-05-25 15:07
Changes:
State: closed

Comment 14 by pvagner on 2012-05-25 18:29
Changes:
Milestone changed from None to 2012.2

Comment 15 by pvagner on 2012-06-04 10:02
ooops, this is still not fixed properly.
It appears running update check multiple times in a succession may eventually download the update properly.
Today my update failed with eset nod 32 4 running and with the fix implemented in the 688c6c7 applied.
I have no more ideas at this time however disabling http scanner in eset nod 32 fixes the issue.
Changes:
State: reopened

Comment 16 by ateu on 2012-06-04 14:53
Hi all

I use windows 32 bit and avast 7 and it's not possible update NVDA.
Appears an error, but it's not logged.

Strangely, when I run ANOTHER computer with windows 64 bit and microsoft secure essential, update feature works fine.

Comment 17 by jteh (in reply to comment 16) on 2012-06-04 22:54
Replying to ateu:

I use windows 32 bit and avast 7 and it's not possible update NVDA.

Is it the download or installation that fails?

Appears an error, but it's not logged.

It's possibly logged as debug warning. Please set your log level to debug warning and report.

Comment 18 by ateu on 2012-06-05 01:35
Hi

The error appears when the update is being downloaded.
Later I will send the log you requested.

Attachment nvda_debug_warning.log added by ateu on 2012-06-05 10:07
Description:

Comment 19 by ateu on 2012-06-05 10:11
When the error appears, an avast window is opened. As it is inacessible, I can't know what it shows.

Comment 20 by jteh (in reply to comment 15) on 2012-06-05 11:31
Replying to ateu:

When the error appears, an avast window is opened. As it is inacessible, I can't know what it shows.

It looks like Avast is blocking the download. The Avast window is probably requesting confirmation. I don't think there's anything we can do about this. I'm guessing this is working as intended as far as Avast is concerned. Do you have any reason to suspect differently?

Replying to pvagner:

It appears running update check multiple times in a succession may eventually download the update properly.

Today my update failed with eset nod 32 4 running and with the fix implemented in the 688c6c7 applied.

Is the error the same; i.e. timeout?

Comment 21 by pvagner (in reply to comment 20) on 2012-06-05 12:45
Replying to jteh:

Replying to pvagner:

It appears running update check multiple times in a succession may eventually download the update properly.

Today my update failed with eset nod 32 4 running and with the fix implemented in the 688c6c7 applied.

Is the error the same; i.e. timeout?

Yes it still appears the same.
Using other apps such as browsers or even wget from a command line I see no timeouts like this.
SThee is nothing logged in the eset nod 32 log.

Comment 22 by ondrosik (in reply to comment 21) on 2012-06-05 15:38
Situation behind Eset nod32 is really strange, no log from Eset and today I updated from snap 2507 to 2508 with HTTP scanner enabled. I see only used ports in eset, do you think, that this may cause problems? E. G. which port is used to download those updates? Eset is controlling 80, 8080, 3128

Comment 23 by jteh (in reply to comment 22) on 2012-06-05 22:37
Replying to pvagner:

Is the error the same; i.e. timeout?

Yes it still appears the same.

Also, is the rest the same; i.e. still gets to 99% then fails?

Replying to ondrosik:

which port is used to download those updates?

It's standard http, so port 80.

Comment 24 by ondrosik (in reply to comment 23) on 2012-06-06 12:06
I'm totally confused. I am now using snapshots and update yesterday and today was successfull with http enabled. So what i am going to do is install RC1 and update to RC2 to make sure that really nothing changed in Eset nod32. Next, i will again instal one of those snapshots and update to current snapshot 5213. Peter or someone else with this "eset" problem, have you tryed to update to snapshots or RC only?

Comment 25 by jteh on 2012-06-06 12:26
The download fix isn't in rc1, so you'll probably encounter the problem with rc1. You shouldn't see it with rc2 or recent 2012.2 snapshots.

Peter, can you please try this in the Python console before downloading an update:

import socket
socket.setdefaulttimeout(20)

Does this help? You can also try increasing this to higher values.

Comment 26 by ondrosik (in reply to comment 25) on 2012-06-06 17:38
OK, after bit of testing i Am at the beginning. Eset is blocking the update and only one way how to finish it is disable http scanner. After disabling and reenabling eset probably requires restart (because after log out update is successfull - so this explains why I installed the update today correctly.)
Log is the same, also the process - ˇ99 % and the error downloading dialog.

Comment 27 by surveyor (in reply to comment 26) on 2012-06-06 17:47
Replying to ondrosik:

OK, after bit of testing i Am at the beginning. Eset is blocking the update and only one way how to finish it is disable http scanner. After disabling and reenabling eset probably requires restart (because after log out update is successfull - so this explains why I installed the update today correctly.)

Log is the same, also the process - ˇ99 % and the error downloading dialog.

The same problem for me. tried to update from main 5208 to 5213 with http enabled in eset and failed again.

Comment 28 by ondrosik (in reply to comment 27) on 2012-06-07 09:00
hi surveyor):
Can you please try following

1. nvda >tools >python console
   import socket
   enter
   socket.setdefaulttimeout(50)
   enter
2. close the Python console and try update NVDA.
   Here i updated NVDA with following behavior
   99 %, then little bit more CPU usage (my laptop was more noisy) then update dialog was closed and after that new dialog appear with successfull message. But Eset is doing strange things here so we need more testers. I am also not sure about the Python console because there was no output but the time after download was longer as before.

Comment 29 by ondrosik (in reply to comment 28) on 2012-06-07 10:05
I repeated the process after restart and it really seems that longer timeout may solve the issue. Here it works fine.

Comment 30 by jteh (in reply to comment 28) on 2012-06-07 11:53
Replying to ondrosik:

socket.setdefaulttimeout(50)

50 seconds is a pretty long timeout.

99 %, then little bit more CPU usage (my laptop was more noisy) then update dialog was closed and after that new dialog appear with successfull message.

I wonder whether it is scanning the file just as it finishes downloading but before it gives NVDA the last chunk. That's pretty stupid/weird behaviour. :)

but the time after download was longer as before.

Any idea how long between the last progress beep and the success dialog? Was it really 50 seconds?

Development note: We don't want to set the default socket timeout too high, as otherwise, update checks will take forever to fail. However, we can change the timeout for the download itself using remote.fp._sock.settimeout. This is ugly as all hell, but it may be the only way.

Comment 31 by ondrosik (in reply to comment 30) on 2012-06-07 11:59
Hi,
What is the default time out? I set it to 50 only to make sure if that should change something, maybe your recomended 20 should be enough.
" Was it really 50 seconds?"
From my point of wiev yes, I can use stopwatch to make sure:-)
So now we can try the short time out.

Comment 32 by jteh (in reply to comment 31) on 2012-06-07 12:30
Replying to ondrosik:

What is the default time out?

" Was it really 50 seconds?"

From my point of wiev yes, I can use stopwatch to make sure:-)

Wow. So we really do have to set it pretty high.

Comment 33 by ondrosik (in reply to comment 32) on 2012-06-07 16:48
OK, i tryed 20 and it is enough, so there is probably some temporary blocking by Eset.

Comment 34 by surveyor on 2012-06-07 18:06
My experience:
I tried 50 on a computer in the office and it didn't work. Then, I tried 20 at home pc it again didn't work. Lastly I tried 50 at home again, this time it worked.

Comment 35 by pvagner (in reply to comment 30) on 2012-06-07 22:14
Replying to jteh:

50 seconds is a pretty long timeout.

I wonder whether it is scanning the file just as it finishes downloading but before it gives NVDA the last chunk. That's pretty stupid/weird behaviour. :)

I am afraid this exactly as you have described it is happening. I can notice it even with firefox wget and all other apps downloading some files over http. It is stuck on 99 or 100 percent for a while. Most likelly eset is scanning the file. I've tried another idea, saving the file into a different file where there is no .exe extension because many downloaders are doing this but that doesn't help either. The only working solution so far is higher timeout.

Any idea how long between the last progress beep and the success dialog? Was it really 50 seconds?

Development note: We don't want to set the default socket timeout too high, as otherwise, update checks will take forever to fail. However, we can change the timeout for the download itself using remote.fp._sock.settimeout. This is ugly as all hell, but it may be the only way.

on my slow laptop it really takes a while. I think it's less than 50 secs but still perhaps just in case we might use 60 seconds if we'll add the hack mentioned above.
Can we commit it to 2012.2? will you do it?

Comment 36 by jteh on 2012-06-07 23:44
Increased the timeout to 120 seconds for downloads in 183853e.
Changes:
State: closed

Comment 37 by ondrosik (in reply to comment 35) on 2012-06-08 05:01
I see that this is currently closed but maybe this might help. I set the time out to 120 regarding to last comment and updated. It Starts after 20 seconds. So the time out from this perspective is not blocking the user two minutes whether or not is eset duing its job. But I am not familiar with all aspects what can the bigger time out do for other users.

Replying to pvagner:

Replying to jteh:

50 seconds is a pretty long timeout.

I wonder whether it is scanning the file just as it finishes downloading but before it gives NVDA the last chunk. That's pretty stupid/weird behaviour. :)

I am afraid this exactly as you have described it is happening. I can notice it even with firefox wget and all other apps downloading some files over http. It is stuck on 99 or 100 percent for a while. Most likelly eset is scanning the file. I've tried another idea, saving the file into a different file where there is no .exe extension because many downloaders are doing this but that doesn't help either. The only working solution so far is higher timeout.

Any idea how long between the last progress beep and the success dialog? Was it really 50 seconds?

Development note: We don't want to set the default socket timeout too high, as otherwise, update checks will take forever to fail. However, we can change the timeout for the download itself using remote.fp._sock.settimeout. This is ugly as all hell, but it may be the only way.

on my slow laptop it really takes a while. I think it's less than 50 secs but still perhaps just in case we might use 60 seconds if we'll add the hack mentioned above.

Can we commit it to 2012.2? will you do it?

Comment 38 by jteh on 2012-06-08 05:15
The timeout is the maximum time to wait to receive data, but if it takes less time, you'll only have to wait as long as it takes. The reason we have a timeout is so that the user isn't waiting forever with no action if the download really does die but the connection is still considered alive for some reason.

Comment 39 by ondrosik on 2012-07-23 08:43
One user is reporting that there is still problem with eset smart security RC 6, when checking TSL and SSL connection is enabled. Important part of log:
Beep at pitch 1619.5302651, for 40 ms, left volume 50, right volume 50
IO - tones.beep (20:32:56):
Beep at pitch 1665.06145824, for 40 ms, left volume 50, right volume 50
IO - tones.beep (20:32:57):
Beep at pitch 1711.87270745, for 40 ms, left volume 50, right volume 50
DEBUGWARNING - updateCheck.UpdateDownloader._bg (20:33:22):
Error downloading http://nvda.sourceforge.net/snapshots/main/nvda_snapshot_main-5251.exe
Traceback (most recent call last):
File "updateCheck.pyc", line 277, in _bg
File "updateCheck.pyc", line 314, in _download
File "socket.pyc", line 380, in read
error: 10054 An existing connection was closed by the remote host.

Attachment eco-neti-pot.jpg added by Smartmil8 on 2013-02-17 19:43
Description:
,