Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Braille display auto-detection feature causes errors on loading large braille tables on NVDA startup #9982

Closed
DrSooom opened this issue Jul 26, 2019 · 81 comments · Fixed by #10498
Closed

Braille display auto-detection feature causes errors on loading large braille tables on NVDA startup #9982

DrSooom opened this issue Jul 26, 2019 · 81 comments · Fixed by #10498
Labels
component/braille component/liblouis Issues related to liblouis, such as liblouis updates and braille table additions/changes p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Milestone
2019.3

Comments

@DrSooom
Copy link

DrSooom commented Jul 26, 2019 •
edited

First of all I'm so glad that these errors aren't caused by my HUC Braille Tables alone, because other large braille tables like "zh-tw.ctb" lead to the same results I described in issue #9973 yesterday. CC: @LeonarddeR

Steps to reproduce:

  1. Install/Create a portable copy of NVDA 2019.2 Beta-18176.
  2. Now start NVDA Portable and change the braille output table to Chinese Taiwan/Mandarin ("zh-tw.ctb") and disable the checkbox "Expand to computer braille for the word at the cursor".
  3. Restart NVDA with debug logging level via NVDA+Q.

Actual behavior:

This time I was able to reproduce both errors I mentioned in issue #9973 on a SSD, but I couldn't figure out if the Chinese braille table "zh-tw.ctb" (of course without the HUC Braille Tables) was completely loaded or not. Maybe you have to restart NVDA multiple times to get these errors.

Here is the first logfile with no error sound on startup. And here is the second one with an error sound and no braille output directly after startup. Always start at line 126. And please take a look at the timestamps in the second logfile, because there aren't any log entries from the beginning of the error sound until the Protocol Viewer was opened. That's so strange, therefore I repeated restarting NVDA in Debug Mode multiple times, because I thought I did something wrong. Normally NVDA should also have logged pressing ArrowRight and ArrowLeft in the Windows Explorer (Detail View) as well as the steps to open the Protocol Viewer via the NVDA menu. But that was never the case.

Expected behavior:

No errors on loading large braille tables.

  • zh-tw.ctb: 1,25 MB (1,306,176 Bytes); 48,769 lines

System configuration

NVDA installed/portable/running from source:

Portable

NVDA version:

2019.2 Beta-18176

Windows version:

Win7x64

Other information about your system:

Optelec ALVA BC680 is connected via USB2. The USB1 port wasn't tested.

Other questions

Does the issue still occur after restarting your PC?

Not tested.

Have you tried any other versions of NVDA? If so, please report their behaviors.

Tests with 2019.1.1 (Portable) are pending. But I guess it's the same behavior like in issue #9973 – it works as expected. And smaller braille tables such as the Finish 8-dot Computer Braille ("fi-fi-8dot.ctb") seems to work with NVDA 2019.2 Beta-18176 as expected too. But deeper tests are pending here too.
@zstanecic
Copy link
Contributor

zstanecic commented Jul 26, 2019 via email •
edited by feerrenrut

@DrSooom
Copy link
Author

DrSooom commented Jul 26, 2019

That were/are always fresh portable Betas of NVDA. NVDA 2018.1 is installed on my system. Here is my config file. I guess it's a regression. Furthermore you can't compare these Betas with the Py3-Alphas because of PR #9544 and #9545.

@zstanecic
Copy link
Contributor

zstanecic commented Jul 26, 2019 via email •
edited by feerrenrut

@LeonarddeR
Copy link
Collaborator

Do you have reasons to think that this is a bug in NVDA and not in liblouis?

@DrSooom
Copy link
Author

DrSooom commented Jul 27, 2019

@LeonarddeR: You ask me things? That could be also caused by the Liblouis update from 3.8.0 to 3.10.0 over 3.9.0. This issue didn't occur in NVDA 2019.1.1 with Liblouis 3.8.0.

Therefore: CC: @bertfrees, @egli, @dkager and @nishimotz (if you are using Liblouis).

@lukaszgo1
Copy link
Contributor

@DrSooom Could you please test this with the last Python 2 Alpha of NVDA available here. I am asking because in issue #9486 the errors are similar, and it is caused by liblouis builds being optimized. If my hypothesis would be correct perhaps disabling optimization for liblouis builds for the time being would be reasonable. @LeonarddeR What do you think?

@DrSooom
Copy link
Author

