Ha, OK, first of all I will take it as a sign of generally good behavior both on the part of OpenEars and Pocketsphinx that it is even possible to discuss what it does after over three hours has elapsed! :) .
But, yes, I am tracking a bug regarding very long searches. It isn’t technically that they don’t return, but that the return is so delayed that it feels like a hang (from a UX perspective the same problem IMO).
It is happening because the search space on these searches is too big for some reason (my early impression is that the reason is a very long utterance due to some persistent noises being taken for an extended speech utterance, combined with something about language model weight values) and it is my current top priority to figure out and fix, but also a challenging issue to pin down. Here are the current correlations for this bug, I’m very interested in any new info you can give me about yours:
1. It appears consistently when a weight above 1.2 is applied to Rejecto when there is a particularly long utterance. This is verified.
2. It has been reported without Rejecto when background volume increases suddenly, although my own tests with the most recent version of the OpenEars beta do not replicate this.
Here is the most recent beta link:
https://politepix.com/wp-content/uploads/OpenEarsDistributionBeta.tar.bz2
I can’t take any test cases that occur over periods of hours, but if you can provide me with a test case that occurs in fewer than 10 minutes, based on the sample app plus an audio recording added to pathToTestFile, I will be very happy to add it to the data on this bug and it will help to get a faster fix.