Nolife, les outils (2) : Marvin

Commençons donc cette série d’article sur les outils maison de Nolife avec le tout premier d’entre eux, conçu et programmé par notre glorieux PDG, Sébastien Ruchet.

Cet outil s’intitule sobrement « Gestionnaire de playlists » mais j’ai pris un malin plaisir à le surnommer « Marvin » assez tôt, bien évidemment en référence au robot de H2G2 (Le Guide du Routard Galactique) et à sa tendance à souvent programmer les clips les plus déprimant de la chaîne, en tout cas au début. ^^

Ce logiciel a été écrit en C# et WinForms en quelques semaines et est encore maintenu de temps en temps. Il est utilisé quotidiennement, en fait c’est un des logiciels piliers de la programmation de la chaîne.

Son but principal est de générer automatiquement les playlists au format m3u en fonction de règles préexistantes. Ces règles définissent des plages horaires de diffusion à la demi-heure près, par exemple : de 15h30 à 16h00 => clips japonais tirés de façon aléatoire.

Pour ce faire tout d’abord le logiciel va scanner tous les fichiers disponibles à la diffusion sur le serveur de fichier local de Nolife. Ces fichiers sont tous nommés de façon standard sous la forme « XXXX_YYYY.ts » ou XXXX est le type d’émission (par exemple CJ pour un Clip Japonais) et YYYY l’identifiant unique de l’émission qui peut être très variable.

Une fois ce scan terminé, on peut rentrer un certain nombre d’infos associées aux émissions : le nom de l’émission évidemment, mais surtout pour les clips nom de l’artiste, auteur/compositeur, infos SACEM, importance dans la rotation (1=clip peu diffusé, 5=clip très diffusé), nouveauté ou pas, et si l’émission est au « frigo ». Une émission au frigo ne sera jamais tirée par Marvin, donc jamais rajoutée dans les playlists générées automatiquement. C’est aussi là qu’on indique si un clip est classé au J-Top cette semaine (Marvin devra alors lui substituer une version habillée avec à l’écran les infos de classement), qu’on met en valeur les nouveau clips de la semaine…

Ces infos sont enregistrées dans la base de Marvin – qui n’est qu’en fait qu’un simple fichier texte qui pèse actuellement 1 Mo.

Enfin, on peut générer des playlists en choisissant les plages horaires à couvrir. Cela crée des fichiers m3u dans un dossier partagé qu’Alex et Zed peuvent ensuite retravailler et checker avant des les envoyer au serveur de diffusion.

Il est à noter que Marvin génère toujours des playlists plus longues que les plages horaires qu’elles doivent couvrir, car il peut arriver que les playlists s’enchaînent mal, ou qu’un programme soit offline sur le serveur de diffusion. Dans ce cas il est sauté, et si la playlist est trop courte, elle boucle. Donc des programmes « dummy » sont toujours rajoutés pour « bourrer » les playlists, qui se terminent toujours avec le clip de chaîne (ce dernier joue le rôle de warning à l’antenne pour indiquer la fin prématurée d’une playlist). Rappelons qu’une playlist trop longue sera systématiquement coupée par la suivante, ce qui est le fonctionnement normal de la chaîne.

Marvin devra aussi faire attention à ne pas répéter le même programme trop souvent, ce qui demande une analyse arrière sur plusieurs playlists différentes à chaque tirage de programme.

D’ailleurs, Marvin peut aussi analyser les playlists définitives (qui sont archivées) pour en tirer le conducteur effectif de ce qui est passé à l’antenne, car le système de Cognacq-Jay ne permet pas d’avoir des logs de la diffusion antenne – ou en tout cas ils ne nous y ont jamais donné accès.

Aujourd’hui le logiciel inclut encore toutes ses versions du module de création de playlist, celui-ci ayant été réécrit plusieurs fois (Seb est clair sur le fait qu’il n’avait aucune idée de ce qu’il fallait vraiment faire au départ).

Marvin ayant été développé très rapidement, il a évidemment des défauts. Le premier est qu’il ne fonctionne que sur un seul poste, et donc une seule personne pouvait entrer les informations en base, ce qui fait qu’au final seules les infos concernant les clips ont été vraiment rentrées (c’est obligatoire pour pouvoir définir les informations sur les rotations, etc). Au final, la base est très incomplète à ce jour.

Un second défaut est qu’il a une logique très simple qui est : 1 fichier = 1 émission. Les entrées dans la base sont créées automatiquement en fonction des fichiers trouvés sur le réseau (mais jamais effacées). D’autre part le scan des fichiers PAD (Prêt À Diffuser) sur le réseau est total à chaque lancement du logiciel, ce qui fait environ 1,5To à l’heure actuelle. Les durées des émissions sont quant à elles évaluées à la louche, car elle était déduite d’un calcul empirique sur la taille des fichiers. Ces derniers sont compressés en CBR, mais le débit a changé depuis le début de la chaîne.

Enfin, le plus gros soucis se situait au niveau des règles de création de playlists, qui étaient définies « en dur » dans le code C# et Seb devait donc les modifier lui-même à chaque changement de la grille des programmes. En 2009 il développa donc un autre outil pour définir ces règles… donc on parlera une autre fois ^^

Merci à Seb pour les corrections apportées à cet article.