Caractère EOF des fichiers textes : \n pour Unix et \r\n pour Windows

Caractère de fin de ligne EOF (« End Of Line »)

J’ai une précision technique à apporter au sujet du caractère EOF. En effet, dans l’article concernant les aspects logiciels de la machine à blague Chuck Norris, j’indiquais que :

« Ici, le seul moyen que j’ai trouvé pour créer un fichier source valide, c’est par le biais d’un copier-coller de l’ensemble du texte à travers l’utilitaire PuTTY. »

C’est vrai que cette technique peu élégante fonctionne. Néanmoins, je n’ai compris que récemment pourquoi la commande strfile ne générait pas de fichier .dat valide depuis le fichier .txt copié depuis mon PC Windows… explications techniques. Revenons tout d’abord à ce qui se produit lorsqu’on applique la commande strfile sur un fichier .txt crée sur un environnement Microsoft. Voici « l’erreur » qui se produit :

Erreur de la commande strfile sur un fichier utilisant le caractère \r\n comme EOF
Erreur de la commande strfile sur un fichier utilisant le caractère \r\n comme EOF

Le retour de la commande indique qu’il n’y a qu’un seul string dans le fichier .dat généré. Ce qui est faux puisque le gisement de blagues Chuck Norris en contient près de 10 000 ! Quoi qu’il en soit, le fichier ainsi généré ne permettra pas à la commande fortune de fonctionner.

Caractère EOF différent selon l’environnement

Ceci s’explique par le caractère EOF. En effet, les fichiers textes n’utilisent pas le même caractère de fin de ligne selon qu’ils sont créés sur un système Windows (\r\n) ou Unix (\n).

Pour s’en convaincre, on pourra lancer la commande :

permet d’afficher le contenu du fichier en octal en faisant apparaître le caractère EOL. La solution consiste donc à supprimer les caractères \r du fichier créé sous Windows pour qu’il soit exploitable sur le Raspberry.

Pour cela, on pourra utiliser la commande sed (Stream Editor) :

qui permet de substituer le caractère \r par rien (en prenant soin auparavant de faire une sauvegarde chucky.txt.old du fichier original avec l’option –i.old). On remarquera ici qu’on remplace ‘\r’ par rien. On aurait pu essayer de remplacer ‘\r\n’ par ‘\n’… mais cela ne fonctionne pas. Pourquoi ? Ceci est lié au fonctionnement de la commande sed qui travaille ligne par ligne :

  1. elle parcourt le Stream jusqu’au caractère ‘\n’ ;
  2. charge tous les caractères avant le caractère ‘\n’ dans une zone de travail, le caractère EOF exclus ;
  3. effectue le traitement de substitution ;
  4. si l’option -i n’est pas précisée, la commande affiche le résultat sur stdout (l’écran) et aucune modification n’est faite sur le fichier passé en paramètre.

Une fois la commande exécutée, si on relance la commande :

on s’aperçoit que la substitution a fonctionner et que le caractère EOL est désormais \n. La commande strfile génère désormais un fichier .dat correct :

Commande strfile sur un fichier utilisant le caractère \n comme caractère EOF
Commande strfile sur un fichier utilisant le caractère \n comme caractère EOF

Le fichier .dat ainsi généré contient cette fois-ci 9692 strings ! En effet, les fichiers textes n’utilisent pas le même caractère de fin de ligne selon qu’ils sont créés sur un système Windows (\r\n) ou Unix (\n). Un simple copier-coller de l’ensemble du texte à travers l’utilitaire PuTTY réalisera la conversion automatiquement.

Ambilight sur Raspberry avec Hyperion

Ambilight avec Hyperion

Vous connaissez certainement le système « Ambilight » inventé par Philips qui prolonge l’image de la TV sur le mur par éclairage de couleurs cohérentes avec l’image courante grâce à un ensemble de LED. Pour améliorer l’expérience Kodi, il est possible d’équiper le Raspberry d’un tel système à moindre frais : un ruban de LED commandé par le logiciel Hyperion.

Avant d’en dire davantage, je vous propose de découvrir l’effet à obtenir en image :

Test de l'ambilight rainbow
Test de l’ambilight rainbow

