La signification littérale est “Libre Embedded Linux Entertainment Center” et c'est un fork d'OpenELEC.
Mais encore?
C'est un système d'exploitation construit à partir du noyau Linux pour supporter au mieux le logiciel multimédia Kodi et spécialement pensé pour les ordinateurs de faible puissance (par exemple le Raspberry Pi.
Qu'est-ce qui le différencie de ses concurrents?
Comme OpenELEC dont il est issu, LibreELEC n'est pas un OS pré-existant adapté et optimisé dans un but précis, c'est un OS développé à partir d'un noyau de base dans le seul but de supporter un logiciel.
Il en résulte qu'ils sont réellement sensiblement plus stable que leurs concurrents mais par contre ils ne savent rien faire d'autre car ils sont volontairement bridés pour gagner en stabilité et il est impossible d'installer le moindre paquet non prévu par l'équipe de développement.

D'après les informations que l'on trouve sur la toile, LibreELEC a été créé à partir d'OpenELEC principalement pour des divergences de points de vue entre le fondateur et la majorité des développeurs en ce qui concerne les mise à jour et les alliances à faire ou pas.

Petit test avec la version stable en cours (4.2.1): c'est réactif, l'installation est simple et permet par exemple dès le départ de paramétrer manuellement le réseau, pas besoin de SSH pour passer à un clavier azerty et la stabilité semble excellente: histoire de mettre le système à rude épreuve et de voir un peu ceux que je ne connaissait pas, j'ai installé une bonne douzaine de thèmes plus ou moins lourds (Xbian n'avait pas supporté plus de 3 ou 4) et il n'y a pas eu le moindre plantage (par contre, même constat qu'avec Xbian ou RaspBMC: il faut éviter les thèmes trop lourds, pas de surprise de ce côté là).
OpenELEC est souvent présenté comme bien plus simple et limité que ses concurrents et c'est pour cela que je l'avais jusque là laissé de côté, mais, contrairement à ce que je pensait, on retrouve toutes les fonctions de XBMC Kodi, seul l'OS est limité (mais tous les services annexes sont là: SSH, Samba, etc.).

La version 5.0 beta d'OpenELEC (curieusement numérotée 4.95.1 0-8) qui inclut le nouveau XBMC Kodi¹⁾ encore en beta est disponible, et, d'après ce que l'on peut lire sur le forum OpenELEC, le tout est plutôt fonctionnel (sauf avec quelques outils du genre PVR et quelques cartes graphiques ou audio Intel) donc je tente…

J'aurais voulu pouvoir directement faire une installation sur un clef USB mais la procédure trouvée n'est pas valable et j'ai donc laissé cela de côté pour plus tard.
La procédure d'installation d'OpenELEC est par ailleurs standard dans le monde Raspberry, rapide et très simple: décompression d'une image disque sur la carte SD et 5 minutes plus tard, tout est en route! <3

Aucun problème à signaler
Les développeurs de Kodi comme ceux d'OpenELEC ont fait un sacré boulot et ce duo de versions beta fonctionne très bien sur Raspberry Pi (modèle B avec 512Mo de RAM).

Avec les versions beta d'OpenELEC, les mises à jour automatiques sont désactivées par défaut et il vaut mieux ne pas activer cette option (l'option se trouve dans l'extension OpenELEC) et procéder manuellement en téléchargeant tout simplement la version dédiée aux Raspberry Pi voulue (pas les images disque) dans le partage Update du bidule.

La configuration avancée dont je parlais se fait via cette fenêtre:

Avec le thème Confluence, cet écran est accessible par la rubrique [Système]: Avec les thèmes qui n'ont pas prévu d'accès direct, on peut y accéder par les extensions de type [Programmes].

Voir l'article dédié.

Attention aux thèmes trop gourmands en ressources. Typiquement, si lors de l'installation d'un thème, une floppée d'extensions sont installées avant qu'il soit lui-même activé (il y aura toujours une notification pour chaque extension installées), on peut presque toujours partir du principe que le thème en question sera à priori plutôt lourd.
Si l'on désinstalle le thème concerné, les extensions restent, à moins de les désinstaller manuellement
Logiquement les autres thèmes ne les utilisent pas donc l'impact en les laissant devrait être assez limité mais on ne sait jamais…

