La seule chose que je fait c’est :
Après vérif via « configuration manuelle », aucune autre occurence de cleardata
Oui ce cleardata que tu as trouvé suffisait pour effacer le répertoire tmp avant le patch
edit: d’ailleurs je crois que celui là efface encore le répertoire tmp, je vais regarder…
Avec ton dernier patch :
Rien dans le journal d’erreur, Journal d’application :
- 17/10/21 17:30:44 - SERVICE Erreur ligne 23:
javax.mail.MessagingException: Could not connect to SMTP host: smtp.gmail.com, port: 587;
nested exception is:
javax.net.ssl.SSLException: Unable to parse TLS packet header
mes params (idem que avec jeedom au mot de passe appli prés :
Avec le système de double identification de google on ne peut plus passer en smtp interne, il faut une identification spécifique avec un mot de passe dédié
J'ai quand même tenté et j'obtiens le même message dans le journal d'application :frowning:
Le simple fait de relancer JPI provoque la disparition du rep tmp, je peux t'envoyer le fichier de config si cela peut t'aider (3000 lignes 100 ko :( )Je t’ai répondu concernant gmail ci-dessous
Concernant le répertoire tmp j’ai vu également que le cleardata (events, var ou sync) efface encore le rep tmp, même dans le dernier patch :
J’ai corriger ça, ce sera dans le prochain patch
ton image est mal insérée.
Mais en la regardant je vois une erreur de config
SSL/TLS => port 465 et non 587
donc soit tu change le port soit tu passe en TLS
Cette fois je pense qu’on en parle plus de ce répertoire temporaire :
On ne peut choisir qu’entre deux sécurité : SSL/TLS ou STARTTTLS, pas de TLS simple ni de SSL :
Pour le tmp, plus de prob avec le dernier patch 
Deja avec ta version avec paw, jpi redemarrai régulièrement… J’avais jamais compris pk
Je vais essayer de checker ces param d economie d energie
Bonjour @dJuL
Est-ce « normal » que dans la page de suivi de JPI, JPI server soit précédé du logo de Paw ? 
Bah oui Start TLS
c’est pourtant bien marqué :
Donc si tu mets le port 587 il faut choisir START TLS et non SSL/TLS
Si tu mets 465 bah c’est SSL/TLS
Hors tu as mis 587 avec SSL/TLS donc ça ne peux pas marcher…
Oui, car j’avais la flemme de changer (j’étais pourtant à 2 doigts de le faire) 
Après ça laissera un petit clin d’œil à Paw qui aura tout de même permit à cette appli d’exister.
4 « J'aime »
Bonjour,
J’ai également un souci avec JPI, tous les matins j’ai un message Android qui dit que JPI ne répond plus et me propose d’attendre ou de fermer.
Pour véritablement le fermer, il faut que je force la fermeture de l’appli, ensuite le la réouvre et tous va bien jusqu’au lendemain.
Particularité, le serveur http est vivant même quand l’IHM defaille.
Pas vu de particularité dans les logs, je surveille ça.
Le pb vient de se produire, il n’y a rien dans les log …
Bonjour @dJuL
Pour info, j’ai désactivé streaming et detection vidéo et je n’ai plus de plantage.
JPI reste bien UP tout le temps. Cela fait plus de 12h qu’il tourne alors qu’il plantait toutes les 3h30 environ avant.
Je laisse tourner 24h pour voir et je réactiverai progressivement streaming et détection vidéo pou ressayer de trouver l’origine.
au top de mon coté Merci @dJuL la gestion de la batterie refonctionne nikel
Bonjour
Je confirme, j’ai migré 3 devices sur la dernière version et dès que je met le streaming jpi plante au bout d’un moment, obligé de relancer l’application manuellement. J’ai coupé le streaming depuis hier soir pour voir et pour le moment toujours up. Rien trouvé dans les logs.
Précision j’avais pas de problème avant
Salut @djul @Darkeyes
Je confirme que c’est bien l’activation de la fonction STREAMING/DETECTION VIDEO qui fait planter l’application JPI.
Sans cette fonction JPI activée, tout est stable. Avec l’activation reconfirmée ce matin, cela fait planter JPI. Qui ne peut d’ailleurs pas être relancé directement (blocage du serveur web après le login), il faut fermer JPI proprement puis le relancer afin que ça repartes normalement.
@Darkeyes tu utilises le streaming vidéo OU la détection de mouvement ou les deux. Il faudrait essayer de creuser pour aider @dJuL.
Pour ma part avec l’ancienne version avec PAW, j’avais des redémarrage régulier de JPI mais je n’avais pas réussi (pas creué non plus) à identifier le problème mais là maintenant ça se précise.
Curieux car j’ai laisser le streaming tourné H24 tout le mois d’Aout et ça n’a pas planté sur un seul appareil.
Pourtant de mon côté c’était pas stable avec l’ancienne version sur du long terme (le streaming plantait au bout de quelques jours).
J’ai la détection de mouvement (seulement quand écran éteint) et le streaming actif sur 4 appareils (2 tablettes et 2 téléphones, Android 5 / 6 / 7 et 9).
Et aucun plantage depuis 3 mois.
Donc ça va pas être facile de trouver pourquoi cela plante sur vos appareils…
edit: faudrait voir sur les 200 et quelques personne qui ont déjà installé la nouvelle version combien utilisent le streaming et/ou détection de mvt et combien ont le problème. En général c’est uniquement les pb qui sont postés, donc j’en déduis qu’en théorie ça doit bien marcher également chez un bon nombre de personne, à voir…
edit2: une piste en attendant, stopper et relancer le streaming dans un cron toutes les 2 heures (avec un sleep d’une seconde avant de relancer) pour voir si ça empêche le crash (on verra plus tard pour la détection de mvt)
Le scénario à importer :
{
"event": "CRON_EVENT",
"key": "0 0 0/2 ? * *",
"data": [
{
"stopCamera": ""
},
{
"sleep": "time=1"
},
{
"startStreaming": ""
}
]
}
Je fais un test depuis ce matin avec le streaming coupé.
Depuis la nouvelle monture, habituellement j’ai un crash de l’appli toutes les 20 - 24h.
J’ai 6 Go de RAM sur cette tablette et elle est très peu utilisé, je pense que l’on peu écarter un problème de mémoire.
@Darkeyes
Tu as quoi comme tablette ?