Categorie : PC Home Cinema

Serveur Subsonic sur Rapsberry PI

Aucun commentaire sur Serveur Subsonic sur Rapsberry PI

février 27, 2013 at 9:33 Categorie :PC Home Cinema | Serveurs

Le Raspberry Pi est un excellent petit engin pour bidouiller. Pas cher, peu consommateur, tout petit, des milliers d’utilisateurs sur le web entier ne cesse de lui trouver des utilités.  En effet, son coût modique permet de l’envisager un peu partout dans votre maison dans des rôles très différents et inattendus. Chez moi, j’ai décidé de m’en servir en tant que serveur audio branché sur ma chaîne. Piloté par les PCs ou des applications mobiles/tablettes, on dispose ainsi d’un jukebox de qualité, ultra modulable, pour une fraction du prix dans le commerce d’une machine dédiée et propriétaire.

Bien sûr, il faut prendre sur soi et faire un de peu de « do it yourself », mais rien d’insurmontable, surtout quand on aime apprendre.

Commençons à zéro en allant télécharger la distribution. J’ai choisi Raspyfi, en lieu et place de l’habituel Raspbian, car j’ai eu des difficultés avec cette dernière. Si vous suivez un peu la communauté Raspberry, vous êtes peut-être déjà tombé sur des fils de discussion interminables parlant des problèmes du Raspberry avec l’USB. En effet, il semblerait qu’ils soit victime de perte de paquets lorsque l’USB est trop chargé. Ce qui est assez pénible, vous l’avouerez, quand c’est une clé wifi qui fait la connexion avec votre réseau, et que vous cherchez depuis 4 heures pourquoi vous venez de subir une énième déconnexion. Raspyfi adresse en partie ce problème, avec un peu de « tunning » : quelques options dans les  modules chargés au démarrage, on fait passer l’USB en 1.1, dans un futur proche un noyau RT sera rajouté et hop, le système est optimisé pour une utilisation sans « jutter » et autres barbarismes que les audiophiles adorent.

L’installation de Raspyfi est un jeu d’enfant, je vous conseille de vous orienter vers le site officiel ainsi que sur celui de Raspbian pour plus de détails.

Ensuite coté logiciel, pour remplir ce rôle nous avons le choix entre plusieurs solutions. Ampache, Subsonic, mpd, tous permettent de gérer une bibliothèque de sons et de contrôler la lecture à distance. Quelques points :

  • Ampache se fait vieux, les applications mobiles qui vont bien ne sont pas très belles ou n’ont pas bonne réputation
  • J’avais besoin d’un jukebox faisant aussi office de serveur de streaming, et que l’application mobile soit capable de gérer les deux modes. mpd et ses applis dérivées ne gèrent pas ça nativement. Dommage, mpd est installé de base avec Raspyfi.
  • Subsonic adresse ces deux précédents points. Cependant, à sa décharge il n’est pas tout à fait gratuit. En effet, pour utiliser les applications mobiles au delà d’un mois d’essai, il faut « acheter » une « licence de soutien » (prix libre). Le surcoût d’une « licence » de soutien ne me gênant pas particulièrement (je suis bien plus attaché au concept de liberté de l’open source qu’à la gratuité qui est souvent poussé en tant que premier argument), j’ai donc choisi Subsonic. Au passage, si vraiment vous êtes allergiques au « soutien », il est tout à fait facile de trouver un patch désactivant les limitations, ou même d’utiliser Supersonic, un fork créé à cette occasion. Et l’application mobile Androïd sans publicité est disponible sur le site des développeurs sous forme d’un apk.

Subsonic étant en java, on commence par installer un JRE. De préférence open source, on ne se refait pas. Ne faites pas les malins (comme moi qui a perdu deux heures…) et n’installez pas la version headless en pensant économiser des ressources : les librairies pulseaudio sont dans la version desktop… On installe au passage ffmpeg parce qu’on en aura besoin après :

sudo apt-get install openjdk-7-jre ffmpeg

Ensuite, on récupère et installe le paquet sur le site officiel (vérifiez si de nouvelles versions ne sont pas disponibles au lieu de recopier mon lien, petits fainéants) :

wget http://downloads.sourceforge.net/project/subsonic/subsonic/4.7/subsonic-4.7.deb

dpkg -i *.deb

Ensuite, on édite le fichier de conf de subsonic (/etc/default/subsonic) pour le faire démarrer avec un utilisateur autre que root. Ici on prend l’utilisateur mpd, puisque ça nous évite d’avoir à en configurer un nouveau (l’ajouter, le mettre dans le bon groupe, etc) :

SUBSONIC_USER=mpd

Si vous utilisez le chip audio du Raspberry plutôt qu’un dongle audio USB avec sortie optique, alors il faut réactiver le module. Je ne sais pas pourquoi, éditer le fichier /etc/modules pour rajouter la ligne « snd_bcm2835 » n’a pas marché chez moi. Si vous avez une idée, faites le moi savoir dans les commentaires. En attendant un coup de génie, rajoutez une ligne dans /etc/rc.local juste avant le exit 0 :

