Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jarvis ne détecte pas toujours qu'il est déjà lancé - du coup il plante micro car micro occupé #3

Closed
ghost opened this issue Nov 27, 2016 · 9 comments
Assignees
Labels

Comments

@ghost
Copy link

ghost commented Nov 27, 2016

@alexylem, je te propose de te remonter quelques problèmes rencontrés sur l'api.

Actuellement, j'utilise beaucoup jarvis à partir de mon téléphone pour joindre l'api.

En premier, si je démarre mon terminal pour lancer jarvis en service, la plus-part des actions sur l'api est retransmise sur mon terminal:

XXXXXXXX - - [27/Nov/2016 20:15:49] "GET /lib/codemirror/lib/codemirror.js HTTP/1.1" 200 -
XXXXXXXX- - [27/Nov/2016 20:15:49] "GET /lib/codemirror/mode/shell/shell.js HTTP/1.1" 200 -
XXXXXXXX - - [27/Nov/2016 20:16:06] "POST / HTTP/1.1" 200 -
XXXXXXXX - - [27/Nov/2016 20:17:00] "POST / HTTP/1.1" 200 -

Je croyais en tenir une autre mais j'ai du mal à la reproduire.

Dès que je suis sûr de moi je te la remonte.

@ghost
Copy link
Author

ghost commented Nov 30, 2016

Bon,
j'ai l'api planté, j'ai simplement demandé ce matin la météo à jarvis.

Afin de t'aider au mieux, quelles traçabilité puis-je te transmettre.
De mon propre chef voici:

de jarvis.log:

mercredi 30 novembre 2016, 08:30:09 (UTC+0100) gilles: ----------------------------------------
mercredi 30 novembre 2016, 08:30:09 (UTC+0100) Exception happened during processing of request from ('XXXXXXXXXX', 50091)

ps afx:

2270 ?        S      0:00 /bin/bash ./jarvis.sh -n
 2366 ?        S      0:20  \_ python -m SimpleHTTPServer 8081
11931 ?        Sl    90:02  \_ python stt_engines/snowboy/main.py 0.5 stt_engines/snowboy/resources/jarvis.pmdl 
 2271 ?        S      0:00 /bin/bash ./jarvis.sh

sudo netstat -lunatp |grep 8081

le port 8081 n'est même plus ouvert.

pas de problème mémoire ni d'espace disque.

J'ai laissé jarvis tranquille depuis hier soir, jusqu'à lui demander la météo le matin.

Petite remarque, après un grand laps de temps, jarvis mange le premier mot. Je pense que c'est dû à la mise en veille d'alsa si pas sollicité => a bien vérifier car supposition.

Juste une autre remarque (quasi HS), j'utilise voxygen. mon "/tmp" contient tout les mp3 provenant de mes demandes. Cela peut devenir un problème si la machine ne redémarre pas de temps en temps ou si le ménage n'est pas fait.

@ghost
Copy link
Author

ghost commented Nov 30, 2016

Autre info, le lock est toujours dans "/tmp", si je tente de relancer jarvis, j'ai bien l'information de stopper celui-ci.

Humm, une autre intuition, il arrive que leplugin météo ne retourne rien. Si rien n'est retourné, ton pai gère ?

@ghost
Copy link
Author

ghost commented Nov 30, 2016

Rha, je viens de voir des modif sur ton api. Peux-être que cela ira mieux. En tout cas, j'ai mis à jour.

@alexylem
Copy link
Owner

Alors c'est tout à fait normal que les requêtes HTTP s'affichent dans le terminal. C'est par design et c'est justement pour voir ce qu'il se passe. Tu voudrais que ces lignes ne s'affichent pas?

Jarvis qui mange le premier mot, ca vient des réglages de seuil de silence:
alexylem/jarvis#112

Cache des phrases voxygen dans /tmp:
Oui c'est pour éviter de faire une requête pour les phrases déjà dans le cache. J'ai pas pensé au long terme, mais on pourrait imaginer ne les mettre en cache que si utilisé souvent (au moins le "Oui?") et donc virer automatiquement ceux qui ne sont pas utilisés régulièrement, n'en garder que X. Tu pourrais ouvrir un ticket pour ca c'est une bonne idée.

API qui plante si plugin meteo ne retourne rien, à tester stp, ca serait un bug. Mais à priori ca doit marcher...

@alexylem
Copy link
Owner

Autre info, le lock est toujours dans "/tmp", si je tente de relancer jarvis, j'ai bien l'information de stopper celui-ci.

Ce qui n'est pas toujours mon cas. Des fois le .lock disparait et ca lance Jarvis en double. Bien sûr ca plante car le micro est déjà utilisé par snowboy. Je pense ouvrir un ticket bientôt si je ne trouve pas la cause de ca...

@dud29
Copy link

dud29 commented Dec 5, 2016

Bonjour,
comme le post est déjà ouvert, je fais remonter mon problème ici.
Je lance jarvis.sh -b ensuite Lorsque j'utilise une requête (http://xxx.xxx.x.xx:8080/?say=hello), à priori l'application Jarvis se ferme : quand je relance Jarvis en ssh, l'appli s'ouvre normalement (il ne dit plus que l'appli fonctionne en arrière plan). Le serveur continue de tourner (je peux toujours lancer une requête http et Jarvis répond). Par contre si je relance Jarvis, il plante il me dit que mon micro et occupé. Il y a des process Jarvis qui tournent (Jarvis -n, et le serveur) si je les kill je peux relancer Jarvis et la plus de problème.
J'espère être assez clair.
Dud29

@alexylem
Copy link
Owner

alexylem commented Dec 5, 2016

Oui c'est exactement le problème. Jarvis ne détecte pas toujours qu'il est déjà lancé, et ca pourrait venir de l'API... merci @dud29 je vais regardé de ce côté.

@alexylem alexylem changed the title pb et remarques sur l'api Jarvis ne détecte pas toujours qu'il est déjà lancé - du coup il plante micro car micro occupé Dec 5, 2016
@alexylem alexylem added the bug label Dec 5, 2016
@alexylem alexylem self-assigned this Dec 5, 2016
@alexylem
Copy link
Owner

Je reproduis l'erreur en faisait dire quelquechose à Jarvis avec un processus déjà lancé. Le fichier .lock est supprimé alors qu'il ne devrait pas l'être.
Je corrige...

@Potjoe-97
Copy link

Je suis désolé de rouvrir un sujet vieux d'un an et demi, mais il me semble que je retrouve le même type de comportement aujourd'hui : utilisation de l'API, le fichier jarvis.log m'indique "Jarvis is not running", pourtant j'ai bien le service actif.... Des idées ? Issue ici

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants