Welcome morchella,
OpenEars is fine for use with keyword spotting applications. I think the way I would probably handle this requirement would be to turn on the option of having the Rejecto phonemes returned in your hypothesis, and just reject the hyp if there are too many of them in a single hypothesis.
(As a side note, I think 2 minutes is too short for demo timeout. I fully respect your need to prevent abuse, but this stuff is complicated and wouldn’t 15min accomplish the goal just as well?)
Sorry this is making things more difficult for you; that isn’t the intention and I understand that speech applications are not so simple (that was a big part of the impetus for adding the pathToTestFile which is designed to make it easy for you to replicate issues that you are working on repeatedly). Practically the timeout is more like 2:30, but to give you some background, here is a link to a study including analytics for how long apps are used on average:
http://readwrite.com/2012/01/17/study_average_app_session_lasts_about_1_minute
It found that the average app usage period is about half the length of the Rejecto timeout. The alternatives to having a timeout that is related to the average app usage length would either be the reality of people shipping the demo linked to their app for apps with short usage requirements, or having some kind of much more intrusive network license checking that would time out the demo after a fixed chronological period (like 30-60 days) which IMO would be more disruptive to development since some projects take years to complete. I think this would be worse because it would result in sales from half-finished apps that might never ship, which I’m not comfortable with as a revenue stream.
But I appreciate the feedback and get the reason for it, and I’ve been considering standardizing all of the demos to the same 4:00 length to make things easier and more consistent.