modprobe snd_bcm2835

Configurer votre sortie audio par défaut (dans mon cas ‘1’ pour le jack):

sudo amixer cset numid=3 1

Vous utilisez une clé wifi ? Avec WPA-2 parce que vous n’êtes pas un insouciant ? Au plus simple, éditez /etc/network/interfaces :

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid "MonSSID"
wpa-psk "masuperpassphrase"
iface default inet dhcp

Dans mon cas, j’utilise le DHCP avec des baux statiques pour mes IPs, si ce n’est pas votre cas vous devrez utiliser une configuration statique. Vous vous attendiez à ce que je vous mâche le travail en vous donnant les bonnes directives ? Décidément vous êtes vraiment fainéants aujourd’hui ! Cherchez vous-même sur le net !

Ensuite : stockez-vous vos fichiers de musique sur le réseau ? Faites un montage depuis /etc/fstab. Pour ma part, j’ai utilisé ma freebox en tant que stockage et partage Samba : tout simplement parce que je suis certain que celle-ci est toujours allumée. Voilà la ligne qui va bien chez moi (remplacez l’IP par celle qui va bien chez vous)

//192.168.0.254/Disque\040dur\Musiques /media/music cifs username=anonymous,password=,uid=mpd,file_mode=0644,dir_mode=0755,iocharset=utf8,rsize=130048,wsize=4096,_netdev,sec=ntlmv2 0 0

Tiens, on apprend au passage qu’on utilise le caractère spécial \040 pour faire un espace dans un point de montage, ou encore qu’il faut utiliser _netdev pour que le système comprenne qu’il faut que le réseau soit initié complètement avant de faire les montages. On dit merci qui ?

Pour que le mode jukebox fonctionne, il faut préciser à Subsonic quelle sortie audio utiliser. Éditer le fichier ‘/usr/bin/subsonic’ et rajouter le paramètre suivant dans la liste des paramètres de lancement java (qui représente le jack chez moi) :

'-Djavax.sound.sampled.SourceDataLine=#ALSA [plughw:0,0]' \

Allez on a presque fini. La version de ffmpeg livrée avec subsonic n’est pas adaptée à l’architecture ARM du Raspberry, il faut donc la remplacer :

sudo rm /var/subsonic/transcode/ffmpeg
sudo cp /usr/bin/ffmpeg /var/subsonic/transcode

Redémarrez Subsonic (/etc/init.d/subsonic restart), et ensuite rendez-vous sur http://<ip_du_raspberry>:4040. Subsonic est très long à se lancer sur le petit Raspberry, donc pas de panique si il ne se passe rien les premières minutes. De plus les pages jsp sont très très longues à charger les premières fois, rassurez vous là aussi, après c’est tout à fait fluide.
Je ne vais pas décrire en détail la configuration de Subsonic, c’est assez simple et vous trouverez plein de tutos sur internet. Par contre, pour vous évitez de chercher inutilement, voilà quelques points pas évidents pour utiliser Subsonic en mode Jukebox (car par défaut il stream vers votre navigateur) :

  • Configurez un « lecteur » (Paramètres –> lecteur) de type « Jukebox »
  • Configurez un utilisateur en lui donnant les droits d’utiliser le « jukebox » (Paramètres –> Utilisateurs)
  • Pour le contrôle en jukebox depuis l’application mobile/tablette, il faut utiliser le bouton « RC » accessible depuis le player (en bas à gauche).

Voilà !

XMLTV : Remplir la programmation d’une chaîne inconnue

3 commentaires sur XMLTV : Remplir la programmation d’une chaîne inconnue

novembre 1, 2011 at 3:01 Categorie :Codage | PC Home Cinema

MythTV, le plus puissant PVR open-source disponible, n’est vraiment pas doué avec les chaînes pour lesquelles il ne dispose pas de programme TV. En l’absence de flux de programmation XMLTV, l’enregistrement est très laborieux, jugez plutôt : lors d’une visualisation en direct, il se fait par tranche d’une demi heure sans possibilité de préciser l’heure de fin. Et depuis la grille de programmes, pas moyen de préciser intuitivement la tranche horaire visée. On a vu mieux comme intégration…

Afin de pallier ce problème, j’ai créé un petit script python qui génère un fichier XMLTV pour les chaînes qui n’en disposent pas. Vous le trouverez ici : XMLTVFill.py

Il dispose de quelques paramètres, comme la granularité de programmation, le nombre de jour à générer (à partir de la date du jour), un décalage horaire à ajouter, et la liste des ID XMLTV pour lesquels la programmation doit être faite. Je vous laisse les découvrir dans le fichier joint.

Récupérer un flux XMLTV pour Nolife-TV

2 commentaires sur Récupérer un flux XMLTV pour Nolife-TV

octobre 31, 2010 at 10:03 Categorie :Codage | PC Home Cinema