Il s’agit ici de l’effet « Rainbow » lancé depuis l’application Android Hypérion Free. Bien entendu, l’utilisation principale reste l’amélioration de l’expérience visuelle pour visionner des films, mais il est également possible d’appliquer une couleur unie en continue ou encore des effets dynamiques prédéfinis sur l’ambilight, c’est ce que nous verrons avec l’application Android une fois que tout sera en place.

Liste du matériel pour l’ambilight maison

Je vous énumère ci-dessous le matériel nécessaire, avec un lien direct sur aliexpress :

Sans compter le coût du Raspberry, le système Ambilight en lui-même revient à 49.86€. C’est quand même un prix assez contenu et tout à fait abordable. D’autant que si l’on dispose déjà d’une alimentation, on économisera 1/3 du prix. Justement, puisqu’on parle de l’alimentation, comment définir l’ampérage nécessaire et suffisant ?

Calcul de l’ampérage

Pour définir la taille (ampérage) du bloc d’alimentation, il suffit de lire les caractéristiques du ruban de LED. Pour le modèle utilisé ici, le vendeur indique un « courant de travail » de 12A par 5m. Selon la taille de la TV à équiper, on définit le métrage nécessaire : pour ma part, je ne dépasse pas 4 mètres. En faisant un produit en croix, on obtient donc (4×12)/5=9.6. Ayant pris des mesures larges et ne souhaitant pas alimenter le Raspberry (le modèle 3 demande jusqu’à 2.5A pour son simple fonctionnement), une alimentation 10A est le bon calibrage.

D’une manière générale, pour calculer l’intensité à fournir par l’alimentation, il suffit de faire l’opération suivante (P = U x I) :

(Longueur ruban x Nombre de LED par mètre x Puissance d’une LED) /  5v = Intensité nécessaire en A.

Fonctionnement du ruban WS2801

Sur le ruban de LED WS2801, chacune des LED est adressable individuellement et peut donc être allumée (ou éteinte) indépendamment de toutes les autres. Comment ça marche ?

Le bus SPI : Serial Peripheral Interface.

Le Raspberry échange avec l’ensemble de LED au travers du bus SPI (Serial Peripheral Interface) disponible sur les GPIO. La liaison SPI est un bus série synchrone full-duplex permettant la transmission de données entre plusieurs équipements selon le schéma master/slaves à l’aide de 2 lignes de signal et 2 lignes de données :

  1. SCLK : Serial Clock ;
  2. MOSI : Master Output, Slave Input ;
  3. MISO : Master Input, Slave Output ;
  4. SS : Slave Select.

Toutes ces lignes sont unidirectionnelles. Le maître génère l’horloge et initialise une transmission de données en sélectionnant l’esclave avec qui il souhaite communiquer. Pour cela, chaque esclave est adressé par le maître par une ligne individuelle SS (Slave Select) et n’est actif que lorsqu’il est sélectionné par la mise à l’état haut de la ligne SS. Une fois l’esclave sélectionné, le maître envoie les données à transmettre sur la ligne MOSI.

Schéma Master-Slave(s) d'une liaison SPI
Schéma Master-Slave(s) d’une liaison SPI

Comme l’indique l’image ci dessus, il y a autant de lignes SS que d’esclaves. Le maitre sélectionne l’esclave à qui il souhaite s’adresser en mettant la ligne SS correspondante à l’état haut et envoie sur la ligne MOSI les données à transmettre. Plus il y a d’esclaves et plus il y a de lignes Slave Select, ce qui peut parfois rendre le montage rapidement complexe quand les slaves sont nombreux, comme c’est le cas d’un ruban de LED.

Il existe une alternative plus souple : le montage « daisy chain » selon lequel :

  • les slaves sont connectés en cascade : le MISO du slave N est connecté au MOSI du slave N+1 ;
  • il n’y a qu’une seule ligne SS pour tous les slaves.
SPI daisy chained
SPI daisy chained

Seul le premier slave reçoit les données directement depuis le maître.

Tant que la ligne CS reste à l’état LOW, à chaque cycle de commande (nombre de pulse sur l’horloge pour transmettre une commande), chaque slave reçoit des données/une commande venant du composant précédent (un slave également, sauf pour le slave 1 qui reçoit les données directement depuis le maître). En effet, si la ligne CS n’est pas activée, les slaves ignorent la commande reçue et la transmettront sur leur sortie MISO lors du cycle. A chaque cycle, les commandes viennent écraser la précédente dans chaque slave,… et c’est ainsi que les données sont propagées à travers la chaîne jusqu’à ce que chaque composant ait reçu la commande appropriée. Le passage à l’état HIGH de la ligne SS donne l’ordre à l’ensemble des composants de la chaine d’exécuter la commande qui leur est parvenue.

