Actuellement cette méthode appelle get_step() avec un paramètre booléen for_schedule. Cela pose problème car les appels à l'API de Radio France sont faits pour chaque émission ce qui ralentit l'ensemble. À optimiser

Ajouter un bouton toggle pour activer ou désactiver le mode sombre.

• "Musique" channel calls API when it should not.
• "Tournesol" channel doest not call when it should.

Actuellement, le planning est codé en dur dans la config liquidsoap. Utiliser les variables interactives peut être une solution

Actuellement les méthodes de crawling du planning sont directement dans la classe Channel. Créer une classe ChannelPlanning pour séparer la gestion du planning.

Actuellement, les données sont persistées seulement si elles diffèrent du cache. Cependant, les données risques d'expirer dans Redis avec ce comportement, il faut en plus vérifier que l'on ne dépasse pas le temps d'expiration.

Depuis Python 3.6, la bib standard permet de faire

with telnetlib.Telnet(host, port):
   ...

Utiliser ça au lieu du open_telnet_session.

Subtask of #44

• Générer la configuration pour chaque chaîne
• Créer une commande pour déclencher la génération de la configuration.

La mémoire prise par le serveur Python augmente avec le temps, sûrement un problème de gestion des connexions persistentes SSE

Pour une meilleure intégration. liens utiles :

• MDN
• Google Developers

Entre la fin du dernier programme enfant et la fin du programme parent, le timestamp de fin est mal évalué car le scheduler va rechercher les infos toutes les 4 secondes. L'erreur ne vient pas de l'API Radio France.

Pour cela il faut se renseigner sur le mocking et rendre ces fonctions plus paramétrables (utiliser le dictionnaire context donné par le watcher par exemple).

• Core :
  • Timetable
  • Génération config liquidsoap
  • Persistence
• Spécifique Pycolore :
  • Récupération infos des stations
  • Parsing config lisp (macros Hy)

Malgré l'asynchrone, il vaut visiblement mieux externaliser les SSE, voir https://github.com/dunglas/mercure

Utiliser la méthode get() au lieu de chercher directement la clé dans le dictionnaire, car cela engendre une erreur pour les métadonnées concernant autre chose que de la musique.

Réparer l'anomalie illustrée ci dessous

• Il ne devrait pas y avoir d'émission parente
• On devrait voir le titre de la diffusion à la place du titre de l'émission (en gras)

Cible

Utiliser ce genre d'url pour parser le json de la grille RTL2 https://pc.middleware.6play.fr/6play/v2/platforms/m6group_web/services/m6replay/guidetv?channel=rtl2&from=2020-04-18 00:00:00&to=2020-04-18 23:59:59&limit=99&offset=0&with=realdiffusiondates

Chaque station met à jour ses métadonnées en allant fetch des sites / API. Pour pas qu'une station empêche les autres de se mettre à jour, il faudrait rendre la méthode get_metadata() (et donc process() des chaînes et des stations dynamiques) asynchrone. Il est nécessaire de changer de dépendance pour faire des requêtes HTTP (par exemple s'orienter vers aiohttp).

Related issues

• #43

Car très peu d'écriture et comme ça, cela n'expire pas

• Top horaire
• Transition entre chaînes
• Transition avant et après coupures pub

Au lieu d'avoir un SSE par chaîne, avoir un seul endpoint sur lequel on choisit les chaîne auxquelles on s'abonne grâce à des paramètres d'url.

On passerait donc de :

GET https://api.radio.pycolore.fr/channels/tournesol/events/
GET https://api.radio.pycolore.fr/channels/musique/events/

À simplement :

GET https://api.radio.pycolore.fr/events/?channel=tournesol&channel=musique

Lorsque l'on sort de la pub, erreur fatale signalée par watcher.py :

KeyError: 'station'

3 onglets à faire :

• En direct
• Programme du jour
• En ce moment sur les autres chaînes
• Podcasts favoris

Utiliser le portage aredis

• Afficher à la fois les informations du 7/9 et des chroniques / journaux.
• Généralisation radiofrance

Les appels à l'API résultent parfois en timeout error. Il faut réguler les tentatives pour éviter de dépasser le nombre d'appels. Il faut au plus 1000 appels en 24h soit un appel toutes les 86 secondes.

Solution : Lors d'un échec d'appel à l'API, planifier la prochaine tentative à t + 90s.

Impacts:

1. Update get_schedule method (scrap https://www.rtl2.fr/grille) #45
2. Opportunity to get square thumbnail (e.g. https://www.rtl2.fr/programmes/le-double-expresso-rtl2) #46

Subtask of #44

Créer un module dans le style du manage.py de Django. Idées de commande :

• (re)start : (re)démarre
  • ... radio : le service liquidsoap
  • ... watcher : le watcher (par défaut)
  • ... all : les deux
• stop : idem que la commande ci-dessus mais pour arrêter
• generate-liquisoap-config : génère la config liquidsoap

Ce paramètre est à la fois utilisé par la webapp et par la classe de station. Cette URL devrait être dans un fichier de configuration et lue par l'app React et le programme Python

Quand le back ne communique pas de timestamp de fin de broadcast, (càd quand end=0), cacher la barre de progression du lecteur dans React

Lorsque l'on se rend sur /, rediriger vers la dernière chaîne visitée (/<endpoint>), on peut mémoriser la dernière chaîne visitée dans un cookie. Il faut permettre à l'utilisateur d'annuler/rétablir cette fonctionnalité.

Utiliser mypy pour améliorer la maintenance et l'autocomplétion.

Continuer l'implémentation du descripteur

• Intégrer le descripteur dans l'objet Channel.
• Y intégrer le publish_to_redis() : ajouter un booléen notify_changes dans le constructeur.
• Faire en sorte que Channel et Station n'héritent plus de RedisMixin.
• Faire une méthode de classe get_view utilisable par le serveur au lieu d'avoir les objets View totalement séparés.

Le modèle synchrone de Flask ne convient pas pour les SSE, FastAPI semble être un très bon candidat de remplacement.

• Pour rendre la page de lecture plus "app-like" (éviter le rechargement lors de changement de chaîne)
• En prévision d'ajout d'onglets

Empêcher deux chansons consécutives d'avoir le même artiste à la création de la playlist

Ils sont fonctionnels mais encore quelques points à finaliser.

• N'envoyer un serveur push que lorsque les données changent.
• Envoyer les nouvelles données aussi par SSE

• Playlist accessible via l'API
• Page avec playlist formatée

Comportement actuel

channel.get_schedule() regarde les créneaux occupés par les stations dans une chaine, puis appelle séquentiellement station.get_schedule() de la station en question avec le début et la fin du créneau en paramètres.

Cible

• Ne plus appeler séquentiellement mais de manière concurrente : (tasks asyncio). Peut-être d'abord gérer le planning à part de Channel pour une API plus propre. Le watcher, ainsi que process de Channel doivent donc être asynchrones
• Regrouper les appels : si une station est utilisée plusieurs fois au cours de la journée, faire un appel groupé ? (donner un itérable de slots au lieu de juste un début et une fin).

Lorsque la liste des chansons est repeuplée, les métadonnées prennent de l'avance. (La chanson affichée dans le lecteur est la chanson suivante à être jouée.)