MISE A JOUR : Cet article n’a plus de sens, car nolife diffuse maintenant son programme TV directement en XMLTV.
Vous trouverez ce flux ici :
http://www.nolife-tv.com/noair/noair_xmltv.xml
Merci à eux !

La bizarre chaîne Nolife, diffusée sur les réseaux TV des opérateurs ADSL, possède quelques émissions intéressantes. Cependant, son statut de petite chaîne artisanale l’exclut d’emblée des sites de programmes TV. Difficile alors de s’y retrouver, notamment quand comme moi on préfère user des fonctions PVR de son Media Center plutôt que du direct.

Heureusement avec un peu d’effort on peut s’en sortir facilement. Nolife diffuse en effet ses programmes dans un format XML « propriétaire », facilement transposable dans un XML plus standard respectant la norme XMLTV. J’ai trouvé au détour d’un forum la feuille XSL d’un généreux donateur qui s’occupe de cette transformation.

Mais cela n’est pas encore parfait. En effet la programmation issue de ce flux « Noair » est pour le moins exhaustive, puisque le détail de tous les clips est donné. Ce qui mène rapidement à quelque chose de complètement illisible… C’est pourquoi j’ai codé rapidement un petit script python, basé sur la librairie XML SAX, qui regroupe  les programmes de même titre et consécutifs.

Il est disponible, en pièce jointe : xmltv-nolife

Note :

  1. Il faut que le programme « xsltproc » soit installé.
  2. Le paramètre « programmes » du script Python recense les différents programmes de Nolife. On ne peut pas en effet se contenter du titre fourni par « noair » car celui ci contient quasiment tout le temps un sous titre dépendant de l’émission du jour.
  3. Il y a une dépendance vers un module python d’Eclipse. Si je n’inclue pas de fichier j’ai un problème d’encodage à l’exécution. J’avoue avoir la flemme de chercher pourquoi. Si vous trouvez, merci de me laisser un commentaire.

MythTV et l’extinction automatique pour une machine bureautique/frontend/backend

2 commentaires sur MythTV et l’extinction automatique pour une machine bureautique/frontend/backend

septembre 3, 2010 at 10:03 Categorie :PC Home Cinema

L’une des fonctions d’un Media Center, peut être la plus impressionnante à l’usage,  est sa faculté à se transformer en un puissant magnétoscope numérique.
Une fois bien configuré, mon chouchou MythTV est capable de renvoyer au vestiaire le fameux TiVo, qui est pourtant déjà une petite révolution dans l’usage et la consommation de programmes télévisuels. La consommation différée et massive, à l’origine difficile par l’usage de supports magnétiques volumineux et nombreux, a pris un tournant avec l’apport du numérique, sa facilité de stockage et l’usage ergonomique des outils intelligents qu’il propose.

Pour atteindre cet objectif de super-magnétoscope, il faut avoir bien configurer une option essentielle : l’allumage et l’exctinction automatique de la machine. D’une part pour ne rater aucun enregistrement pour cause de machine éteinte, et d’autre par pour ne pas voir sa facture d’électricité drastiquement augmenter. Bien que simple à énoncer,  cette fonction est très complexe à mettre en oeuvre. Et pourquoi donc? Premièrement, le PC n’a pas été pensé pour ça; et deuxièmement, le grand nombre d’installations possibles rend l’automatisation de la configuration très difficile à mettre en oeuvre. Choix a donc été fait de laisser l’utilisateur final se débrouiller pour faire monter la sauce de lui même. Il faut alors se retrousser les manches et ne pas avoir peur de scripter son installation.

Après cette longue introduction, j’en viens enfin à expliquer le double but de ce billet. D’une part pour faire ce qui n’est pas fait souvent dans les howto, à savoir expliquer ce qui se passe réellement derrière la scène (à l’instar de mon précédent billet sur LIRC). Et d’autre part pour couvrir un exemple pas vraiment explicité dans les différents tutos que j’ai pu trouver : la machine MythTV frontend+backend+desktop.

AVERTISSEMENT : Cet article, qui se veut un complément et non un tutorial aveugle, est donc à apprécier en parallèle de la lecture du howto de mythtv.org sur le sujet.

Allumage et extinction de MythTV, behind the scenes

Le réveil d’un PC à une heure précise se fait par l’utilisation d’une fonction ACPI présente dans la plupart des BIOS des machines vendues au grand public. Cette fonction est activable dans les menus de votre système au démarrage, et charge est ensuite à l’OS de prévoir une interface permettant l’accès en écriture à cette horloge. C’est heureusement le cas de GNU/Linux qui présente généralement le pseudo fichier /sys/class/rtc/rtc0/wakealarm pour cette tâche. Je n’irais pas plus loin, il y a déjà abondance de matière sur le sujet sur Internet.