Le maître est ainsi en mesure de faire exécuter une commande différente à chaque slave avec seulement 3 lignes : SS, CLK et MOSI.

SPI et WS2801

Dans notre cas, c’est encore particulier. Aucune donnée n’est attendue en retour des LED vers le Raspberry, on n’a pas besoin de la ligne MISO. Et l’on constate que le ruban n’utilise que 2 lignes : Data IN et Clock (en plus de l’alimentation).

Sans aucune certitude au moment de la rédaction de ce paragraphe, j’imagine que cela revient à ce que la ligne SS soit constamment à l’état LOW, ce qui permet de propager les commandes de LED en LED. Et alors pour donner l’ordre d’exécution de la commande, j’imagine que l’ordre est donné au niveau logiciel, puisque le nombre de LED présentes sur le ruban est défini dans le fichier de configuration évoqué plus loin.

Installation matérielle

Le ruban de LED WS2801 ressemble à ça :

LED stripe WS2801
LED stripe WS2801

Comme l’indique une flèche présente sur le ruban, les données ne peuvent circuler que dans un sens (indiqué par une flèche). En revanche, le courant peut être fourni sur une extrémité ou sur l’autre. Parmi les lignes décrites ci-dessus dans la paragraphe SPI, on retrouve de haut en bas :

  • 5V ;
  • CK = Clock ;
  • SI = Data IN ;
  • GND.

ATTENTION : les fils du connecteur JST ne respectent pas le code couleur conventionnel des fils : le +5V est noir et le GND est bleu ! Il est prudent de vérifier ses branchements avant de mettre sous tension.

Pour couvrir le périmètre de la TV, il est nécessaire de couper le ruban sur les traits prévus à cet effet, de les juxtaposer perpendiculairement dans les angles de l’écran puis de les raccorder en soudant 4 fils :

Soudure des lignes 5V, CK, SI et GND.
Soudure des lignes 5V, CK, SI et GND.

Un adhésif se trouve au dos du ruban de LED et facilite l’installation sur la TV sans avoir à fabriquer un support supplémentaire. Une fois placé au dos de la TV, cela donne ça :

Ruban de LED relié perpendiculairement à l'aide de fils soudés
Ruban de LED relié perpendiculairement à l’aide de fils soudés

Le schéma de câblage est le suivant (numération BOARD utilisée) :

Schéma de câblage LED Strip WS2801
Schéma de câblage LED Strip WS2801
  1. CK -> SPI0_CLK = broche 23 ;
  2. SI -> SPI0_MOSI = broche 19.

Une fois le montage réalisé, on obtient :

Connexion du ruban de LED sur les GPIO du Raspberry
Connexion du ruban de LED sur les GPIO du Raspberry

Et puisque les détails sont essentiels pour des réalisations abouties :

Kodi Box
Kodi Box

Installation logicielle

Commençons par mettre à jour le Raspberry :

Puisque le Raspberry échangera avec le ruban de l’aide au travers du bus SPI implémenté sur les GPIOs vues plus haut, il est nécessaire d’activer ce bus SPI. Pour cela, il y a deux possibilités. Editer le fichier /boot/config.txt et décommentez la ligne suivante :

Ou bien passer par l’utilitaire de configuration raspi-config > 5 Interfacing Options > P4 SPI > Activer SPI.

Installons les paquets nécessaires :

Télécharger et installer l’outil hyperion :

Hyperion est un logiciel qui va fonctionner en tant que serveur au sens software, c’est à dire service, qu’une fois le service démarré sur le Raspberry, un nouveau port sera en écoute des requêtes à destination d’Hyperion. Par défaut, ce port est 19445.

A ce stade, le serveur Hyperion n’est pas démarré et ne peut pas l’être :

Comme le suggère le retour de la commande ci-dessus, pour pouvoir démarrer, le serveur Hypérion a besoin d’un fichier de configuration : le fichier /etc/hyperion/hyperion.config.json que nous allons générer à l’aide de l’outil hypercon…

Création du fichier de configuration Hyperion.json

