Implémentation de Liquidsoap dans les paquets Airtime
  • Bonjour,
    J'ai une installation d'Airtime qui tourne en test depuis plusieurs semaines. Difficile cependant de tout automatiser avec le minimum d'intervention humaine pour fabriquer les playlists nécessaires pour tourner 24/7 sans reprises récurrentes des mêmes programmes.
    Comme certains, je me suis donc plongé dans Liquidsoap pour palier aux lacunes d'Airtime en terme d'automation.

    Jusqu'à maintenant, j'ai réussi à alterner tracks, jingles et pubs avec succès. Par contre je bloque sur les points suivants:
    - A partir des paquets Ubuntu, l'implémentation de Liquidsoap dans Airtime est spécifique et je n'arrive pas à utiliser l'outil de contrôle des scripts prévu par les concepteurs "liquidsoap --check". J'obtiens un message d'erreur en retour qui me dit que Liquidsoap n'est même pas installé sur ma machine (sic)
    - J'ai essayé d'utiliser "output.file" pour fabriquer la pige réglementaire demandée par le CSA, mais le script plante systématiquement. Par contre ça marche avec "dumpfile" à l'intérieur d'un "output.icecast", mais avec la même qualité que le flux, donc ça gâche de l'espace disque et je préférerais obtenir des fichiers mp3 à 32 ou 64kb/s seulement pour satisfaire cette contrainte :)
    - Il me faudrait également collecter les métadonnées horodatées dans un fichier à plat pour fournir des relevés SACEM.

    QQun aurait-il déjà implémenté tout ça pour ses propres besoins?
    Merci par avance pour votre aide,

    Fred<br>
    Post edited by Frédéric Perrod at 2011-12-01 10:47:21
    Etheractis - Digital Online Media
    http://www.etheractis.fr/?-Radio-
  • 8 Comments sorted by
  • Vote Up0Vote Down Albert FRAlbert FR
    Posts: 1,978Member, Airtime Moderator
    pas encore, mais dans la situation actuelle airtime n'est pas utilisable pour ce genre de demande.

    pour la pige il existe des tas de solutions open sources (et même réalisables en ligne de commandes avec vlc ou mplayer par exemple)

    pour les metadonnes il faudrait voir du coté de liquidsoap, et donc avec airtime le fichier ls_script.liq

    P.S. : encore qu'il soit possible de parser les logs airtime pour savoir ce qui a été diffusé et à quelle heure (faut le faire quoi ;)


    Post edited by Albert FR at 2011-12-02 10:44:08
  • Salut Fred et Albert!

    Fred, si tu nous fais part de tes problems sur la mailing liste (en francais si tu le souhaite bien entendu), on devrait pouvoir t'aider.. En particulier ton probleme de outout.file devrait etre reglable sans trop de soucis.

    Concernant les paquets ubuntu, cela depend de la version d'ubuntu que tu utilises. Il existe des paquets backportes avec la version la plus recente fournis par radio girol.

    Enfin, pour les metadata horodate, tu devrais pouvoir utiliser on_metadata, qui recoit chaque nouvelle metadata et peux en faire pratiquement ce que tu veux.

    Bon courage!
  • Vote Up0Vote Down Albert FRAlbert FR
    Posts: 1,978Member, Airtime Moderator
    @Romain effectivement un :







    output.file* 

    pour la pige est possible, mais pas très souhaitable, vu les process déjà en cours dans airtime, il vaut mieux déporter cette opération vers une autre machine (ou en avoir une puissante ;)

    et puis il faut réaliser un vrai script liquidsoap pour gerer tout ça.
    en sachant que l'on doit garder les piges 2 ans si je ne m'abuse ...

    sinon j'utilisera plutot store_metadata, non ?

    pour liquidsoap en paquet, sourcefabric va intégrer liquidsoap dans son dépot (qui sera de tout maniere en avance par rapport à debian/ubuntu

    je pense qu'il sera souhaitable d'utiliser cette version plutot que celle de radio girol (choix de compilations, etc)

    la 2 devrait sortir d'ici noel, patience ;)

    ----

    • output.file
      (?id:string,?append:bool,?dir_perm:int,?fallible:bool,
      ?flush:int,?on_close:((string)->unit),
      ?on_start:(()->unit),?on_stop:(()->unit),?perm:int,
      ?reopen_delay:float,?reopen_on_metadata:bool,
      ?reopen_when:(()->bool),?start:bool,format('a),string,
      source('a))->active_source('a)


      Output the source stream to a file.


      • id (string – defaults to ""): Force the value of the source ID.

      • append (bool – defaults to false): Do not truncate but append in the file if it exists.

      • dir_perm (int – defaults to 511):
        Permission of the directories if some have to be created, up to umask.
        Although you can enter values in octal notation (0oXXX) they will be
        displayed in decimal (for instance, 0o777 = 7*8^2 + 7*8 + 7 = 511).

      • fallible (bool – defaults to false): Allow the child source to fail, in which case the output will be (temporarily) stopped.

      • flush (int – defaults to false): Perform a flush after each write.

      • on_close ((string)-&gt;unit – defaults to fun (_) -&gt; ()): This function will be called for each file, after that it is finished and closed. The filename will be passed as argument.

      • on_start (()-&gt;unit – defaults to {()}): Callback executed when outputting starts.

      • on_stop (()-&gt;unit – defaults to {()}): Callback executed when outputting stops.

      • perm (int – defaults to 438):
        Permission of the file if it has to be created, up to umask. You can and
        should write this number in octal notation: 0oXXX. The default value is
        however displayed in decimal (0o666 = 6*8^2 + 6*8 + 6 = 438).

      • reopen_delay (float – defaults to 120.): Prevent re-opening within that delay, in seconds.

      • reopen_on_metadata (bool – defaults to false): Re-open on every new metadata information.

      • reopen_when (()-&gt;bool – defaults to {false}): When should the output be re-opened.

      • start (bool – defaults to true):
        Automatically start outputting whenever possible. If true, an infallible
        (normal) output will start outputting as soon as it is created, and a
        fallible output will (re)start as soon as its source becomes available
        for streaming.

      • (unlabeled) (format('a)): Encoding format.

      • (unlabeled) (string): Filename where to output the stream. Some strftime conversion specifiers are available: %SMHdmY. You can also use $(..) interpolation notation for metadata.

      • (unlabeled) (source('a))

  • Salut,

    Merci pour votre aide.

    Personnellement, je trouverais plus prudent d'exporter la diffusion icecast sur un second serveur, histoire d'absorber la charge CPU et/ou RAM. C'est plus logique d'avoir la "production" d'un côté et la "diffusion" de l'autre (à l'image de l'organisation d'une station de radio)

    Comme mentionné dans mon post, j'arrive à dumper le flux dans un fichier local à partir de la commande "dumpfile" à l'intérieur d'un "output.icecast". De mémoire, ça ne charge pas le système de manière significative et de cette façon, on ne risque pas d'avoir de coupure "réseau".

    Mais j'aimerais mieux le faire avec un "output.file" qui va me permettre de coder en basse résolution à 32 ou 64 Kb/s et donc prendre moins de place disque tout en restant suffisamment intelligible pour le CSA.
    Ensuite un logrotate pour avoir un fichier par heure devrait faire l'affaire.
    Peut importe la durée légale de conservation demandée par le CSA, tu peux ensuite récupérer tes fichiers une fois par semaine et les graver sur un DVD pour archives.

    Le problème récurrent que je rencontre n'est pas de trouver quelle est la bonne commande LS pour réaliser l'opération. Il suffit d'étudier la doc pour se rendre rapidement compte des possibilités immenses qu'offre LS.
    Par contre, dès que je passe à l'implémentation, c'est galère... et même en recopiant les exemples donnés, ça plante.

    Comme je ne sais pas comment utiliser l'outil de contrôle des scripts "liquidsoap --check" sous airtime pour vérifier si mon script tiens la route avant de le relancer en prod, je dois:
    - supprimer la log sous /var/log/airtime/pypo-liquidsoap/ pour avoir les éventuels msg d'erreur sans devoir parcourir des centaines de lignes
    - modifier le script sous /usr/lib/airtime/pypo/bin/liquidsoap-scripts/
    - relancer le script avec sudo service airtime-playout restart
    - recharger VLC pour écouter si le flux est diffusé avec le résultat attendu
    Bref, c'est très laborieux quand tu dois tatonner pour trouver la bonne syntaxe...
    Je contrôle pourtant bien les couples ( ), { } et [ ] et de ne pas faire de faute de frappe dans les instructions...
    Si vous avez une meilleure méthode, je prends :)

    Je trouve cela vraiment dommage car il me semble que tous les ingrédients sont réunis dans le package airtime/liquidsoap pour fabriquer une radio de qualité PRO (format web ou FM, ou les 2) avec un petit budget, loin devant des solutions "usine à gaz" comme Rivendell.
    Félicitations aux développeurs...

    Fred

    Etheractis - Digital Online Media
    http://www.etheractis.fr/?-Radio-
  • Vote Up0Vote Down Albert FRAlbert FR
    Posts: 1,978Member, Airtime Moderator
    @Frédéric Perrod

    Dans l'idéal tu as raison, bien que la charge ne soit pas si importante que ça
    par contre au niveau qualité de la pige pour le CSA, du 64kb/s mono est le standard (il me semble qu'on l'avait demandé pour une radio que j'avais installée il y a quelques années ;)

    pour la pige tu peux la faire de différente manière, donc à toi de voir ;)
    mais un découpage à l'heure est en général aussi le standard :(|)

    sinon pour tester mes scripts j'utilise une instance virtualbox (machine virtualisée donc ), et ça marche nickel
  • Aurais-tu des références en terme de puissance consommée ou de dimensionnement de serveurs en fonction du nombre de clients connectés sur un flux?

    Autant je peux "jouer" avec la génération de flux et constater le résultat en RAM et CPU, autant je ne sais pas comment simuler 100, 200 ou 1000 clients simultanés...

    Fred
    Etheractis - Digital Online Media
    http://www.etheractis.fr/?-Radio-
  • Vote Up0Vote Down Albert FRAlbert FR
    Posts: 1,978Member, Airtime Moderator
    ben tout dépend du rapport cpu/ram
    mais par exemple sur une dedibox SC (online.net) tu peux sans problème avoir des 1000 flux
    un Dedibox DC 9000 à 128kb/s (1gb de bp)

  • Ok, merci pour ces infos.
    Effectivement, Icecast ne semble pas très gourmand en ressources :)

    Pour en revenir à mes soucis, voici la ligne que j'ai essayé d'insérer dans mon script pour récupérer mon flux dans un fichier:

    output.file(%mp3, "/home/pige/test.mp3", s)

    Pour info, j'ai simplifié au maximum en supprimant les paramètres de conversion et j'ai vérifié que les droits en écriture sont Ok dans le répertoire de destination.

    Une idée sur ce qui ne va pas?

    EDIT: Bon, j'ai la moitié de la solution, la bonne syntaxe est:

    output.file(%mp3(bitrate=32, samplerate=22050), fallible=true, "/home/pige/test.mp3", s)

    Par contre, je n'arrive pas à convertir en mono.
    stereo=false ou mono=true dans %mp3(...) me font planter mon script...

    Merci pour vos conseils :)

    Post edited by Frédéric Perrod at 2011-12-11 20:32:17
    Etheractis - Digital Online Media
    http://www.etheractis.fr/?-Radio-