Petit exercice de logique : le backend de MythTV, seul à être au courant de l’heure du prochain enregistrement, doit  être celui qui configure l’heure du réveil par l’utilisation de cette interface. Afin de ne pas écrire à tout bout de champ dans la petite mémoire de la carte mère, et risquer ainsi de la corrompre ou de l’user, cette écriture doit se faire logiquement à l’arrêt de la machine afin d’assurer son réveil. Ceci implique tout aussi logiquement que MythTV soit l’acteur principal de cet arrêt. Afin de déterminer qu’une machine peut être arrêtée, MythTV va donc utiliser un certain nombre de règles basiques :

  • Est ce que qu’un frontend est connecté ?
  • Est ce qu’un enregistrement est en cours?
  • Est ce qu’un enregistrement arrive très bientôt, et est-il trop tard pour faire un arrêt?

1- Backend seul

Si toutes les réponses à ces questions sont négatives, alors MythTV provoque un arrêt. Et avant d’éteindre la machine, MythTV va écrire dans la mémoire de l’alarme pour le réveil.  Les options (commande d’arrêt, commande d’écriture dans la mémoire, différentes variables temporelles) sont accessibles depuis la configuration du backend.

Si tout s’est bien passé,  vous ne raterez pas votre fantastique Théma « L’histoire des pâtes » sur Arte. Génial non? Pas si vite, ne partez pas !! Il subsiste de nombreux problèmes. Le problème d’une telle solution est son manque de souplesse, car elle ne s’applique que pour une machine faisant office de backend seul. Un exemple : ma mythbox, à la fois frontend et backend, est configurée pour lancer une session et un frontend automatiquement au démarrage. C’est indispensable à mon avis si son usage principal est de traîner sous votre TV et non pas dans un grenier. Comment en effet envisager un Media Center qui afficherait au démarrage une odieuse fenêtre de login ou un simple environnement de bureau?
Le problème d’un tel démarrage dirigé vers un frontend, c’est que la machine ne s’arrêtera  jamais, même à la fin de l’enregistrement, car un frontend sera toujours connecté.

2- Backend et frontend.

Bien sûr, les développeurs/utilisateurs de MythTV ont  pensé à çà, et ont créé MythWelcome. Nous voilà donc dans le cas d’une machine frontend + backend avec démarrage automatique de session et de frontend.
MythWelcome est un sympathique programme qui sera lancé à la place de votre frontend et déterminera que faire : si le démarrage semble être manuel (si aucun programme à enregistrer n’est visible dans la tranche horaire à venir), alors un frontend est lancé par dessus. Si le démarrage est automatique, MythWelcome reste le seul programme lancé, et comme il ne se connecte pas au backend, ce dernier éteindra la machine en se croyant tout seul.
Autre situation : le fontend est lancé par MythWelcome; à la fin de la session, on quitte MythTV; MythWelcome repasse alors au premier plan et l’extinction peut avoir lieu dès que le backend l’a décidé.
Comme MythWelcome possède d’autres atouts dans sa manche (plage horaire de réveil automatique, verrouillage empêchant l’extinction), les développeurs ont choisi de lui confier à lui et son partenaire « mythshutdown », plutôt qu’au backend, la logique de gestion de l’arrêt de la machine. Les options (commande d’arrêt, commande d’écriture), sont désormais du ressort de MythWelcome et configurables depuis son interface. Il est bien sur nécessaire de configurer le backend afin qu’il délègue sa gestion à MythWelcome. Ceci explique l’usage de la commande mythshutdown que l’on constate dans les différents tutos sur le sujet disponibles sur Internet : le backend délègue le contrôle à cet outil bien pratique qui utilise les paramètres de MythWelcome.

Une petite subtilité que j’ai apprise à mes dépends : La commande

Command to set Wakeup Time             : mythshutdown --setwakeup $time

est un piège. Elle n’écrit en fait pas dans l’heure de réveil du bios, seulement dans la base de données. C’est en effet la commande

Server halt command                    : mythshutdown --shutdown

qui s’occupe de l’écriture, ainsi que de l’arrêt de la machine. Le but de ce changement est de permettre à MythWelcome de prendre en compte les plages de réveil quotidienne que vous pouvez configurer.
C’est une différence de fonctionnement fondamentale avec la configuration « simple » de MythTV vu dans le paragraphe « backend seul ». Vous aurez besoin de cette information si vous avez un problème et chercher à debugger votre environnement.

Super ! Voilà donc le cas d’un frontend + backend couvert. Mais qu’en est-il des autres combinaisons impliquant un backend?

3- Le combo backend et desktop.

