Rhasspy 2.5 broken across the board?

I am kind of at a loss here and have been running rhasspy successfully for a long time, even rhasspy voltron. I was trying to upgrade Rhasspy to current version from 2.5 voltron to current 2.5.

It breaks all my setups:

  • Rhasspy does not work at all as venv anymore on any platform (tested pi os and manjaro, some kind of type error when entering settings and some dependency errors when installing).

  • The deb file for armhf on updated pi 3 buster does not work (timeout on training with fsticuff).

So, rhasspy 2.5 now only runs as docker? Any success stories of any other configuration than docker (or is docker also broken)?

1 Like

The docker install works fine for me (Pi4). I have not tried any of the other variants for rhasspy 2.5.

1 Like

I am currently developing with venv, seems to work ok

1 Like

@ulno, please try ./configure --enable-in-place for the venv installation going forward. I’ll update the install instructions here shorty. This uses the Python source code directly instead of installing the submodules with pip.

I think an overarching problem here is that I need to have some kind of regular release cadence, instead of haphazard updates that fix some things but break others (e.g., incorrect versions in pip requirements).

Your patience is appreciated. I’m still learning along with others how to run an open source project of this magnitude and complexity :slight_smile:

2 Likes

4 posts were split to a new topic: Scale up project development

Back to the original topic.

Ok:

Solves one problem of venv (sorry took a good while on the pi to build) on pi and x86 pc under manjaro. Training on pi still doesn’t work and times out (I initially thought it worked). No specific error messages visible. Training on pc works. So, behavior on pi is now exactly like the armhf deb. Guess I have to fire up docker on a pi that already has a gui - let’s see if that is possible…

Anybody opening a dedicated future development thread or do we discuss this on github?

1 Like

I don’t see this on my Pi 3 with either venv or debian install. What speech/intent systems are you using? Sentences/slots?

fresh install on updated buster on pi 3, 8gb sd card, default config sentences/slots (and later own sentences slots) - same result.

mqtt: local
Audio record local command: parec -d mydevice.blah.etc --channels 1 --rate 16000, udp audio port 12102
wake word: mycroft precise, udp audio (input): localhost:12102
speech to text: remote http (working - training successful - current rhasspy 2.5 in venv in manjaro on on PC)
intent recognition: fsticuffs
tts: marytts on other server
audio playing: local command, paplay
dialogue management: rhasspy
intent handling: disabled

relevant log:

DEBUG:2020-06-15 20:19:25,312] rhasspyserver_hermes: -> AsrTrain
[DEBUG:2020-06-15 20:19:25,314] rhasspyserver_hermes: Publishing 4199 bytes(s) to rhasspy/asr/raspad/train
[DEBUG:2020-06-15 20:19:25,348] rhasspyserver_hermes: -> NluTrain
[DEBUG:2020-06-15 20:19:25,350] rhasspyserver_hermes: Publishing 4199 bytes(s) to rhasspy/nlu/raspad/train
[DEBUG:2020-06-15 20:19:25,446] rhasspynlu_hermes: <- NluTrain
[DEBUG:2020-06-15 20:19:25,450] rhasspynlu_hermes: Loading /home/pi/.config/rhasspy/profiles/en/intent_graph.pickle.gz
[DEBUG:2020-06-15 20:19:25,716] rhasspynlu_hermes: -> NluTrainSuccess(id='b8f43446-2dc0-4ace-aba1-809111a22520')
[DEBUG:2020-06-15 20:19:25,717] rhasspynlu_hermes: Publishing 46 bytes(s) to rhasspy/nlu/raspad/trainSuccess
[DEBUG:2020-06-15 20:19:25,728] rhasspyserver_hermes: Handling NluTrainSuccess (topic=rhasspy/nlu/raspad/trainSuccess, id=e716e205-e6e7-460f-a813-32b42dfecee2)
... ulno: nothing seems to be running in bg that consumes cpu apart from precise eating around 100% cpu - why is that actually running during training? ...
[ERROR:2020-06-15 20:29:25,356] rhasspyserver_hermes: 
Traceback (most recent call last):
  File "/home/pi/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/home/pi/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/home/pi/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1215, in api_train
    result = await core.train()
  File "/home/pi/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 395, in train
    timeout_seconds=self.training_timeout_seconds,
  File "/home/pi/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 898, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

nothing interesting in journalctl

Now switching to local Kaldi - maybe that changes things:
Oh well, yes that runs through!?

And when switching back to remote http it fails again. So, “just” the satellite function broken?

I just found out that venv seems not to set LD_LIBRARY_PATH correctly under arch/manjaro and therefore training fails on my server, so that might be the reason for this bug with not being able to use remote-http?

Compare: https://github.com/rhasspy/rhasspy/issues/71