DrSooom commented Jul 28, 2019

NVDA Alpha-18064 logfile on loading "zh-tw.ctb" after NVDA restart in Debug Mode:

Initializing global plugin handler
DEBUGWARNING - braille.BrailleHandler.setDisplayByName (20:39:28.825):
Error in initial display after display load
Traceback (most recent call last):
  File "braille.pyc", line 1686, in setDisplayByName
  File "braille.pyc", line 1976, in initialDisplay
  File "braille.pyc", line 1840, in handleGainFocus
  File "braille.pyc", line 1845, in _doNewObject
  File "braille.pyc", line 1516, in getFocusRegions
  File "braille.pyc", line 615, in update
  File "braille.pyc", line 428, in update
  File "louisHelper.pyc", line 65, in translate
  File "louis\__init__.pyc", line 183, in translate
WindowsError: exception: access violation reading 0x08DF7608
IO - braille.BrailleBuffer.update (20:39:29.046):
Braille regions text: [u'NVDA ist bereit']
IO - braille.BrailleHandler.update (20:39:29.046):
Braille window dots: 13457 12367 1457 17 - 24 234 2345 - 12 15 1235 15 24 2345
DEBUG - core.main (20:39:29.048):
Initializing core pump

And here is the complete logfile (start at line 149) after NVDA Alpha-18064 (Portable on a SSD) totally crashed after a few more restarts in Debug Mode. Only the Windows Explorer was opened during these tests. The HUC Braille Tables weren't tested.

@LeonarddeR LeonarddeR mentioned this issue Jul 29, 2019
Closed
@aaclause
Copy link
Contributor

Hi,
I've just tested and I wasn't able reproduce this bug. Tested with 2019rc1 and alpha-18222,be63d19d (portable versions). I Restarted NVDA about 10 times.

@DrSooom
Copy link
Author

DrSooom commented Jul 29, 2019

@Andre9642: Regarding NVDA 2019.2 RC1 I can confirm this. I also didn't get any errors. I wonder why. Therefore: Closing for now.

@DrSooom DrSooom closed this as completed Jul 29, 2019
@DrSooom
Copy link
Author

DrSooom commented Aug 8, 2019