Celui ci est vicieux. On souhaite se servir de son PC pour autre chose qu’un « simple » enregistreur Media Center.
La seule difficulté est d’empêcher MythTV d’éteindre le PC lorsqu’aucun frontend n’est connecté. MythWelcome et sa fonction de lock peuvent être utilisés pour ça, mais ce serait un détournement de sa fonction, loin d’être ergonomique qui plus est : qui aimerait voir un écran bizarre d’enregistreur numérique se lancer à l’ouverture de sa session alors qu’il souhaite juste aller consulter ses mails? Non, la solution est encore une fois décrite sur le wiki de mythtv (rubrique desktop user). On fait un petit script détectant si un utilisateur est connecté au système. Si oui, alors MythTV n’a pas le droit d’éteindre la machine. Tout simple et évident. Dans cette configuration, c’est le setup de MythTV qui est responsable de la configuration de cet ensemble, aidé d’un script de pré-extinction contrôlant les utilisateurs connectés. Ceci implique aussi d’empêcher toute extinction manuelle du système (ou alors avec un script utilisant mythshutdown).  On veillera donc du coup  à autoriser uniquement les utilisateurs à se « déconnecter », probablement par la configuration de votre environnement de bureau.

Le véritable problème arrive, avec la dernière combinaison impliquant un backend. Et c’est sur ce point que je n’ai pas vraiment vu de tutos sur Internet.

Le triple combo backend-frontend-desktop

Voilà la situation : une machine enregistrant la télévision en arrière plan, servant principalement de frontend, mais pouvant aussi dépanner pour n’importe quel tâche habituellement dévolue à la bureautique (photos, mail, vidéos de lolcat sur internet).

Dans cette configuration, voici le cahier des charges :

  • Allumage automatique sur le frontend
  • Pas d’extinction automatique si en cours d’usage bureautique
  • Allumage automatique pour un enregistrement
  • Extinction automatique après un enregistrement suite à un allumage automatique

Le point 1 et 4 implique l’utilisation de MythWelcome.
Le point 2 implique l’utilisation du script de détection d’utilisateur connecté.
Problème : si une session est lancée au démarrage, accompagnée de MythWelcome, alors le script de détection d’utilisateur connecté empêchera toujours MythTV d’éteindre la machine, ce qui ne respecte pas le point numéro 4.

Une solution sous entendue par les tutos du site MythTV, mais jamais énoncée directement, est d’utiliser la fonction de lock offerte par MythWelcome. En verrouillant l’arrêt, on se prémunit du problème et on peut alors utiliser son PC de façon bureautique. Le problème est qu’il faut ensuite enlever ce verrou, soit en lançant de nouveau MythWelcome, soit par une ligne de commande, raccourci, ou touche de télécommande configurée de façon adéquate. On a vu mieux au niveau ergonomie.
Lorsque j’ai configuré une telle machine pour mon environnement familial, j’avais des besoins très clairs : aucune contrainte superflue. Le verrou de MythWelcome dans cette situation d’usage bureautique en était clairement une. MythWelcome doit se faire complètement oublier. Si je veux cliquer sur le menu K et demander l’arrêt de l’ordinateur, je veux pouvoir le faire sans penser à déverrouiller l’extinction automatique qui doit avoir lieu.

La solution à mon problème est une petite modification toute bête du script de détection de l’utilisateur :

# Check to see if anyone is currently logged in. Return zero if not and 1 if so.
# Echoed text appears in log file. It can be removed and --quiet added to the
# grep command once you are satisfied that mythTV is working properly
result=1
#
if
    mythshutdown --check
then
    echo mythshutdown ok to shut
    result=0
else
    result=1
    echo mythshutdown not ok to shut
    echo result : $result
exit $result
fi
#
if
    w | grep -v grep | grep " 0 user"
then
    echo `date` " No one is logged in, ok to shut down." #>> /home/mythtv/.mythtv/extinction.log
    result=0
else
    echo `date` " Someone is still logged in, do not shut down?" #>> /home/mythtv/.mythtv/extinction.log
    if
        ps -edf | grep mythwelcome | grep -v grep
    then
        echo `date` " Mythwelcome is launched, so its ok to shut" #>> /home/mythtv/.mythtv/extinction.log
        result=0
    else
        echo `date` " No mythwelcome, no shutdown" #>> /home/mythtv/.mythtv/extinction.log
        result=1
    fi
fi
#
echo result : $result
exit $result

Ce script est à lancer en prérequis de tout arrêt. C’est à dire qu’il faut le placer à « Pre Shutdown check-command » dans la configuration de MythTV, à la place du « mythshutdown –check » mentionné pour la mise en place de MythWelcome. C’est d’ailleurs pour cette raison que la première tache de ce script est d’appeler « mythshutdown –check » pour effectuer les vérifications qui lui sont liées.

Ce script vérifie si un utilisateur est connecté. Si non, alors l’arrêt est autorisé (c’est par exemple le cas d’un utilisateur qui s’est déconnecté de la session). Si oui, alors il vérifie si MythWelcome est lancé. Si MythWelcome n’est pas lancé, alors c’est qu’on est en train de faire un usage bureautique de sa machine et qu’il ne faut pas s’éteindre. Mais si MythWelcome est lancé, alors nous avons là une exception à la règle interdisant l’arrêt si un utilisateur est connecté, et il est donc possible d’éteindre la machine.  Ce script étant lancé par le backend MythTV après ses propres vérifications (frontend lancé?), on ne risque pas d’interrompre une session de visualisation malgré le fait que MythWelcome soit toujours lancé lorsqu’on utilise le frontend. Vous m’avez suivi j’espère?

