Comment 1 by briang1 on 2012-04-07 11:20
Well, I was surprised to find that my reboot shortcut operated the button to install, and this is the log output I got to where it just stopped.

IO - speech.speak (12:07:01):
Speaking ('en_UK'), u'Close'
IO - speech.speak (12:07:02):
Speaking ('en_UK'), u'Install Update dialog Update downloaded. It will now be installed.'
IO - speech.speak (12:07:02):
Speaking ('en_UK'), u'OK button'
IO - inputCore.InputManager.executeGesture (12:07:17):
Input: kb(desktop):control+alt+r
DEBUGWARNING - watchdog._watcher (12:07:18):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 158, in
File "core.pyc", line 325, in main
File "wx_core.pyc", line 8010, in MainLoop
File "wx_core.pyc", line 7306, in MainLoop
File "wx_core.pyc", line 14669, in
File "updateCheck.pyc", line 275, in _downloadReport
File "wx_windows.pyc", line 2971, in Update
File "wx_core.pyc", line 14669, in
File "updateCheck.pyc", line 292, in _downloadSuccess
File "shellapi.pyc", line 37, in ShellExecute

IO - speech.speak (12:07:19):
Speaking ('en_UK'), u'Downloading Update dialog Elapsed time : \n0:00:56\nRemaining time : \n0:00:00'
IO - speech.speak (12:07:19):
Speaking ('en_UK'), u'Close button'
DEBUGWARNING - watchdog.watcher (12:07:20):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 158, in
File "core.pyc", line 325, in main
File "wx_core.pyc", line 8010, in MainLoop
File "wx_core.pyc", line 7306, in MainLoop
File "core.pyc", line 302, in Notify
File "IAccessibleHandler.pyc", line 851, in pumpAll
File "IAccessibleHandler.pyc", line 610, in processGenericWinEvent
File "IAccessibleHandler.pyc", line 532, in winEventToNVDAEvent
File "NVDAObjects\IAccessible__init_.pyc", line 38, in getNVDAObjectFromEvent
File "IAccessibleHandler.pyc", line 358, in accessibleObjectFromEvent
File "oleacc.pyc", line 240, in AccessibleObjectFromEvent

DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent (12:07:21):
oleacc.AccessibleObjectFromEvent with window 6751226, objectID -4 and childID 0:
DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent (12:07:21):
oleacc.AccessibleObjectFromEvent with window 1180532, objectID -4 and childID 2:
IO - speech.speak (12:07:22):
Speaking ('en_UK'), u'dialog Please wait while Setup is loading...'
IO - speech.speak (12:07:22):
Speaking ('en_UK'), u'text'

I don't know if there are any smoking guns there.

Comment 2 by briang1 (in reply to comment 1) on 2012-04-07 13:17
Replying to briang1:

Well, I was surprised to find that my reboot shortcut operated the button to install, and this is the log output I got to where it just stopped.

IO - speech.speak (12:07:01):

Speaking ('en_UK'), u'Close'

IO - speech.speak (12:07:02):

Speaking ('en_UK'), u'Install Update dialog Update downloaded. It will now be installed.'

IO - speech.speak (12:07:02):

Speaking ('en_UK'), u'OK button'

IO - inputCore.InputManager.executeGesture (12:07:17):

Input: kb(desktop):control+alt+r

DEBUGWARNING - watchdog._watcher (12:07:18):

Trying to recover from freeze, core stack:

File "nvda.pyw", line 158, in

File "core.pyc", line 325, in main

File "wx_core.pyc", line 8010, in MainLoop

File "wx_core.pyc", line 7306, in MainLoop

File "wx_core.pyc", line 14669, in

File "updateCheck.pyc", line 275, in _downloadReport

File "wx_windows.pyc", line 2971, in Update

File "wx_core.pyc", line 14669, in

File "updateCheck.pyc", line 292, in _downloadSuccess

File "shellapi.pyc", line 37, in ShellExecute

IO - speech.speak (12:07:19):

Speaking ('en_UK'), u'Downloading Update dialog Elapsed time : \n0:00:56\nRemaining time : \n0:00:00'

IO - speech.speak (12:07:19):

Speaking ('en_UK'), u'Close button'

DEBUGWARNING - watchdog._watcher (12:07:20):

Trying to recover from freeze, core stack:

File "nvda.pyw", line 158, in

File "core.pyc", line 325, in main

File "wx_core.pyc", line 8010, in MainLoop

File "wx_core.pyc", line 7306, in MainLoop

File "core.pyc", line 302, in Notify

File "IAccessibleHandler.pyc", line 851, in pumpAll

File "IAccessibleHandler.pyc", line 610, in processGenericWinEvent

File "IAccessibleHandler.pyc", line 532, in winEventToNVDAEvent

File "NVDAObjects\IAccessible__init__.pyc", line 38, in getNVDAObjectFromEvent

