Demon KO et Dépendances OK

Bonjour je possède une box officielle Atlas

GCast ne fonctionne plus j’ai donc décidé de passer sur TTSCast.

Dépendances OK et Demon KO

J’ai lu qu’il était possible de cocher ces paramètres mais que cela était déconseillé pour les Boxs officielles. En PJ quelques caputres et Logs.

Merci d’avance pour vos conseils.

Le plugin en NOK est le TTSCast

ttscast.txt (14,8 Ko)

Bonjour,

Merci de copier les logs des dépendances entre balises.

Passer le demon en log debug et fournir le log lors du démarrage de ce dernier même si il passe Nok

ttscast_daemon.txt (2,4 Ko)

ttscast (2).txt (1,1 Ko)

ttscast_update.txt (24,2 Ko)

Voici les fichiers des 3 logs de TTSCast après passage en debug

A la demande de les copier entre balises ??

Non je ne telecharge pas les fichiers pr les ouvrir localement.

C a copier ici entre balises

Bonjour,

J’ai fait l’effort d’ouvrir les .txt mais je rejoins @lperenna sur le fait que ce serait tellement plus simple si tu mettais les logs dans un champ “texte préformaté” directement donc dans le message :slight_smile:

D’après ces logs, il manque un composant système “_ctypes”, ce qui empêche le démon de démarrer dès le début :confused:

C’est une précaution en effet que j’indique pour les box officielles, car ce sont… des box officielles :stuck_out_tongue: donc l’OS est normalement géré par l’équipe Jeedom.

Après, chacun est libre de faire ce qu’il souhaite et cliquer où il veut, mais en connaissance de cause.

Je dirai juste que les box sont, dans certains cas, très loin d’être à jour en terme de système, et cela amène des problèmes à l’installation de certains composants. C’est pour ca que j’ai donné cette possibilité dans la page de config du plugin, car en général, ca permet de résoudre 99% des soucis d’install des dépendances :+1:

Mais avant de lancer des mises à jour systèmes (c’est la première case à cocher), tu peux déjà tenter ceci :

  • Cocher les cases 2 et 3 (Réinit de PyEnv + Réinit de Venv)
  • Cliquer sur le bouton Sauvegarder de la page (en haut à droite)
  • Relancer l’installation des dépendances (une seule fois)
  • Bien attendre que cela arrive au bout
  • Vérifier si le démon se lance ou non après cela

poster ici les logs de l’installation des dépendances (juste après ces installs, car si tu relances une 2ème fois les dépendances ensuite, on perd une partie des logs, notamment sur la partie PyEnv et Venv justement :slight_smile: )

Bonne soirée,
TiTidom.

Un grand merci !

En suivant tes conseils et process tout est OK, pas eu besoin de forcer les “MAJ systèmes” :slight_smile:

1 « J'aime »

Bonjour,

Je ne comprends pas ce qui est sous-entendu par ces phrases ? Les systèmes des boxes officielles Smart/Atlas sont construits sur mesure et testés sur chaque box à chaque nouvelle version.

S’il existe un réel manque qui ne concerne pas les dépendances nécessaires au plugin (c’est à lui de les gérer pour tout type de matériel) alors il suffit d’en faire la remontée et ce sera corrigé sur l’image système suivante.

Bonsoir Aurélien,

Merci pour ton message.

Il n’y avait aucun sous-entendu dans mon message, et surtout rien contre ni toi ni les équipes Jeedom, juste un constat sur un système qui vit dans le temps (car après l’installation d’une image à jour, il vit pendant souvent plusieurs années chez la plupart des utilisateurs), je m’explique :

déjà sur le fait des box “officielles”, c’est un constat : il est demandé par les équipes Jeedom pour pouvoir maitriser le système de ne pas les modifier, de ne pas les mettre à jour ou autre par les utilisateurs eux-mêmes : et c’est tout à fait compréhensible (comment en assurer la maintenance sinon si chacun vient à le modifier dans tous les sens), et j’ai donc respecter cela en tant que dev de plugins tiers, et je l’ai même écrit dans la doc et plusieurs fois sur le community, pour respecter et suivre ce choix fait par Jeedom.

Et je te rejoins sur le fait que le système derrière les images, au moment de leur installation, est à jour. Mais un autre constat est qu’ensuite, un grand nombre d’utilisateurs ne touchent plus à rien (pas de mise à jour du système) pendant plusieurs mois, et même la plupart du temps pendant plusieurs années, et le système “vieillit” alors inévitablement, avec les paquets (Linux) qui le composent qui deviennent obsolètes (avant même le système en lui-même). Certains de ces paquets évoluent (avec même des “breaking change”), et l’utilisateur (pour la grande majorité) ne le mettra pas à jour de lui-même, ce qui fait qu’à un moment, si le système n’est pas mis à jour, des composants ne peuvent plus fonctionner correctement.

Et je ne parle pas de passage d’une version majeure à une autre de l’OS, je parle au sein d’une même version, si elle n’est pas mise à jour depuis sa première installation, il y a alors plusieurs centaines de paquets qui sont en retard, non à jour, et comme on dépend tous (les dev) à un moment d’un paquet du système, cela a des impacts sur beaucoup de plugins, dont les miens oui.

J’ai vu ces deniers mois (sur de Atlas ou des Luna) des systèmes avec plus de 300, 400, 500 paquets non à jour, et dans certains cas, pas le choix, il faut mettre à jour le système pour que le tout se remette à fonctionner.

Alors si je me suis exprimé d’une manière qui laissait transparaître des sous-entendus, ce n’était pas mon intention.

Quant à échanger sur comment on pourrait palier à cela, ce sera avec plaisir, mais ce n’est pas l’objet de ce fil de discussion :slight_smile:

Bonne soirée,
TiTidom.

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.