Bonus : Déconnexion par la touche d’une télécommande

Dans ce cadre, j’ai eu à rechercher comment déconnecter l’utilisateur par l’action d’une touche de la télécommande (toujours dans l’optique de s’affranchir au maximum des contraintes du retour à MythWelcome). Voici la commande magique valable pour KDE 4:

/usr/bin/qdbus org.kde.ksmserver /KSMServer logout 0 2 0

Il est ensuite facile de combiner cette commande avec LIRC et irexec pour qu’une touche lance le processus « sûr » d’arrêt de votre machine. Vous pouvez aussi utiliser mythshutdown à la place pour que l’arrêt soit direct plutôt que temporisé.

Pre Shutdown check-command

MythTV, les SSD et le démarrage trop rapide

Aucun commentaire sur MythTV, les SSD et le démarrage trop rapide

août 29, 2010 at 2:56 Categorie :PC Home Cinema

Souvent, les nouvelles technologies ont des problèmes de jeunesse. Fréquemment, elles n’apportent pas vraiment tous les bénéfices auxquelles on s’attendait. Et parfois même, elles marchent trop bien.

La drôle d’expérience que j’ai eu l’occasion de vivre avec un SSD fait partie de ce dernier cas.

Un des avantages du disque SSD, bien connu et qui fait baver de nombreux adeptes des benchmark, est la rapidité de démarrage du système. Dans le contexte d’un PC Home Cinema, cette caractéristique en fait un véritable « must-have », un petit plus pouvant drastiquement améliorer le WAF. C’est donc tout naturellement que, après l’achat, j’ai pris un plaisir non dénué de fierté puéril à découvrir que mon système pouvait être « prêt » (frontend MythTV lancé) en moins de 20 secondes, départ arrêté depuis grub, et ce sans optimisation particulière et alors même que j’utilise un environnement de bureau plutôt lourd (KDE). Bref, tout à fait ce que j’attendais.

Mais oh, surprise, les démons de l’informatique ont déterminé qu’il était important de me fournir matière à article, et ont donc introduit un effet de bord particulièrement vicieux : mon système démarre parfois trop vite. Ou plus exactement, MythTV se lance trop rapidement ! Alors même que je ne suis pas passé au massivement parallèle Upstart, restant fidèle au bon vieux init de System V que je maîtrise bien, le démarrage pourtant essentiellement séquentiel de mon système arrive quand même à faire des siennes. J’explique :

Symptôme : le vilain écran me demandant de rentrer les paramètres du backend à la main apparaît une fois sur deux, car le backend mentionné dans la configuration n’est pas joignable.
Cause : l’interface réseau est trop lente à se rendre disponible, les logiciels sont chargés bien plus vite que la normale, et les requêtes TCP à destination d’autres machines de mon réseau local n’aboutissent parfois  pas au moment du démarrage.
Remède : un petit script quick-and-dirty super simple qui ping ma machine principale avant de lancer MythTV. Il suffit ensuite d’appeler ce script par votre lanceur habituel en lieu et place du lanceur du frontend MythTV.

#!/bin/bash

killall mythfrontend
killall mythwelcome

ping -c2 192.168.0.1 > /dev/null
result=$?
while [ $result -ne 0 ]
do
sleep 1
#bonus : vous pouvez glisser ici un petit réveil par le réseau.
#wakeonlan -i 192.168.0.255 <adresse_mac>
ping -c2  > /dev/null
result=$?
done

mythfrontend &

Bonus

La même chose peut être valable pour lancer le backend sur une machine trop rapide. Il faut donc adapter le script /etc/init.d/mythbackend et ajouter le même genre de test simplet.
Je vous offre une petite subtilité gratuite qui mérite à elle seule cette section bonus : attention à ne pas oublier de commenter l’éventuelle ligne « set -e » ! Celle-ci à pour intéressante (et détestable dans notre cas) particularité de commander l’interruption complète du script dès lors qu’une des commandes n’a pas retourner le code ok (zéro en bash). Vous vous doutez bien que cette option est invalidante quand on cherche à tester par ping une machine susceptible de ne pas répondre.

LIRC – Quelques explications

7 commentaires sur LIRC – Quelques explications

juillet 29, 2010 at 3:53 Categorie :PC Home Cinema

On trouve de nombreux tutoriels sur le net à propos de LIRC. « Fais ci », « édite ce fichier », et « relance ça comme ça ». Et puis « bidouille ce truc aussi s’il te plaît ! ». Bref, beaucoup d’actions opérées en aveugles et un bon paquet de lignes de commande absconces pour la plupart des utilisateurs. Plutôt que de « réécrire la roue » (magnifique figure de style, n’est ce pas ?) avec un autre tuto, je vais profiter de cet article pour faire quelque chose qu’on voit rarement : décrire le fonctionnement de l’application, le pourquoi des fichiers de configuration et leur rôle.
Attention : dans cette article je ne couvrirai que les systèmes basés sur Debian.

