I am currently using version 2.2.1 which has a bug that causes the program to lockup frequently. The program locks up so badly that the only way to close it is from the taskbar and then to restart the program. (Program locks up when moving between blocks. When pressing arrow key for next block, the block flies in from right to left but the program seems to lockup in that process of moving between blocks. It is like in the process of moving between blocks (previous block on left of screen and new block on right of screen freezes as the program locks up). Sorry I don’t have a screen capture to show you. I have had this same issue on more than one computer. It happens at random blocks throughout the Bible/project). I had hoped that installing 2.2.3 would solve that issue. I did update to v.2.2.3 however that caused another major issue so I was not able to fully test if the issue was resolved. I have reverted back to v.2.2.1 for now and will continue with the random program lock ups.
This is the first I’ve heard about the problem with HearThis locking up in 2.2.1, and as far as I can see, none of the changes between 2.2.1 and 2.2.3 touched any of the code that would be likely to cause this, so it’s not very likely that 2.2.3 fixes it.
As for the current problem of HearThis locking up, I know there have been some changes over the past year or so intended to prevent places where deadlock could occur. It’s possible that one of those changes actually made things worse (at least in some situation), or it’s possible that there is another potential cause of deadlock that we have not yet found. These problems can be pretty tricky to solve, even when we can “catch them in the act” on a development computer, but I’ll certainly have a look and do my best. To help me, please answer these questions if you can:
- What version of Paratext are you using for the project you are recording? (Or if you’re recording from a Text Release Bundle, let me know that.)
- Does the lockup occur regardless of whether you click the arrow on the screen or use the right-arrow key on your keyboard?
- Does it happen only in a certain circumstance? For example, only if you navigate immediately after recording? Only immediately after playing the clip? Only while playing the clip? Only if you are just navigating through the project without recording or playing clips?
Finally, If you are using running any kind of software that might be interfering with HearThis files (disk defragmentation software, OneDrive, GoogleDrive, backup software, etc.) or accessing your sound card (Zoom, Skype, Audacity, etc.), please try stopping/disabling that software temporarily to see if that fixes the problem. I’m guessing this is not the problem, but it would be good to rule that out if possible.
I just read the details of the problem in 2.2.3 and will look into it immediately. My guess is that there is a setting that can fix the issue, but it was certainly not our intention to mess up the numbering of blocks. In that description, I saw a potential culprit for the locking problem. It’s not quite clear what the user is doing to have a separate normalized “parallel” copy of the HearThis data files, but I wonder if she is running two copies of HearThis simultaneously. That is possible, and I don’t know of any problems, but it is a scenario that is probably unusual. It’s also possible that the conflict is with whatever program she is using to copy/normalize the clips.
I have confirmed that there is a serious problem (not sure what yet) with 2.2.3 and I have removed it from the download server.
I think I was just able to reproduce this. Not 100% sure it was the same scenario, but the symptoms are identical.
I now know how to reproduce this. I am working on a fix. Meanwhile, I think the problem can be reliably avoided by wait after playback stops until the play button goes back to blue (in the default color scheme) before clicking to go to the next block (or changing chapters, books, etc.). Since a recorded clip may have a brief amount of “silence” at the end, it might seem as though the playback has stopped, but if the play button is still gray (with a yellow border), then playback is not yet complete. I hope this workaround will prevent further annoyance until I can get a real fix out (which might not be until 2021).