File "IAccessibleHandler.pyc", line 358, in accessibleObjectFromEvent

File "oleacc.pyc", line 240, in AccessibleObjectFromEvent

DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent (12:07:21):

oleacc.AccessibleObjectFromEvent with window 6751226, objectID -4 and childID 0:

DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent (12:07:21):

oleacc.AccessibleObjectFromEvent with window 1180532, objectID -4 and childID 2:

IO - speech.speak (12:07:22):

Speaking ('en_UK'), u'dialog Please wait while Setup is loading...'

IO - speech.speak (12:07:22):

Speaking ('en_UK'), u'text'

I don't know if there are any smoking guns there.

Another thought. If one actions the update check from a portable version, one goes via the normal IE dialogues about downloading the file and running the file, and this seems not to cause the running system to crash. So maybe its the method used to bypass this and download and run the code that is where the problem lies.

Comment 3 by briang1 on 2012-04-08 13:05
I just installed a new copy of nvda on a machine which had had the nvda
installed version completely removed.
Firstly, I deliberately used snap 62.
The install went fine, though as I was using a dolphin reader to load it in,
I did not expect dolphins exit to stop the installer as it did. It basically
disappeared and had to be run again. Most odd.

I think I'd like to see the installer default to creating a desktop shortcut
and an automatic start on the install sequence. This seems not to be the
case in snap62 as far as i could tell.
Of course being snap 62, after it ran itself, it prompted to download the
later snap. I let it do this and it worked fine. When I let it do the
update there was no rising or falling tones at all until the update was
complete and the updated version ran. This seems to point to all the
messing about we have seen being due to something about the altered .ini or
other configurations of the copy on the machine when you do the update.

I have not yet configured anything other than the auto start and run on
login and no start dialogue, so we will see what happens when the next snap
comes along.

Comment 4 by nikosdemetriou on 2012-04-10 12:32
Hi.
I am having a simmilar problem when trying to update.
At the moment i have got snapshot 5066 installed under windows xp.
When i try to update the new version downloads fine but when i press ok i can hear my installed version closing, then the nvda logo music and then nvda starts again without installing the new version. When i go in to the about dialogue i can see that i am still running main 5066.

Comment 5 by briang1 on 2012-04-11 15:03
I think for most the current version reboots in time to be closed again by the new installer code so the update still does occur. I managed to get your result just once, but mostly, if you wait quite a long time, the update does load and update correctly I find. I just cannot figure out why it makes any difference if you download and run from the portable version which goes via the IE dialogues, or the installed version which updates mostly without intervvention.

Unforunately the update only seems to work cleanly if you do no configuration between updates and the original install. I'm thinking maybe it might be the same bug as the reason it cannot spot the users config correctly. If its got bits of one config and bits of another, no wonder its confused!

Comment 6 by briang1 on 2012-04-15 08:05
Having read a number of the messages from those who get this and the comments in the dev list, I wonder would there be any mileage in me or someone else who has the issue zipping up our user config folder and putting it in dropbox so you could substitute it in an xp system there and see if it causes the issue?

Comment 7 by jteh on 2012-04-16 09:03
Hopefully fixed in cf2ae90. Please test and report.

Comment 8 by jteh on 2012-04-20 12:42
Apparently, this still happens on some low spec machines. Damn.

Comment 9 by briang1 (in reply to comment 8) on 2012-04-20 15:19
Replying to jteh:

Apparently, this still happens on some low spec machines. Damn.

Well, I know you like the low user intervention of that updater, but from the flexability point of view, the updater on portable versions is better, allowing one to actually save the update to a known permanent place, so if an update did not do what you thought, you could reload the old version last downloaded.
The manual update created this way always works, even thoug it might be very slow on a low spec machine.

Comment 10 by briang1 on 2012-04-21 19:14
One question, is anyone masochistic enough to use nvda on a machine with less than half a gig of ram under xp?

If its only myself, then maybe this has to just be accepted as a limit.
I've figured out why it does not sometimes update at all even though its downloaded the file. Its because the reboot of the crashed nvda occurs at the time its trying to shut it down and boot in the temp copy.
It always succeeds if you run the file manually. Maybe there is just not enough ram and it starts swapping out to disc?

Comment 11 by jteh on 2012-04-27 11:11
I think I understand why this crash is occurring now. I've hopefully fixed it for real in 6d31167. Please test and report.

Comment 12 by briang1 on 2012-04-27 11:21
Well on the current snap updating from the previous 1, I also found that it is indeed the crash that stops the machine updating, if it happens while the update is loading, so if its sorted it will kill this problem as well.
I did actually amanage to get the low spec machines to update, but one took two downloads to do it for snap 32. Obviously, one will have to update with 33 and await the next snap to test the fix though.

Comment 13 by jteh on 2012-05-08 08:54
Brian has confirmed that this is fixed for him across several systems and we've had no further reports of crashes.
Changes:
State: closed