Télécharger l’outil Hypercon : https://hyperion-project.org/wiki/HyperCon-Information. L’utilitaire HyperCon se présente sous la forme d’un .jar (HyperCon.jar). S’agissant d’une application Java, vous aurez nécessairement besoin d’un JRE installé sur votre PC pour pouvoir l’exécuter. Une fois lancé, l’outil se présente de la manière suivante :

Configuration d'Hyperion avec HyperCon
Configuration d’Hyperion avec HyperCon

Il s’agit ici de renseigner les champs avec les paramètres correspondants à l’installation physique des LEDs derrière la TV. Pour cela, on configure le nombre de LED horizontales, à gauche et à droite. Il est possible que le pied de la TV vous contraigne à ne pas couvrir une portion centrale sur le bas de l’écran, dans ce cas, il faudra préciser le Bottom Gap en nombre de LED.

Une fois le fichier généré à l’aide du bouton « Create Hyperion Configuration » en bas à gauche, on le place donc dans le répertoire /etc/hyperion. On peut maintenant démarrer le service :

Et contrôler qu’il est correctement démarré :

On peut également s’apercevoir que le port 19445 est à l’écoute :

Testons dès à présent l’allumage de toutes les LEDS en rouge pendant 5s avec une priorité de 50 (plus prioritaire que par défaut fixé à 100) :

 

Selon le ruban, certaines couleurs RGB peuvent être inversées.

Après avoir généré un premier fichier, j’ai constaté que Hyperion affichait du bleu au lieu du vert et inversement. J’ai donc configurer le paramètre RGB Bytes Order à RBG plutôt que RGB. Par défaut configuré à RGB, ce paramètre devra être adapté selon le ruban de LED utilisé.

Voici l’ambilight en fonctionnement, avec l’activation dynamique des LED pour prolonger de manière lumineuse, l’image sur le mur :

LED lighting
LED lighting

l’application Hypérion Free pour smartphone

Et pour finir, la cerise sur le gâteau ! Téléchargez l’application Hypérion Free sur votre smartphone et vous serez en mesure de télécommander le système ambilight :

L'application Hyperion Free vous permet de commander les LEDs depuis votre smartphone
L’application Hyperion Free vous permet de commander les LEDs depuis votre smartphone

En plus du cercle chromatique, un ensemble d’effets dynamiques est disponible pour tester l’ambilight.

Maintenant, on allume l’ambilight et on fait chauffer les pop-corn !

 

 

SQLite : moteur BDR embarqué

Généralités sur les bases de données

SQLite est un moteur de base de données. Une base de données (BDD) est un outil permettant de stocker de nombreuses données dans un ensemble structuré. Plutôt que d’éparpiller l’enregistrement de l’information dans plusieurs fichiers différents, la bases de données relationnelle centralise l’information pour y accèder simplement.

Les Systèmes de Gestion de Base de Données Relationnelles (SGBDR) sont les outils permettant de gérer des ensembles de données complexes. Parmi les solutions payantes : IBM DB2, Oracle, Microsoft SQL Server,… et les solutions gratuites : PostGreSQL, SQLite, MySQL,… Un tel système permet donc de simplifier la mise à jour et/ou la suppression des données mais aussi d’éviter les incohérences (doublons).

Quel que soit le serveur cible, la formulation des requêtes est standardisée dans un langage commun : le langage SQL (Structured Query Language).

Le modèle client/serveur

Chacun des systèmes cités ci-dessus fonctionne selon le modèle client/serveur :

  • le coeur de l’application (BDD + moteur) est installé sur un serveur ;
  • l’application cliente est installé sur des postes de travail, les clients.

Chaque client accède, selon les autorisations définies par l’administrateur de BDD, aux données de la base par un protocole d’échange. Les échanges entre le client et le serveur sont fait de requêtes et de réponses. Une fois connecté au serveur, le client peut interroger le serveur à l’aide de requête (extraction, ajout, suppresion, mise à jour de données,…). Le serveur exécute la requête et retourne les résultats au client.

Le modèle embarqué

Les SGBDR client/serveur sont des candidats sérieux pour des volumes de données massifs mais impose l’installation de solutions lourdes. Ces outils ne sont pas adaptés aux applications embarquées sur un Raspberry. Alors comment embarquer ses données persistentes au sein même de l’application et les gérer de manière relationnelle ? Continuer la lecture de « SQLite : moteur BDR embarqué »

L’outil ncdu pour identifier l’origine d’une saturation disque

Espace disque saturé

