Sorry if I’m being unclear or if that question has already been answered (and sorry, my technical competence is very low).
I installed Picroft on a Raspberry Pi 3B+ with a Jabra 410 Speaker, did the little tweak found here (No Audio Output on Picroft with Jabra 410), and, after running after a few errands, wiped it and did the whole process again.
Now, Mycroft only works if I ssh in it via Putty. In fact, as soon as I use CTRL + c to run a command or leave Putty, Mycroft stops working.
Do you now what could cause that problem?
Thanks in advance!
So you can only talk to it when you ssh in or does it only work via command line? Does it drop you directly to the command line interface or do you have to run through the setup questions each time? What’s in the logs (/var/log/mycroft/*)?
Hello! Thank you for your answer, and sorry for my imprecision.
When I ssh into it, it works normally and I can talk to it. I can also talk to it via command line.
Each time I ssh into it, it seems to reinitialize itself and restart all of it’s skills (see pictures 1 & 2).
I’m sorry in advance for my next questions : do you need all the logs of the audio, bus, enclosure, skills and voice logs? If so, how can I do this (because there seems to be a lot of data in those files)?
Thank you for your help!!
Image 1 :
Can I check, Mycroft won’t respond at all until you SSH into the Picroft?
Sometimes Picroft can take a while to do its initial boot for example if it finds a system update (and your system is set to auto update). It looks like you are using the dev branch which means you will be downloading an update most days of the week.
Alternatively is the issue that after SSH’ing in, if you quit the CLI using
Ctrl+C it doesn’t respond until you restart the CLI using
Exactly : Mycroft won’t respond at all until I SSH into it. And if I quit che CLI using Ctrl+C, it doesn’t work either. I admit I did not try to restart the CLI ; I could try that to see if Mycroft starts working again when I come back from work.
I tried waiting for a long time (10+ minutes) to see if it was just a long booting sequence, but it didn’t work.
I can still format the SD card and reinstall Picroft completely, but was hoping to find a less drastic solution (and to understand what happened!)
When your Picroft boots it should create a shell session and launch all of the mycroft services as well as the CLI. SSHing in creates a new shell session and connects to the existing Mycroft processes.
It sounds like your boot sequence isn’t launching the services after startup and hence this is done when you SSH in. Exiting the CLI is then terminating the running processes.
Are you able to plug your Picroft into a monitor to see what happens when it boots?
It would also be useful to check the logs after booting but before you SSH in to see if there’s anything useful in there. To make it easier to search, I’d delete or backup your existing logs first:
- SSH in to Picroft
mv /var/log/mycroft/* /some/other/directory/
- Wait for it to boot
- From your local machine - using the IP of your Picroft:
scp email@example.com.*.*:/var/log/mycroft/* /path/to/local/dir/
Was there any resolution to this post? I am having pretty much the very same problem.
I have Picroft running on a Pi 3A, a Sabrent USB Controller. When the unit boots I don’t hear the I am ready skill. However when I ssh in, CTRL+C and then issue mycroft-start debug it works perfectly. The microphone is responsive and all the audio works well.
However the second I log out of the terminal window, that’s it, if it was playing the news it terminates and the PiCroft doesn’t work.
Hey Dan, I saw in chat that you thought it might be related to having set a root user password? Have you had a chance to test that theory?