This issue is back in NVDA 2019.2 RC2 (portable). Here is the logfile with "zh-tw.ctb" and freezing on startup (which wasn't logged, because I was able to kill the process "nvda.exe" via the Task Manager). The HUC Braille Tables are also affected.

@DrSooom DrSooom reopened this Aug 8, 2019
@DrSooom
Copy link
Author

DrSooom commented Aug 9, 2019

A nice new log entry with NVDA 2019.2 Beta-18345 on startup. Complete logfile

RuntimeError: Can't translate: tables [u'louis\tables\zh-tw.ctb', 'braille-patterns.cti'], inbuf N V D A i s t b e r e i t , typeform None, cursorPos c_long(0), mode 4

Note: There is a strange character between the letters in the logfile, It's not a space (U+0020) – maybe CR, LF or CRLF together.
CC: @LeonarddeR, @zstanecic, @bertfrees and @egli

@DrSooom DrSooom changed the title Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176 Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176, 2019.2 Beta-18345 and 2019.2 RC2 Aug 9, 2019
@Adriani90
Copy link
Collaborator

@DrSooom are you able to reproduce this in NVDA 2019.2 final release?

@DrSooom
Copy link
Author

DrSooom commented Aug 15, 2019 •
edited

Sadly absolutely no differences with NVDA 2019.2 Stable (Portable). Tested multiple times on a SSD and on a USB Flash Drive. Issue #9973 as well as this one here are still valid.

Question: Why did this all work as expected in NVDA 2019.2 RC1? What changes have been made since 2019.2 RC1 to 2019.2 Stable regarding liblouis? The file "zh-tw.ctb" wasn't changed (I checked the SHA-256 sums).

And here follows the significant part of the logfile (HUC8 Braille Tables were included into "de-de-comp8.ctb", but it's the same with "zh-tw.ctb" alone):

Initializing global plugin handler
IO - braille.BrailleBuffer.update (12:51:58.680):
Braille regions text: [u'Desktop fst']
ERROR - core.main (12:51:59.104):
Traceback (most recent call last):
  File "core.pyo", line 461, in main
  File "braille.pyo", line 1799, in message
  File "braille.pyo", line 428, in update
  File "louisHelper.pyo", line 65, in translate
  File "louis\__init__.pyo", line 183, in translate
WindowsError: exception: access violation writing 0x00000000
DEBUG - core.main (12:51:59.104):
Initializing core pump

@DrSooom DrSooom mentioned this issue Aug 16, 2019
Closed
@LeonarddeR
Copy link
Collaborator

Question: Why did this all work as expected in NVDA 2019.2 RC1? What changes have been made since 2019.2 RC1 to 2019.2 Stable regarding liblouis

Nothing has changed in the braille area as far as I'm aware, except for the fact that all dll's (including liblouis) have been recompiled.

@DrSooom
Copy link
Author

DrSooom commented Aug 16, 2019

Here is the logfile based on NVDA 2019.2 Portable running from a USB 3.0 Flash Drive (connected via USB 2.0). This time several Unicode characters in the Basic Latin block (U+0000 to U+007F) weren't loaded correctly. See line 181 to 194.

@DrSooom DrSooom mentioned this issue Aug 17, 2019
Merged
@DrSooom
Copy link
Author

DrSooom commented Aug 18, 2019

Same result on startup with NVDA 2019.2.1 Beta-18416 (Portable, release date: 2019-08-15) as I described here. Personally I would give this issue here a P2, as it is critical for Chinese users – and maybe others too.

@DrSooom DrSooom mentioned this issue Aug 18, 2019
Closed
@LeonarddeR
Copy link
Collaborator

This definitely looks like a liblouis issue to me, therefore I'd like to suggest opening an issue against liblouis as well.

Just to make sure, does this problem also occur with NVDA 2019.1?

@LeonarddeR LeonarddeR added component/braille component/liblouis Issues related to liblouis, such as liblouis updates and braille table additions/changes p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority labels Aug 19, 2019
@LeonarddeR
Copy link
Collaborator

@feerrenrut I think we should consider reverting the update to liblouis 3.10, i.e. go back to liblouis 3.9 and see what that does here.

@zstanecic
Copy link
Contributor

zstanecic commented Aug 19, 2019 via email •
edited by feerrenrut

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Aug 19, 2019 via email

@DrSooom
Copy link
Author

DrSooom commented Sep 25, 2019

Are you saying that you have the Chinese table loading error on this build? That would be a regression from current alpha snapshots, right?

I never tested Py3-Alpha builds. But others said that "zh-tw.ctb" loaded correctly. I'm not sure if everybody immediately looked into the Log Viewer after starting NVDA. During a quick test, it seems that this braille table is loaded correctly with NVDA 2019.2.1 Beta 1 again. But this doesn't say anything. As the HUC Braille Tables still raise that error, I just think that the total file size level has changed again.

@lukaszgo1: Yes, I own a BAUM SuperVario2 64, which got broken by an Austrian braille dealer during cleaning. More details about the still open case can be read on my website. Personally I don't intent to touch it until this case is finally closed. I had a huge luck to find a second-hand Optelec ALVA BC680 via a C2C purchase, as there is only one company in whole Austria, which sells, repairs and cleans braille displays. But repairing this specific braille display is no longer possible because "the tree" (BAUM Retec AG, manufacture) has died in October 2017. And KSG does no longer sell SC9 braille modules. Sadly there is more broken on that BAUM braille device than only 40 of 64 braille modules due to that cleaning process by the Austrian company.

@zstanecic
Copy link
Contributor

zstanecic commented Sep 25, 2019 via email

@zstanecic
Copy link
Contributor

zstanecic commented Sep 25, 2019 via email

@DrSooom
Copy link
Author

DrSooom commented Sep 25, 2019 •
edited

File name: usb-cert-baum.zip (removed on 2019-10-26)
File size: 1.54 MB (1,615,480 Bytes)
SHA-256: 281947b58571f5d371a15415ae6a5afbbc002bf029adfa4fb5b9f6f38cc93e5b

I've temporarily uploaded the BAUM braille display driver (version V7 02/17/2009 2.04.16) onto my webserver, which was released in January 2010 (based on the date of the Installer). Perhaps this driver influences the NVDA-own ALVA driver and/or the braille display auto-detection feature in NVDA. This driver package is installed on both machines – Stand-PC and NUC. But as I wrote before: the broken BAUM SuperVario2 64 isn't connected to these machines.

@zstanecic: Which OS?

@zstanecic
Copy link
Contributor

zstanecic commented Sep 25, 2019 via email

@lukaszgo1
Copy link
Contributor

@DrSooom Two more things:

  1. Could you please compress, and upload somewhere the entire folder in which portable NVDA is placed?
  2. I have a feeling that presence of older NVDA versions on your pcs might have something to do with this problem. Could you disable autostarting of whatever version is installed, reboot your machine, start the portable build either blindly or with Narrator without running installed NVDA and try to reproduce this?

@DrSooom
Copy link
Author

DrSooom commented Sep 25, 2019 •
edited

  1. 9982_NVDA_2019.3 Try-18768.7z (22.0 MB, temp. available, removed on 2019-10-26)
  2. Do you also mean the logon screen? Or shall I set up a new Win7 VM, which I could do in the upcoming days?

@lukaszgo1
Copy link
Contributor

I would start with disabling from both autostart, and logon screen, and if it still would be reproducible then go to the more time consuming process of creating a VM.

@school510587
Copy link

Hi all,

I'm a zh_TW user with Windows version 6.1.7601 service pack 1 (64-bit). I have tested both 2019.2 and alpha-18759,6cb40529 NVDA versions, and no problem occurred during zh_TW loading.

Also, I am the current maintainer of zh-tw.ctb, but no other Taiwanese user reported similar bug to me. I thus don't know existence of this issue.

@DrSooom DrSooom changed the title Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176, 2019.2 Beta-18345 and 2019.2 RC2 Auto-Detection of an Optelec ALVA BC680 causes errors on loading large braille tables on NVDA startup Sep 26, 2019
@DrSooom
Copy link
Author

DrSooom commented Sep 26, 2019 •
edited

EUREKA! I got it!

Now I know why nobody without an Optelec ALVA BC680 was able to reproduce this issue. No, it isn't caused by any braille tables – also not by my HUC Braille Tables. And I guess that it isn't caused by Liblouis too.

The kind how NVDA is started on the logon screen has changed between NVDA 2015.3 and 2015.4. And the ALVA driver has changed between NVDA 2017.4 and 2018.1. On my Stand-PC NVDA 2018.1 is installed and on my NUC 2015.3. But the symptoms are/were exactly the same on both machines with NVDA Try-18768 (Py3, will get to 2019.3).

And now: The braille display auto-detection feature was added to NVDA 2018.3 and didn't exist before. And exactly this feature in combination with a connected Optelec ALVA BC680 via USB1 or USB2 (this braille display has two USB ports) is responsible for the loading errors of Liblouis braille tables – and nothing else.

I tested the largest Liblouis braille table "zh-tw.ctb" and the HUC8 and the HUC6 Braille Tables (included into "de-de-comp8.ctb" and "de-g1.ctb" and stand-alone) multiple times with NVDA 2019.2.1 Beta 1 Portable (Liblouis 3.10.0) and NVDA Try-18768 Portable (Liblouis 3.11.0) on my Stand-PC. I also successfully tested the UTF32 files of the HUC Braille Tables with NVDA Try-18768. Okay, the more braille tables are included, the longer NVDA requires to start. If only "huc8-u+0000-u+ffff.tbi" and "huc8-u+10000-u+1ffff.tbi" are included, no lag on startup is recognizable. After including "huc8-u+20000-u+2ffff.tbi" as well, NVDA requires around four seconds to be fully started. Well, and the more braille tables are included, the longer it takes. But this isn't really relevant yet, because there are just 337 allocated Unicode characters in the Unicode planes 3 to 16 in the Unicode Standard 12.1 (may 2019).

In all testing scenarios I was immediately able to force this issue after I switched back from "Optelec ALVA 6-Serien/Protokoll-Konverter" ("display = alva") to "Automatisch (Optelec ALVA 6-Serien/Protokoll-Konverter)" ("display = auto" in the "nvda.ini") in the Braille NVDA Settings. If the braille display was chosen directly from the list of braille displays, these loading errors don't occur – on a SSD. Therefore I changed the issue title. If wanted, I also can test this by running NVDA Portable from an USB 3.0 flash drive as well as on my NUC (SSD).

@LeonarddeR: Please let me know if you need a logfile with enabled HWIO logging for fixing the braille display auto-detection feature.

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Sep 26, 2019 via email

@DrSooom
Copy link
Author

DrSooom commented Sep 26, 2019

Here are five logfiles. "p13" is from Try-18768 and the other four from Alpha-18783. The very last line in "p13" is extremely strange, as there aren't any absolute paths in the HUC Braille Tables. As this loaded process took too much time, I launched NVDA 2018.1 via the desktop shortcut – if I memorize correctly. (There were too many tests in the last 4.5 hours. 😉)

@LeonarddeR
Copy link
Collaborator

Yes, pretty sure it is as described in #9982 (comment)

I will look into the code and will provide a try build shortly.

@LeonarddeR
Copy link
Collaborator

I'm pretty sure try build try-initialDisplayFix will fix the issues you're having.

@DrSooom
Copy link
Author

DrSooom commented Sep 27, 2019

Here are ten new logfiles. I'm confused. I'm not sure if this issue is really completely solved by Try-18797, but the braille tables seems to be fully loaded on NVDA startup – excluding the "p19" log, which I couldn't reproduce again during testing. Thus "p19" only occurred once. I tested all the same braille tables, which I tested yesterday on, a SSD again. Tests on a USB 3.0 flash drive are still pending.

@DrSooom
Copy link
Author

DrSooom commented Oct 1, 2019

@LeonarddeR: Shall I test Try-18797 right now on a USB flash drive too or are you going to provide a new Try-build?

@LeonarddeR
Copy link
Collaborator

@LeonarddeR: Shall I test Try-18797 right now on a USB flash drive too or are you going to provide a new Try-build?

Yes, please. I don't have any starting points to change anything in the current try build.

@DrSooom
Copy link
Author

DrSooom commented Oct 2, 2019

Done. NVDA Try-18797 Portable works exactly the same on a USB 3.0 flash drive (connected via a USB 3.0 and a 2.0 port) like on an internal SSD.

NVDA 2019.2.1 still has this issue if the HUC Braille Tables are used. But it seems that "zh-tw.ctb" is completely loaded on startup again – I got no errors in the logfiles when using the auto-detection feature. Otherwise: Not using the braille display auto-detection feature also solves the loading error with the HUC braille Tables, as I already mentioned last Thursday. Thus this finding is also valid for NVDA 2019.2.1.

@DrSooom DrSooom changed the title Auto-Detection of an Optelec ALVA BC680 causes errors on loading large braille tables on NVDA startup Braille display auto-detection feature causes errors on loading large braille tables on NVDA startup Oct 2, 2019
@DrSooom DrSooom mentioned this issue Oct 12, 2019
Closed
@DrSooom
Copy link
Author

DrSooom commented Nov 18, 2019

@LeonarddeR: Are you planning to add your fix to NVDA 2019.3?

@LeonarddeR
Copy link
Collaborator

I'm happy to do this, if you consider this issue to be fixed after merging try-initialDisplayFix.

@DrSooom
Copy link
Author

DrSooom commented Nov 18, 2019

@LeonarddeR: Please read this comment and this comment.

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Nov 18, 2019 via email

@DrSooom
Copy link
Author

DrSooom commented Nov 18, 2019 •
edited

Summary of the issue:

If the braille display auto-detection feature is enabled and large braille table(s) (> 1 MB) are loaded on NVDA startup, the braille table(s) couldn't be completely loaded respectively compiled. Sometimes also the include opcode no longer operates and the braille output keeps blank after NVDA startup unless the braille output was updated (e.g. by opening the NVDA menu). Or only parts of the braille tables are loaded. A "Can't translate" runtime error was logged on startup.
This issue was confirmed by @DrSooom with an Optelec ALVA BC680 (connected via both USB ports) on Windows 7 64-Bit. Based on @leonardder comment in issue #9982 this issue might not be limited to the Optelec ALVA BC680, but plenty other users weren't able to reproduce this issue using other braille displays.

Hmm… I guess this is still a little bit too long. Nevertheless it should help you – hopefully.

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Nov 18, 2019 via email

@LeonarddeR LeonarddeR mentioned this issue Nov 18, 2019
Merged
@nvaccessAuto nvaccessAuto added this to the 2019.3 milestone Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component/braille component/liblouis Issues related to liblouis, such as liblouis updates and braille table additions/changes p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
Milestone
2019.3
Development

Successfully merging a pull request may close this issue.

Run initial display for braille on the main thread BabbageCom/nvda