Donc l'outil OpenELEC (plus ou moins accessible selon le skin), inclut un système de sauvegarde et de restauration qui concerne aussi bien OpenELEC lui-même que Kodi. Génial ! <3
Enfin au moins sur le papier…
Dans la pratique, il peut y avoir des effets de bord étranges comme se retrouver avec tous les films dédoublés. Je me suis ainsi retrouvé avec deux éléments portant le même nom et pointant sur le même fichier et pourtant bien distincts avec chacun son statut “vu” ou pas et il a fallu restauré une sauvegarde de la base de données pour m'en sortir (car la fonction de [Nettoyage de la médiathèque] ne se préoccupe que des éléments disparus, pas des doublons ).

En conclusion: le système de sauvegarde et de restauration est bien pensé (très bien même, je persiste) mais pèche légèrement par la pratique et ne dispense pas de faire par ailleurs des sauvegardes régulières de la base de données (qu'il s'agisse d'une sauvegarde MySQL automatique ou d'un export au format “1 fichier” de Kodi.

Par défaut, OpenELEC crée sur la carte SD des dossiers destinés à recevoir les images, les films, etc. Autant dire qu'ils ne servent pas à grand chose et qu'on peut sans problème les supprimer pour faire un peu de ménage.

• En ce qui concerne les sources, il suffit d'aller dans la rubriques [Fichiers] de chacun des types de médias, de sélectionner la source en question, d'invoquer le menu contextuel (touche [C]) et de choisir [Supprimer].
  
• Pour les partages, c'est un peu plus compliqué car la configuration est assez particulière: on trouve bien un fichier /etc/samba/smb.conf contenant toutes la configuration Samba mais même pour l'utilisateur root il est en lecture seule . Voir le paragraphe ci-dessous.

Kodi n'est pas bon en ménage
Même après désinstallation, un skin laisse derrière lui des plugins et des lignes inutiles dans le fichier userdata/guisettings.xml (environ 6000 lignes quand même ! bon d'accord, j'ai chargé la mule en terme du nombre de skins testés: à peu près tous soit presque 40). Je pars du principe qu'avec une machine faible comme le Raspberry, tout élément inutile chargé en mémoire et tout processus lancé inutilement ralentissent la machine pour rien.
Pour les plugins en trop, certains sont encore chargés en mémoire et lancent un script de temps en temps même si le skin qui l'a installé est désinstallé. Pour le nettoyage, c'est par là que ça se passe.
Pour le fichier guisettings.xml, sous OpenELEC, il se trouve dans /storage/.kodi/userdata et ne peut être modifié tant que Kodi tourne (toute modification sera écrasée au reboot). Voici donc la méthode la plus simple que j'ai trouvé (via SSH):

# systemctl stop xbmc

Cette commande va fermer Kodi mais pas OpenELEC et à partir de là, on peut modifier sans problème le fichier /storage/.kodi/userdata (via SSH ou un programme comme WinSCP associé à un éditeur comme Geany ou Notepad++).

Dans la même idée (mais avec le seul intérêt de réduire le temps des sauvegardes OpenELEC), les packages téléchargés lors de l'installation des plugins restent ad vitam eternam dans /storage/.kodi/addons/packages mais le nettoyage est bien plus simple: il suffit de supprimer les fichiers.

Le fichier /etc/samba/smb.conf est donc protégé en écriture et totalement géré par OpenELEC mais il est heureusement possible de modifier la configuration par défaut à partir du fichier /storage/.config/samba.conf.sample.

• commencer par créer une copie sans l'extension finale:

cp /storage/.config/samba.conf.sample /storage/.config/samba.conf

• éditer le fichier de configuration créé ci-dessous pour y supprimer les partages en trop

nano /storage/.config/samba.conf

Voici une petite liste des partages que l'on peut supprimer sans le moindre scrupule: Emulators, Music, Pictures, Recordings, TV Shows et Videos.

Le principal défaut des cartes SD est la corruption potentielle des données au fil du temps à cause du nombre de cycles d'écritures. Dans ce cas il n'y a plus qu'à la formatter et tout recommencer
La solution consiste à utiliser une clef USB pour la partition Storage ce qui va accessoirement accélérer l'accès aux artworks en cache et aux menus

Pour en arriver là, il faut une bonne clef USB (pour des fichiers plutôt petits, les artworks en tous genres se situant entre 30 et 300Ko).
Mon choix s'est porté sur une SanDisk Extreme USB 3.0 de 32Go.
Alors oui, cette clé est bien trop grosse et surtout c'est du gâchis d'utiliser une clé USB 3.0 alors que le Raspberry Pi n'est équipé qu'en USB 2.0. Et bien pas vraiment.
Voici les résultats de tests réalisés avec FlashBench²⁾, respectivement pour la clef SanDisk Extreme en USB 3.0, la même sur un port USB 2.0, une clef Silicon Power de 8Go (USB 2.0) et une clef Sony de 16Go (USB 2.0 aussi): Si les courbes d'<color green>écriture</color> sont comparables et ne compenseraient pas la différence de prix, les courbes de <color red>lecture</color> placent la SanDisk Extreme en USB 2.0 nettement devant les deux autres.

• Commencer par une sauvegarde du système avec l'extension OpenELEC (on est jamais trop prudent)
• Éteindre le bidule (quel que soit le système installé, l'insertion d'un dispositif USB peut provoquer un redémarrage avec une éventuelle perte des données)
• Formater la clef avec une partition primaire en Ext4 avec par exemple l'étiquette StorageUSB(sous Windows, il faudra un outil comme MiniTool Partition Wizard Home Edition)
• Insérer la clef USB
• Démarrer le bidule si l'insertion de la clef ne l'a pas fait
• Se connecter en SSH
• Trouver le point de montage de la clef USB:

Habituellement, ce sera quelque chose comme /var/media/ suivi de l'étiquette choisie lors du formatage, ici /var/media/StorageUSB.

• Copier le contenu visible et caché du dossier /storage vers la clef USB

cp -r /storage/. /var/media/point_de_montage

La copie peut être longue donc c'est le bon moment pour une pause café

• Trouver l'identifiant unique ou UUID de de la clef USB

blkid

Noter le code hexadimal (le fameux idententifiant) correspondant à la clef USB (ici: 740fa9af-c200-d001-1007-a9afc200d001).

• Remonter la partition /flash pour la rendre accessible en écriture

mount /flash -o remount,rw

• Sauvegarder le fichier cmdline.txt:

cp /flash/cmdline.txt /flash/cmdline.sd

L'extension sd permettra de se souvenir si nécessaire qu'il s'agit du fichier qui était à l'origine sur la carte SD.

• Éditer le fichier pour remplacer la portion disk=/dev/mmcblk0p2 afin d'indiquer que l'on souhaite utiliser la clef USB.

nano /flash/cmdline.txt

Et voici le résultat dans mon cas:

• Il est temps de redémarrer le bidule:

reboot

Pour vérifier, il suffit de se connnecter à nouveau via SSH et d'utiliser la commande mount qui devrait renvoyer une ligne indiquant que la partition /storage pointe bien sur la clef USB: Pour aller au bout de l'idée, on peut éteindre le bidule le temps de protéger la carte SD contre l'écriture avec le loquet prévu à cet effet mais il faudra la déverrouiller pour pouvoir mettre à jour le système.

Cette procédure a été établie grâce à cette page.

Par défaut, le processeur est bridé à 700MHz mais certains le font tourner jusqu'à 1GHz

Avant d'overclocker le bidule, il est important de jeter un simple coup d’œil aux températures normales que l'on trouve dans les [Informations système] accessibles par le menu [Paramètres]:

On peut jouer sur 4 paramètres:

• la fréquence du processeur (arm_freq)
• la fréquence du GPU (gpu_freq)
• la fréquence de la RAM (sdram_freq)
• le survoltage (over_voltage)

Et voici une présentation des réglages “types” (les valeurs intermédiaires sont tout à fait possibles):

* Il faut se connecter en SSH et modifier le fichier /flash/configt.txt mais pour cela, il faut avant tout passer la mémoire flash en mode écriture:

mount /flash -o remount,rw

• Par principe, il vaut mieux sauvegarder le fichier original:

cp /flash/config.txt /flash/config.txt.original

• Puis enfin éditer le fichier:

nano /flash/config.txt

• Décommenter et éditer les lignes ci-dessous:

arm_freq=800
core_freq=300
sdram_freq=400

Vous êtes évidement libre de choisir les valeurs qui vous conviennent, à vos risques et périls

• Il ne reste plus qu'à rebooter:

reboot

La bataille fait rage
Il y a tout de même vraiment beaucoup d'adeptes du NFS qui prouvent, chiffres à l'appui, que leur protocole favori est plus rapide que SMB et moins gourmand au niveau du processeur. Au final, tout dépends du hardware, du réseau, et peut-être du taux d'humidité de l'air
Pour ma part, SAMBA est en place sur le serveur Debian sur lequel mes fichiers sont stockés et c'est une nécessité pour les partager avec des PCs Windows et par ailleurs, même à travers le réseau CPL de la Freebox, il n'y a pas le moindre problème de lecture, même sur les films HD 1080, donc pas de nécessité de mettre en place NFS.