Mirmo Dynamics

Si tu kiffes pas reunoi, t'écoutes pas et puis c'est tout.

To content | To menu | To search

Keyword - bidouille

Entries feed - Comments feed

Friday 20 October 2006

Relayer un stream audio avec icecast2

Pour économiser la bande passante au boulot, j'ai décidé de relayer le stream Club ! de 1.fm sur le LAN. Après avoir vainement tenté d'utiliser streamripper (on verra plus tard pourquoi vainement), j'ai sorti l'artillerie lourde: icecast2:

sudo apt-get install icecast2

Si on sait un peu lire, le script de post-configuration nous incite à aller fourrer notre nez dans /etc/default/icecast2, où l'on apprend (vers la fin) que icecast est désactivé par défaut à cause de la directive ENABLED=false. C'est en fait une feinte pour nous pousser à configurer le bousin (de toute façon si on le configure pas, il marchera pas). Direction /etc/icecast2/icecast.xml donc, pour un brin de configuration (les explications qui suivent se basent sur le fichier par défaut d'une installation sur une ubuntu).

La première partie qui nous interresse s'intitule authentication (vers la ligne 23). Elle contient les informations d'authentification pour les clients qui se connectent en tant que source (source-password), les serveurs qui se connectent en tant que slave (relay-password, en fait je ne suis pas sur à 100%, c'est une déduction) et pour l'interface d'administration (admin-user et admin-password). Une fois ces informations modifiées, direction la directive hostname, qu'on remplira avec au choix, le nom de la machine, son ip, etc. J'ai personellement mis l'ip privée de ma machine (172.16.x.y), pour que ça correspondent à la prochaine directive qui nous interresse: listen-socket. Ici on définit le port et l'ip sur laquelle icecast va écouter. En gros, si vous spécifier 127.0.0.1, votre serveur de streaming ne sera accessible qu'en local. On y met donc en général la même chose que dans hostname (172.16.x.y par exemple), avec un port qui va bien, libre de préférence (8000 par défaut).

Maintenant on passe a la partie qui nous interresse vraiment, la section relay. Rien de bien compliqué ici. Le stream que je souhaite relayer se trouve là: http://64.62.253.223:8060/, or icecast nous demande un server, un port, un point de montage (mount) et un point de montage local (local-mount). Vous avez déjà compris qu'on arrive a cette configuration:

   <relay>
       <server>64.62.253.223</server>
       <port>8060</port>
       <mount>/</mount>
       <local-mount>/1.fm</local-mount>
       <on-demand>0</on-demand>
       <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
   </relay>

Ainsi parés, il ne nous reste plus qu'a lancer modifier la directive ENABLED=false en ENABLED=true dans /etc/default/icecast2 et à lancer icecast:

sudo /etc/init.d/icecast2 start

Si vous avez bien tout fait, vous devriez pouvoir streamer depuis http://172.16.x.y:8000/1.fm, et vos collègues également ! Vous pouvez avoir une vue d'ensemble du serveur ainsi que quelques options d'administration en vous rendant sur l'interface d'admin: http://172.16.x.y:8000/ et en utilisant admin-user et admin-password pour vous authentifier.

A cela on peut ajouter un petit streamripper:

streamripper http://172.16.x.y:8000/1.fm -d ~/streamripped

Pour enregistrer. En parlant de streamripper, j'avais tenté au début de relayer avec streamripper -r, mais malgrès les apparences du netstat -pl (*:8000 LISTEN), il ne bind qu'en local, donc impossible d'en faire profiter les collègues :-)

Tuesday 3 October 2006

Submit par défaut dans un formulaire HTML

Qu'on se le dise, dans un formulaire comprenant plusieurs input de type submit, il n'est pas possible de spécifier le bouton à actionner quand on appuie sur la touche entrée. Si l'on considère que les HIG de Gnome imposent d'avoir un bouton ok à droite du bouton annuler, on se retrouve avec une incompatibilité fondamentale, puisque l'action par défaut est rarement celle d'annuler la saisie que l'on vient de faire. Plusieurs solutions s'offrent dès lors à nous:

  1. Ignorer les HIG, solution non acceptable dans mon cas (sous peine de lynchage généralisé)
  2. Supprimer purement et simplement les boutons annuler, ce qui représente une perte de fonctionnalitées trop importante dans certains cas
  3. Utiliser du JS, solution non acceptable vis à vis de mon challenge personnel (ne pas utiliser de JS avant que l'appli ne soit complètement fonctionnelle)
  4. Tricher.

J'ai donc opté pour la 4ème solution, j'ai triché. J'ai placé mes input comme le souhaitait le navigateur (ok, puis cancel), et utilisé la directive CSS direction pour réorienter le tout, ce qui donne, pour le HTML:

<fieldset class="submit">
	<input type="submit" name="submit" id="ok" value="Ok" />
	<input type="submit" name="submit" id="cancel" value="Cancel" />
</fieldset>

Et pour la CSS:

fieldset.submit {
	direction: rtl;
}

Et le rendu final.

Problèmes connus:

  • Impossible d'utiliser de ponctuation dans les boutons (un point d'exclamation à la fin d'un bouton par exemple se retrouvera au début) Un fieldset.submit input { direction: ltr; } est nécessaire pour bénéficier des ponctuations au bon endroit (merci Matt.Rixx)
  • Surement d'autres conséquences facheuses qui ne me sont pas encore tombées dessus :-)

Mais bon pour l'instant ça marche.