Je suis en phase de migration sur TTSCast.
Globalement la migration se passe bien, merci @TiTidom.
J’ai une seule problématique que je n’arrive pas à résoudre malgré l’ensemble des options du plugin.
Sur GoogleCast, j’avais un scénario le matin qui commencait par la radio.
Puis quelques minutes après une annonce TTS.
Puis la radio reprenait
Puis de nouveau une annonce TTS
Puis de nouveau la radio …
Sur GoogleCast, un TTS lancé, alors que la radio était encours, générait un arrêt de la radio pour le TTS puis relancait automatiquement la radio.
Je n’arrive pas à reproduire ce fonctionnement de façon fluide avec TTSCast.
J’ai essayé avec la fonction « wait » mais celle-ci n’est pas prise en compte pour la radio.
Existe-t-il une solution pour reproduire ce fonctionnement?
C’est un cas d’usage que je n’avais pas imaginé. Il n’est donc à ce stade pas implémenté.
Je vais me pencher de ce pas sur le sujet et je reviendrai vers toi prochainement avec une solution, soit en ajoutant d’autres cas d’usage à la fonction « wait », soit en implémentant le « resume », en fonction de ce qui sera possible en restant dans un usage le plus simple possible
Première étape mise en place dans la version v1.5.13 (en BETA seulement pour l’instant, à tester s’il n’y a pas d’effets de bord avant le passage en stable) disponible dès maintenant sur le market :
Implémentation de l’option « wait » dans l’ensemble des commandes de diffusion
Un scénario tel que celui décrit ci-dessous devient maintenant possible :
Les commandes type « Radios », « Youtube », « Media » (bref toutes les commandes dont on ne connait pas forcément la durée à l’avance) doivent être les dernières commandes de la « wait queue » (de l’option wait), car dès le lancement de la vidéo, je libère le numéro de leur « wait » dans le code (ce qui provoque la lecture s’il y en a de la commande « wait » suivante !
Donc s’il y a d’autres commandes à jouer derrière, il faut le gérer « à la main » (dans le scénario par exemple en faisant une pause, ou utiliser la fonction « Dans » etc…)
J’espère que cela correspond en partie à ce que tu attendais, je me pencherai dans les jours à venir dans l’implémentation de la fonction « resume » (mais celle-ci est un peu plus complexe à gérer )
Merci pour ta réactivité.
Je viens d’effectuer les tests dans mon cas d’usage.
Cela fonctionne parfaitement. La radio et les TTS s’enchainent très bien.
Néanmoins (mais pas d’impact pour moi), je me suis aperçu que si l’option « Désactiver le ‹ ding › des commandes » n’est pas active alors on a le ding Google mais la radio ne reprend pas.
Le résultat est le même en ajoutant la fonction « ding » : false dans le lancement de la radio.
A part ce petit point, c’est parfait.
Un grand merci.
Bizarre l’histoire du ding, j’avais fait le test avec et sans et cela ne change rien chez moi.
Pourrais-tu me décrire (capture d’écran du scénario par exemple) exactement comment tu fais ton scénario ? (car j’imagine que c’est un scénario derrière)
J’ai refait les tests pour valider.
Et petite erreur de ma part, si la fonction « ding »: false est présente alors la reprise de la radio se fait bien.
En revanche, si la fonction est absnete alors pas de reprise de la radio après le ding Google.
Voici une capture d’écran du scénario de test que j’ai fait pour valider le fonctionnement:
pourquoi utiliser l’option force à plusieurs endroits de ton 2ème scénario ? Car attention, cette option « force » casse (volontairement) la chaine des « wait » pour jouer la notification où il y a le « force » (on s’en sert par exemple pour que quoi qu’il arrive, la notification d’une alarme soit jouée instantanément)
Car de ce que je vois, cela pourrait être la cause de ta radio qui ne reprend pas (car elle est annulée par le « force » de la commande juste avant)
Il s’agissait d’un scenario bac à sable pour tester.
Mais en effet, il y avait plus simple à faire.
Voici le scenario finalisé, qui fonctionne avec la version beta du jour.
)