Cet article décrit une méthode simple pour identifier l’origine d’une saturation disque à l’aide de l’outil ncdu. Avant d’en traquer l’origine, revenons sur l’apparition de l’incident technique qui en découlait…

Les symptômes du problème

En visionnant le film d’animation Kung Fu Panda 2 (oui, je me souviens très de la gueule du gros Panda poilu scotché à l’écran pendant le bug), l’application Kodi s’est interrompu : image figée, le Raspberry était tout simplement planté. Après un redémarrage, je vois défiler furtivement des lignes inscrites en rouge indiquant un problème mais je n’ai pas le temps de les lire. Une fois redémarré, le prompt s’affiche mais l’application Kodi ne se lance pas automatiquement comme elle devrait pourtant le faire.

J’esssaies de lancer manuellement Kodi : cela échoue. En tapant quelques commandes, je suis amené à tenter d’utiliser l’autocomplétion et là, le message d’erreur suivant apparaît :

Le message d’erreur me mets sur la piste : un manque d’espace disque.

Investigations avec ncdu

Afin d’avoir un état de l’occupation de l’espace disque, je tape la commande suivante :

On s’aperçoit que la partition monté sur / est pleine à 100%. Il y a effectivement une saturation de l’espace disque. Après quelques recherches sur Internet, je découvre un outil super intéressant nativement présent sur Raspbian : ncdu (ncurse disk usage).

Ncdu est une version récursive de la commande du et un moyen rapide pour repérer les répertoires qui occupent le plus d’espace disque.

Lançons la commande ncdu sur le répertoire / en ne comptabilisant que les fichiers et répertoires présents sur le même FileSystem que celui qui est scanné (option -x) :

Une fois l’analyse terminée (cela peut prendre quelques minutes selon la taille du FileSystem), on s’aperçoit que le répertoire /var occupe 4 Go sur les 8 Go disponibles sur la carte micro SD, ce qui est assez conséquent, la saturation est clairement liée à ce répertoire. Toujours avec l’utilitaire ncdu, on navigue à l’intérieur du répertoire /var et on obtient :

Une fois dans /var, la taille de 3,7 GiB nous interpelle, allons y :

Une fois dans /var/log, on identifie 3 fichiers particulièrement volumineux (1,2 Gib chacun) :

  1. syslog.1 ;
  2. kern.log ;
  3. messages.

Pour comprendre qu’est-ce qui pouvait bien remplir à outrance ces fichiers, j’ai rapidement regardé le contenu. J’ai pu remarquer que les lignes évoquaient une erreur de transmission réseau. J’imagine que cela est lié à quelques bugs de la carte réseau wifi qui dysfonctionne parfois. (dongle wifi en sommeil après une inutilisation prolongée). Impatient de poursuivre la visualisation de Kung Fu Panda 2, j’ai tout simplement supprimé les 3 fichiers cités ci-dessus.

Idéalement, on cherchera à comprendre pourquoi l’application écrit si fréquemment dans ces fichiers de logs (voire mettre en place les logs rotatifs) pour éviter la réapparition du problème.

Une fois les fichiers supprimés, on peut apprécier les gains obtenus :

On est ainsi passé d’un taux d’utilisation de 100% à 51%. On peut encore gagner un peu d’espace  en nettoyant le référentiel local des paquets récupérés avec la commande :

Ce nettoyage permet de passer le taux d’occupation de l’espace disque de 51% à 50%.

Remarque : Si vous ne disposez pas de l’utilitaire ncdu, une commande équivalente peut vous aider :

Il faudra soi-même relancer la commande de manière itérative sur les répertoires les plus volumineux.

Caméra de vidéosurveillance avec motion

Motion
Un système de vidéosurveillance avec motion

On a vu comment ajouter la vision au Raspberry Pi dans l’article dédié au module Pi caméra. On dispose donc d’un périphérique de capture d’images/vidéos qu’on peut utiliser à l’aide de commandes éventuellement insérées dans un script shell ou Python : c’est chouette. Mais il y a encore plus chouette : créer un système de vidéosurveillance avec motion.

Les usages sont multiples et je ne vais pas philosopher là-dessus, je suis certain que vous saurez trouver l’utilité de ce système. En tout cas, à la fin de ce tutoriel, vous serez en mesure :

  • de visualiser en temps réel le streaming vidéo de votre Raspberry Pi depuis votre smartphone ;
  • déclencher l’enregistrement vidéo et/ou être alerté par mail sur détection de mouvements.

