Open burin-n opened 5 years ago
This error seemed to occur only on a docker image. I fixed it by building docker image myself.
@burin-n Did you change something in the Dockerfile or have you just rebuilt the image?
I am asking this, because I also ran into this issue and a local built docker image from yesterday did not solve this problem.
From the Dockerfile I see that are potentially multiple dynamic things which will make creation of the same image again difficult: pip install tornado git clone https://github.com/kaldi-asr/kaldi git clone https://github.com/alumae/gst-kaldi-nnet2-online.git git clone https://github.com/alumae/kaldi-gstreamer-server.git
All this action do not specifiy a concrete version or commit, but always use the latest available version.
@burin-n Can you tell me what version of tornado your docker build used? Same for the git clone lines: what commits from master branch were used?
My current locally built container uses the following python modules:
root@7cf654ea3692:/opt# pip list
argparse (1.2.1)
backports-abc (0.5)
cffi (0.8.6)
chardet (2.3.0)
colorama (0.3.2)
cryptography (0.6.1)
futures (3.2.0)
html5lib (0.999)
ndg-httpsclient (0.3.2)
pip (1.5.6)
ply (3.4)
pyasn1 (0.1.7)
pycparser (2.10)
pygobject (3.14.0)
pyOpenSSL (0.14)
PyYAML (3.11)
requests (2.4.3)
setuptools (5.5.1)
simplejson (3.6.5)
singledispatch (3.4.0.3)
six (1.8.0)
tornado (5.1.1)
urllib3 (1.9.1)
wheel (0.24.0)
ws4py (0.3.2)
wsgiref (0.1.2)
root@7cf654ea3692:/opt#
Ok, I think I have found the reason for this issue.
The yaml file for my german model contains this line:
# Just a sample post-processor that appends "." to the hypothesis
post-processor: perl -npe 'BEGIN {use IO::Handle; STDOUT->autoflush(1);} s/(.*)/\1./;'
After deactivating this post-processor line, the worker.log now contains this line:
2019-01-24 13:24:27 - INFO: decoder2: 43ebf3ad-a9c9-4745-84b8-0540d01ec370: Pipeline received eos signal
This was not the case before. So adding the "." at the end of the hypothesis broke the recognition of the "EOS" (End-Of-Stream?) marker.
I used tornado==4.5.3
@burin-n Ok. But it seems that it was not a matter of any specific version of some components but rather the provided yaml file.
I am curious: how does your yaml file look like? Does it contain any post-processing commands?
@nanosonde
My yaml is exactly the same as a samplefile for librispeech English model. I didn't change anything.
I also tested with Thai. Here is my yaml https://github.com/ekapolc/ASR_classproject/blob/master/hookup/sample_nnet2.yaml
Ok, I think I have found the reason for this issue.
The yaml file for my german model contains this line:
# Just a sample post-processor that appends "." to the hypothesis post-processor: perl -npe 'BEGIN {use IO::Handle; STDOUT->autoflush(1);} s/(.*)/\1./;'
After deactivating this post-processor line, the worker.log now contains this line:
2019-01-24 13:24:27 - INFO: decoder2: 43ebf3ad-a9c9-4745-84b8-0540d01ec370: Pipeline received eos signal
This was not the case before. So adding the "." at the end of the hypothesis broke the recognition of the "EOS" (End-Of-Stream?) marker.
Jeeeeez, I have been looking for a solution for this for weeks now and I finally found it. Thanks a lot!
I downloaded librispeech model from test folder and used your's librispeech yaml.
There was no response transcript to the client side. It seemed like decoder was resetting state forever. I tracked the code and found that decoder2 stuck at this line https://github.com/alumae/kaldi-gstreamer-server/blob/master/kaldigstserver/decoder2.py#L171 There was no problem when I tested with tedlium model on the same machine.
Below is my librispeech's worker.log