LIRC, mais c’est quoi en fait?

LIRC est une excellente suite logicielle visant à utiliser des télécommandes avec GNU/Linux. Sa compatibilité avec tout et n’importe quoi et sa versatilité en font un incontournable de tout PC orienté Home Cinema.
Concrètement, et c’est souvent ce qu’on a du mal à comprendre la première fois qu’on y touche,  LIRC est un mot fourre-tout pour ce qui est à la fois une paquet d’éxécutables  (sous forme de démon ou non), un framework (utilisable par les application tierces), et un ensemble de modules noyaux (pour piloter le hardware de vos récepteurs).
Mais assez de présentations, entrons dans le vif du sujet :

/etc/lirc/hardware.conf, le fichier de configuration du matériel

C’est ici qu’est défini le matériel. Ça vous l’aviez compris tout seul, non?
Par contre, et là je pense que je vous apprends quelque chose,  il ne fait pas partie de LIRC ! Ce fichier de configuration est une aide, laissée par les packageurs de votre distribution afin de simplifier l’utilisation des démons contrôlant LIRC. Il est donc nécessaire de faire attention à ce que vous lisez sur Internet, car en fonction de votre distribution les paramètres peuvent drastiquement changer. Le fichier peut même être totalement inutile. (Pour l’anecdote, je l’ai appris à mes dépends en perdant quelques heures lors d’une migration Ubuntu vers Debian)
Concrètement, ce fichier est lu par le script de démarrage de LIRC (/etc/init.d/lirc,  dont le contenu change selon les distributions). Celui-ci  prépare l’environnement et construit la ligne de commande adéquate pour lancer le démon LIRC.

Je ne vais pas tout couvrir, mais les paramètres les plus importants sont :

  • REMOTE : Ah non, en fait ce paramètre ne sert pas à grand chose. Je vous ai bien eu non? Il est principalement esthétique. Mettez y ce qu’on vous dit d’y mettre et puis c’est tout.
  • REMOTE_MODULE : Le script d’initialisation parcourt ce paramètre et avant toute opération charge les modules noyaux mentionnés ici. Bien entendu ces modules doivent être installés et compatibles avec le noyau que vous utilisez actuellement.  Où les trouver ? Ils sont généralement issue directement du projet LIRC. Soit vous avez de la chance et ils sont disponibles directement dans votre distribution, patiemment reconstruit par les packageurs à chaque nouvelle version de noyau, soit vous devrez les faire vous même avec la commande m-a, acronyme de module-assistant (reportez vous aux différents tuto sur le sujet). Pour vérifier que le module est OK, n’hésitez pas à vous amuser avec les commandes lsmod, modprobe et rmmod afin de voir si celui ci se charge correctement. Le chargement du module, si OK, devrait faire apparaître un fichier périphérique dans /dev/ (exemple /dev/ttyUSB0 pour mon USBuirt)
  • REMOTE_DRIVER : Ceci indique à LIRC quel pilote utiliser pour dialoguer. Cette notion de pilote est cette fois interne à LIRC  : Il ne s’agit pas de périphérique noyau mais juste de définir comment LIRC va dialoguer avec votre périphérique /dev/machin. La subtilité, c’est que LIRC peut très bien avoir été compilé sans le support du périphérique que vous voulez utiliser. Un petit coup de /usr/sbin/lircd -H help ôtera vos doutes rapidement.
  • REMOTE_DEVICE : C’est le fichier périphérique qui a été créé par le module noyau que vous avez chargé. Ceci indique au démon LIRC avec qui il va devoir dialoguer.
  • REMOTE_LIRCD_CONF : L’emplacement du fichier de configuration des télécommandes (habituellement /etc/lirc/lircd.conf, mais vous pouvez mettre ce que vous voulez) . Voir plus bas.

Alors, tout ce beau monde, qu’est ce que ça fait au final ?
Si je prends mon exemple personnel et relativement simple de boitier USBuirt, un passage de /etc/init.d/lirc start me donne maintenant un démon lancé comme ça:

/usr/sbin/lircd --driver=usb_uirt_raw --device=/dev/ttyUSB0 --output=/dev/lircd --listen

Tout ça pour ça, pourrait-on se dire…
Mais au moins, maintenant, à chaque fois que je lance LIRC par le script d’initialisation j’obtiens : des modules chargés, un périphérique bloc /dev/ttyUSB0 monté, un joli démon lancé sur ma machine pour dialoguer avec ce /dev/ttyUSB0 selon le langage « usb_uirt_raw », et ce même démon me crée une jolie socket unix /dev/lircd pour mes logiciels favoris (voir plus bas le rôle de cette socket). Pas mal non? C’est un bon début.

Le fichier de configuration /etc/init.d/lircd.conf