Motion est l’outil qui va permettre de diffuser le flux vidéo en streaming, de capturer des images et des vidéos provenant d’une ou plusieurs caméras.

Installation de motion

Commençez tout d’abord par mettre à jour Raspbian avec la commande :

Maintenant, installons motion et les paquets nécessaires :

Pour demander au noyau le chargement d’un module (le drivers broadcom (bcm) vidéo for linux (v4l)) , taper la commande :

Vous devriez normalement disposer du matériel /dev/video0. Pour que le module bcm2835-v4l2 soit automatiquement chargé au démarrage par le noyau, ajoutons le au fichier /etc/modules :

Oui, c’est une commande élégante pour ajouter bcm2835-v4l2 en fin de fichier /etc/modules.

Configuration de motion

Tout d’abord, pour que motion puisse s’éxécuter en tant que processus d’arrière plan, éditez le fichier /etc/default/motion et modifiez la ligne suivante à yes :

Ce paramètre modifié, motion pourra être lancé et l’essentiel de la configuration est à réaliser dans le fichier /etc/motion/motion.conf. Editez le fichier de configuration :

Dans ce fichier, on pourra apporter les modifications suivantes

Les principales modifications portent sur les paramètres suivants :

  • Décommenter la ligne logfile /tmp/motion.log pour enregistrer les logs ;
  • Effectuer une rotation de l’image selon les besoin (0, 90, 180 et 270), ici : rotate 180 ;
  • Ajuster la largeur/hauteur en pixels de l’image : width 1280 et height 720 ;
  • Le port d’écoute du serveur web offrant le flux viédo : stream_port 8081 ;
  • Ne pas restreindre l’accès au streaming à la machine locale uniquement :  stream_localhost off ;
  • Activer l’authentification Digest : stream_auth_method 2 ;
  • Configurer les credentials (login/password) : stream_authentication username:password ;
  • Afficher un texte en bas à gauche : text_left P3TCH CAMERA %t.

Pour lancer motion, taper la commande :

Désormais, un point rouge s’allume sur le module caméra… ça tourne ! Il est possible de se connecter à l’URL : http://192.168.1.123:8081. Après authentification, on visualise le flux vidéo en tant réel.

Si vous souhaitez désativer la LED rouge qui s’allume au démarrage de motion, c’est dans le fichier /boot/config.txt que ça se passe avec le paramètre : disable_camera_led=1.

Vous pourrez découvrir que le fichier de configuration permet un paramétrage assez fin de la caméra camera les zones de détection, la luminosité, les paramètres des enregistrements,… le site officiel Motion est exhaustif sur les options du fichier de configuration.

Remarque : A ce stade, cela fonctionne mais vous devriez rencontrer une erreur au premier mouvement détecté par la caméra. En observant les logs renseignés dans le fichier /tmp/motion.log, on s’apercoit qu’il s’agit d’un problème de permission lors de l’accès au répertoire /var/lib/motion (voir extrait ci-dessous).

Pour résoudre ce problème, il faut rajouter les droits adéquats à l’utilisateur sous lequel tourne motion. Pour cela, tapez la commande :

C’est donc l’utilisateur pi qui est utilisé. La commande suivante nous renseigne sur les permissions du répertoire en question :

Ajoutez à « other » le droit en écriture avec la commande :

Désormais, motion ne s’interrompera plus suite à la détection de mouvements puisqu’il pourra écrire dans le répertoire adéquat les vidéos d’enregistrements.

 

 

Créer un media center avec Kodi

Media Center Kodi

Nous avons vu comment gérer l’espace de stockage avec Logical Volume Manager en vue de créer un serveur NAS destiné à partager le système de fichier avec NFS ou au travers d’un partage Samba. On dispose donc d’un espace de stockage conséquent pour y stocker une vidéothèque que nous allons gérer avec le media center Kodi.

Menu Principal Kodi
Menu Principal Kodi

Anciennement appelé Xbmc, Kodi est un media center qui supporte de nombreux formats multimédia. En tant que lecteur multimédia, cette application permet de lire la plupart des fichiers audio et vidéo, afficher des diaporamas d’images, regarder des vidéos en streaming, écouter la radio, consulter la météo,… Continuer la lecture de « Créer un media center avec Kodi »