Jusqu’ici le démon lircd que vous pouvez maintenant lancer sait comment dialoguer avec votre périphérique émetteur ou récepteur. Mais il ne sait pas vraiment ce qu’il va trouver pendant son dialogue, qu’est ce qu’il doit garder et qu’est ce qu’il doit jeter. Ce fichier lircd.conf est là pour ça : c’est une sorte de « carte » de votre télécommande. A l’intérieur, des listes de télécommande (si vous en utilisez plusieurs) et pour chaque télécommande des touches avec des jolis noms « user-friendly » et les codes infrarouges correspondant.

Où trouver ce fichier de configuration? Par exemple ici.
Mais si il ne s’y trouve pas, vous pouvez le faire vous même. Vous allez devoir utiliser irrecord pour ça. C’est un exécutable livré ordinairement avec LIRC. Il prend grosso modo les même paramètres que le démon « lircd », donc si vous êtes capables de configurer le fichier hardware.conf et que celui ci vous génère à chaque lancement de /etc/init.d/lirc une belle ligne de commande, alors le plus gros du travail est fait.
Exemple :

irrecord --driver=usb_uirt_raw --device=/dev/ttyUSB0 monlircd.conf

Comme irrecord dialogue directement avec le bloc périphérique, comme lircd, il ne faut pas que ce dernier soit lancé (ils sont exclusifs et très jaloux).
Coté utilisation, c’est très facile : vous suivez les instructions, et il enregistre toutes vos touches les unes après les autres en leur attribuant le joli nom que vous souhaitez.

Mais alors, comment mes applications savent jouer avec LIRC ?

C’est simple, vous vous souvenez de la socket unix dont je parlais plus haut, celle qui est préparée par le démon LIRC? Et bien les applications  se connectent à celle-ci  et écoutent toutes les touches que vous pouvez taper.
Cette socket est nommée /dev/lircd le plus souvent. Si vous souhaitez donner son chemin vous même (par exemple si vous en avez plusieurs), il est défini par le paramètre –output du démon lircd. La plupart des application vont se connecter à /dev/lircd, mais certaines d’entre elles peuvent être configurées pour se connecter au chemin de votre choix (c’est le cas par exemple de mon cher mythtv qui possède ce paramètre dans un coin de la configuration du frontend). Je vous conseille de tout laisser par défaut, c’est suffisant pour 90% des cas.

Vous l’avez compris, mais je me permets de le rappeler : pour qu’une application fonctionne avec LIRC, il faut qu’elle se branche sur la socket unix, et donc qu’elle ait été codée pour çà ! Cela semble évident au premier abord mais c’est pourtant loin d’être automatique si l’on se réfère aux questions qu’on trouve souvent sur les forums.

Et la configuration de ces applications, où se fait-elle?

/home/<user>/.lircrc, où comment en avoir marre de tous ces fichiers de configuration

Les applications se connectent à la socket lircd, OK. Mais comment l’application sait quoi faire selon la touche pressée? C’est ici qu’intervient le fichier .lircrc.
Contrairement à une autre idée fréquemment répandue, ce n’est pas un fichier de configuration de LIRC. C’est un fichier de configuration de vos applications finales !
En effet, celles ci parcourent immanquablement le fichier ~/.lircrc (et les éventuels sous fichier inclus avec la directive include), y repèrent leur propre marqueur (c’est le rôle de l’attribut « prog« ), et enregistre la carte des événements déclenchés en fonction des touches appuyées. Exemple :

begin
remote = NOVA-T500
prog = mplayer
button = Play
config = pause
end

L’appui de la touche « Play » (touche nommée ainsi dans le fichier /etc/lirc/lircd.conf qui établit la correspondance nom <–> code infrarouge), provoque l’événement « pause » dans l’application mplayer.

Et voilà ! C’était pas si compliqué (hum…)

Une synthèse s’il te plaît, pour finir un article trop long !

Comme je suis attentif à vos remarques, la voici :
lircd est un démon qui s’interface avec un périphérique /dev/machinX (donc le fichier bloc est créé par un module noyau appartenant parfois au projet LIRC) selon un protocole de communication appelé « driver » par LIRC. Une fois que lircd est lancé, celui ci va à son tour lire un fichier de conf (/etc/lirc/lircd.conf par défaut). Ce fichier décrit les codes infrarouges susceptibles d’être échangés avec le périphérique (les codes sont regroupés en appareil). Le démon créé ensuite une socket de type /dev/lircdX avec lequel les programmes peuvent s’interfacer facilement.
Les programmes se connectent à cette belle socket, lisent un fichier de conf .lircrc dans le home de l’utilisateur, repèrent le mappage touche <–> événement à déclencher, et VOUS POUVEZ ENFIN REGARDER DES VIDEOS DEPUIS VOTRE CANAPE.

Article sous licence « Creative Common Merciciel ». Vous en faites ce vous voulez, mais je veux un merci si vous l’avez bien aimé.