Yop,

un tout petit tour d’horizon s’impose. Le travail sur (et autour de) Enna fait son petit bonhomme de chemin. Le design était sans cesse modifié mais depuis quelques semaines on a enfin quelque chose de relativement stable. Personnellement je n’ai pas beaucoup travaillé sur Enna car je continue à me concentrer sur libvalhalla. Il y a encore deux régressions de Enna qui sont dues à l’utilisation de libvalhalla.

Je parle de régressions, bien qu’il n’y a jamais eu de sortie officielle et stable. Il faut comprendre par là qu’avec toutes les modifications qui ont été apportées à Enna, de temps en temps des fonctionnalités disparaissent simplement parce qu’elle devraient être gérées d’une autre manière.

La première régression que je veux souligner est celle de pouvoir reprendre la lecture d’un film à l’endroit où il a été interrompu. Dit comme ça, il n’y a rien d’exceptionnel. Mais “à l’époque”, l’enregistrement se faisait à l’aide de Eet qui était également utilisé pour stocker les méta-données des fichiers audio/vidéos. Depuis l’arrivée de libvalhalla et donc d’une base de donnée SQLite, Eet n’avait plus beaucoup de sens et cette partie a été simplement supprimée d’Enna. Mais la lib ne permet pas l’écriture depuis son API publique pour plusieurs raisons. Tout d’abord Valhalla ce n’est pas une bibliothèque pour gérer une base de donnée, mais c’est avant tout un scanner de fichiers, des “parsers” et des “grabbers”. Les données sont récupérées par elle automatiquement. Il est donc possible de les lire depuis l’API publique. Lorsque des données doivent être modifiées, elles le sont depuis les fichiers (tags ID3 par exemple), ou alors depuis les site internets qui fournissent des informations (les grabbers, ImDB, Amazon, etc, …).

Mais pour répondre à certains besoins comme la sauvegarde de la position d’un film, il est nécessaire de reconsidérer cette question sur libvalhalla. J’ai donc commencé à travailler sur cet aspect il y a peu de temps. Il y aura ainsi une information qui permettra d’identifier des données venant de l’extérieur (parser, grabbers, …) et des données venant de l’intérieur. Pour mieux comprendre pourquoi il est nécessaire de faire des séparations, l’exemple d’un champ “playcount” est bien adapté. Le “playcount” (donc le nombre de fois qu’un fichier est lu), dépend uniquement de l’utilisateur d’Enna. Si le fichier en question est modifié (les tags par exemple), ce champ doit rester intacte ce qui n’est pas possible actuellement.

La deuxième régression concerne les “snapshots” (ou “fanarts”). Ils servent à avoir une image illustrant une video. Par exemple les images suivantes présentent les résultats pour quatre “trailers” où des données intéressantes ont pu être récupérées par les “grabbers” (j’ai récupéré les “trailers” sur le site d’Apple, merci au blogger en lien <ici> et <ici> pour l’astuce).

Dans tous ces exemples les images de fond ont pu être téléchargées sur le site TheMovieDB.org. Mais il peut arriver qu’aucune image ne soient disponibles et donc une alternative est nécessaire. Actuellement il y a une image de fond par défaut pour ces cas de figure, mais le but est de créer un “snapshot” directement avec le contenu de la vidéo. Cette fonctionnalité était disponible à l’époque où libvalhalla n’existait pas, et libplayer faisait office d’intermédiaire pour récupérer l’image à 20% de la vidéo. L’idée désormais est donc d’utiliser le “grabber” FFmpeg (ajouté il y a peu de temps) pour extraire l’image. Bien sûr, il ne faut pas l’extraire dans les cas où TheMovieDB contient déjà un “snapshot” de bien meilleur qualité.

Il y bien entendu toujours un panneau d’informations pour les vidéos. Il va encore probablement subir des modifications, et donc rien de ce qui est montré dans ces “screenshots” ne peut être considéré comme définitif.

…

Il y a encore d’autres choses qui ont évoluées aussi bien au niveau de l’audio que de la vidéo, mais mon objectif  pour ce billet est uniquement de parler des deux régressions. Du côté de libvalhalla, les “grabbers” tels que Amazon, Allocine et LyricWiki re-fonctionnent normalement (espérons que se sois pour encore longtemps). A part ça, une grande partie des modifications sont internes tel que de l’optimisation et des corrections de bugs par exemple.

A bientôt,

Mathieu SCHROETER

]]> http://skywalker13.wordpress.com/2009/11/05/un-logo-pour-illustrer-libvalhalla/ Thu, 05 Nov 2009 22:12:27 +0000 Mathieu SCHROETER http://skywalker13.wordpress.com/2009/11/05/un-logo-pour-illustrer-libvalhalla/

Il manquait une illustration pour libvalhalla. C’est toujours plus sympathique de pouvoir faire référence à une bibliothèque par l’intermédiaire d’images. Ce n’est pas non plus pour rien que je lui ai donné ce nom. Contrairement à celle que j’avais fais pour libplayer, cette fois j’ai choisi un style un peu plus classique et complètement monochrome.

Les personnages représentent des Valkyries à la recherche de vos fichiers multimédias perdus dans les champs de batailles de vos disques durs.

C’est sûrement le billet le plus court que je n’ai jamais publié .

A bientôt,

Mathieu SCHROETER

Hello,

avec les projets GeeXboX parfois j’ai l’impression de ne jamais arriver au bout. Quand quelque chose se termine, il y a toujours autre chose à faire. On ne risque pas de s’ennuyer. Mais il arrive qu’on fasse les choses à double, triple ou pire. Tout ça pour dire que les fonctionnalités présentées dans le billet précédent (“force-stop”, “on demand” et “events”) sont implémentées.

Je vous invite à lire l’article à ce lien si vous ne comprenez pas de quoi je parle; reste aussi à être intéressé par ce genre d’article .

En quelques phrases

force-stop

Je ne vais pas revenir sur les détails. La réalisation du “force-stop” a introduit de nouvelles tables dans la base de donnée. Une table pour sauvegarder les “grabbers” et une table pour sauvegarder les contextes du “downloader”. En résumé, lorsqu’un fichier a été traité par un “grabber” et que les données ont été sauvegardées, la relation avec ce “grabber” est également introduite dans la base de donnée. Ça évite ainsi au prochain démarrage de “regrabber” les même données. Pour le “downloader” l’idée est un tout petit peu différente. Lorsque Valhalla se termine, il sauvegarde toutes les listes de fichiers à télécharger dans la base de donnée. Au prochain démarrage, quand le scanner tombe sur un fichier où il y avait encore des données à télécharger, il réintroduit les listes dans les structures.

ondemand

Pour le “ondemand” le travail s’est montré un peu plus compliqué que je le pensais. Étant donné que le “ondemand” peut se passer à n’importe quel moment il y a de nombreux cas à considérer. Par exemple, vous faites une requête “ondemand”, le fichier de la requête n’a pas été vu par le scanner. Le “ondemand” se met en branle et ce fichier se retrouve dans le mécanisme, puis le scanner voit le fichier et l’introduit presque en même temps dans le mécanisme. Du coup vous vous trouvez avec deux paquets différents pour un même fichier. Il y a ainsi deux-trois astuces pour gérer ce cas de figure ainsi que beaucoup d’autres (je vous épargne le plus tordu sur lequel je suis tombé). Aucune nouvelle table a été introduite pour cette fonctionnalité, uniquement un nouveau champ dans la table des fichiers, pour savoir si le fichier existe dans les chemins du scanner, ou pas.
Grosso modo le “ondemand” se passe ainsi: pause de tous les threads en aval au scanner (donc depuis le DBManager); il attend que tout le monde s’en dort; il cherche dans les queues si le fichier à traiter existe déjà; en fonction de ça il créer un nouveau ou il modifie l’existant; puis il réveille tout le monde. Les paquets “ondemand” ont également une haute priorité et sont donc traités le plus rapidement possible par les différents threads de Valhalla.

events

Concernant les événements, il y a simplement des retours au “front-end” pour lui signaler quelle étapes ont été réalisées, via un callback. Les événements sont possibles uniquement avec les requêtes “ondemand”.

L’architecture

Deux threads ont donc fait leur apparition (en rose pâle). L’architecture n’a donc pas été modifiée, mais étendue. Au lieu de n’avoir que le scanner comme intervenant pour l’ajout de fichiers, il y a donc le “ondemand” en parallèle. Les événements sont traités exclusivement par le DBManager.

Comme toujours, ces diagrammes sont un peu simplifiés. Par exemple, les commandes “ondemand” ne sont pas bloquantes. Et donc en réalité il y a une queue devant la flèche entrante du “front-end”. Mais ça n’apportait rien d’intéressant à la lecture de ce diagramme. Il suffit de lire la documentation Doxygen pour connaître ce genre de précision quant a l’utilisation des fonctions publiques.

La base de donnée

Les modifications sur la base de donnée concernent les tables grabber, dlcontext, file ainsi que la table d’allocation pour les relations (n,n) avec les “grabbers”. Les champs interrupted__ et outofpath__ ont intégrés la table file. Notez bien que les champs terminés par __ sont utilisés uniquement comme données internes pour le bon fonctionnement de Valhalla.

Mais encore …

Comme je le disais au début, on aime faire du travail à double et même à triple. Écrire des “grabbers” dans Enna pour ensuite les porter dans Valhalla. Et le meilleur c’est quand le fournisseur d’un service utilisé par un “grabber” aime se foutre du monde. Amazon par exemple, un jour il décide de dire que toutes les requêtes pour le service doivent être signées HMAC-SHA256 (c’est limite ridicule mais ça n’engage que moi). Ou alors la MPAA/RIAA qui aime emmerder les petits (et dire qu’ils sont payés pour ça) et qui empêche ainsi Lyricwiki de fournir une WebAPI pour les paroles des chansons. Du coup deux “grabbers” cassés, le “grabber” Lyricwiki qui a été fixé d’une autre manière mais qui s’est vu à nouveau être inutilisable (je crois, je ne m’en suis pas occupé).

En ce qui concerne Amazon c’est pas une grosse affaire mais j’ai la flemme. C’est fatiguant de devoir toujours revenir sur ce qui a déjà été fait, encore et encore. Imaginez le jour où il y a une release. Vous aurez deux-trois “grabbers” de morts en à peine quelques semaines.

Finalement avant de fixer des “grabbers” mieux vaut attendre le dernier moment.

Mais encore …, …

Il manque (et oui) des moyens depuis l’API publique pour modifier des méta-données; un exemple: le “play-count”. Vous pouvez imaginez d’autres types de champs dans cette idée. mais qui dit modifier les données dit aussi de considérer deux cas de figure:

1. Modifier uniquement dans la base de donnée
2. Modifier également dans le fichier en question (avec FFmpeg)

Selon les méta-données et le type de fichier, seul le cas (1.) est envisageable. Mais pour par exemple un OGG et l’artiste, il peut être bien de pouvoir directement l’écrire dans le fichier. Tout ceci reste encore sujet à réflexion.

A bientôt,

Mathieu SCHROETER

Hello,

comme je l’ai plus d’une fois expliqué, la vidéo sous Enna passe par libplayer. Et depuis quelque temps, Ben et Nico m’ont à nouveau sensibilisé sur un problème d’aspect avec les vidéos.
Le plus simple des aspects correspond à une stupide fraction:

Mais celle-ci n’est pas toujours vraie, ainsi l’aspect peut être directement enregistré en tant que propriété dans le fichier vidéo. Un exemple courant étant les films DVD. La définition de l’image est de 720×576 (PAL) néanmoins l’aspect peut être du 4:3, 16:9 ou du cinémascope 2.39:1. Pourtant l’image est toujours enregistrée afin d’utiliser un maximum de surface et donc les pixels ne sont pas carrés. Considérer le pixel carré est le dernier recours au cas où la vidéo ne donnerait aucune information sur son aspect.

Le bug…

Le problème rencontré part Ben et Nico n’était pas reproductible chez moi. Et étant principalement responsable de libplayer depuis toutes les modifications que j’ai apporté, et donc connaissant de fond en comble sa structure et son fonctionnement actuel, il est forcément de mon devoir que de corriger les problèmes connus.
Quand ils utilisaient libplayer avec Enna, ils avaient certaines vidéos qui s’affichaient avec un aspect de 1.00. Ce qui engendre donc une image parfaitement carrée. S’ils testaient cette même vidéo avec le logiciel test-player qui utilise libplayer, l’aspect était correcte. Là où ça devenait encore plus étrange, c’est quand j’ai testé la même vidéo que Nico et j’avais un aspect correct aussi bien sous Enna que sous test-player. Je ne savais donc pas comment reproduire le bug, même que j’avais de plus en plus de doute sur l’existence de ce bug. Non pas que je n’ai pas confiance en leurs manipulations (surtout qu’ils sont deux à être victime de ce problème) mais plutôt que je fais toujours une grande quantité de testes lorsque j’ajoute ou modifie des fonctionnalités dans la bibliothèque. Les problèmes d’aspect je les ai particulièrement travaillé quand j’ai rajouté le support de la navigation DVD pour les wrappers MPlayer et xine. Car il y a des conversions de coordonnées à effectuer pour que la souris agissent au bon endroit sur la surface de l’image et cela en tenant compte de l’aspect et des offsets en x et y.

Nico m’a alors transmis les logs Enna lorsque le problème survient et j’ai pu identifier le problème indirectement. libplayer écrit dans ses logs certaines informations sur les modifications qu’il effectue sur la fenêtre vidéo. Il apparait que la ligne qui indique l’aspect de l’image utilisait une virgule pour séparer les décimales. Sur mon ordinateur cette même ligne ne s’écrit pas avec une virgule, mais avec un point.

Un problème de LOCALE

libplayer utilise abondamment la fonction atof() pour la conversion des valeurs réelles transmissent par MPlayer. Une de ces valeurs est l’aspect. MPlayer retourne la valeur dans un champ ID_VIDEO_ASPECT=1.85 par exemple. Et ce champ a toujours un point comme délimiteur dans le cas d’un MPlayer utilisé avec libplayer (MPlayer doit toujours être en anglais). Là où ça devient un problème c’est le comportement de la fonction atof(). En fonction de la LOCALE du système, elle considère que le délimiteur est une virgule et non un point. De ce fait, (et surtout parce que la fonction atof() ne peut pas échouer) l’aspect lu n’était pas 1.85, mais 1. atof() ignorait tous les caractères depuis le point.

Bien qu’étant de langue francophone, en Suisse-Romande nous n’avons pas du tout la même LOCALE que la France. Notre clavier est également différent (disposition QWERTZ). Nous utilisons le point comme séparateur de décimale et non la virgule et la LOCALE est “fr_CH”. En France, la LOCALE est “fr_FR” et le séparateur de décimale est une virgule. Ceci explique pourquoi je ne pouvais pas reproduire l’erreur. Qui pense aux LOCALEs quand il y a un bug sur l’aspect des vidéos? Et bien je tâcherais d’y penser à partir de maintenant.
Quoi qu’il en soit, de nombreux français devaient avoir des problème, mais je n’ai pas eu d’autres retours que les autres développeurs. Je suppose que les éventuels utilisateurs d’Enna se sont dit qu’étant donné qu’aucune version stable existe, ça finirait par être fixé pour la finale? Sachez qu’il y a un site où vous pouvez rapporter les problèmes: enna.geexbox.org, vérifiez si le bug est déjà listé et dans le cas contraire n’hésitez pas à vous inscrire et à soumettre un rapport de bug.

Correction

Pour y remédier il suffit donc de changer de LOCALE avec libplayer. Mais il n’y a pas de raison apparente de changer la LOCALE pour toute la bibliothèque. Ainsi il suffit de réécrire une fonction atof() qui s’exécute dans une autre LOCALE. En principe un programme utilise la LOCALE “C”. Qui est celle par défaut. Enna étant internationalisé, la LOCALE change selon la langue. Ceci explique donc pourquoi le bug apparaissait sous Enna mais pas sous test-player.

En principe, la LOCALE se change avec la fonction setlocale(). Mais avant de dire youpie il faut garder à l’esprit que libplayer utilise abondamment les threads. Lorsque la fonction atof() est appelée, Enna peut être en train de faire autre chose. Et cet autre chose peut très bien être influencé par la LOCALE en cours. Le fait d’utiliser la fonction setlocale() modifie la LOCALE pour tout le processus.
Il est donc nécessaire d’avoir recours à une fonction qui ne modifie la LOCALE que sur le thread où atof() est exécuté. Cette fonction s’appelle uselocale(), le nouveau atof() se présente donc ainsi (patch libplayer):

#define _GNU_SOURCE
#include <locale.h>
#include <stdlib.h>

double
my_atof (const char *nptr)
{
  double res;
  locale_t new_locale, prev_locale;

  new_locale = newlocale (LC_NUMERIC_MASK, "C", NULL);
  prev_locale = uselocale (new_locale);
  res = atof (nptr);
  uselocale (prev_locale);
  freelocale (new_locale);

  return res;
}

Afin de simplifier la fonction et d’éviter atof() qui a une réputation d’obsolescence je l’ai remplacé par strtod_l(). Du même coup il est possible d’éliminer uselocale() et donc de ne plus changer la LOCALE du thread.

#define _GNU_SOURCE
#include <locale.h>
#include <stdlib.h>

double
my_atof (const char *nptr)
{
  double res;
  locale_t new_locale;

  new_locale = newlocale (LC_NUMERIC_MASK, "C", NULL);
  res = strtod_l (nptr, NULL, new_locale);
  freelocale (new_locale);

  return res;
}

On notera que strtod() peut retourner HUGE_VAL contrairement à atof().

A bientôt,

Mathieu SCHROETER

Geexbox merupakan sebuah perangkat multimedia dan ga cuma itu geexbox ini juga adalah sebuah distro dengan sistem operasi linux lengkap dengan berbagai utilitas termasuk utilitas jaringannya.

Untuk menjalankan geexbox, kita ga perlu harddisk, cukup CDROM atau USB stick. Nah, karena geexbox ini dilisensikan open source so setiap orang bebas untk mengubah dan membangun versinya sendiri.

Konfigurasi minimal yang dibutuhkan untuk menjalankan geexbox:

• CPU minimal Pentium
• Graphic Card yang kompatibel dengan standar VESA 2.0. Sebagian besar graphic card keknya dah memenuhi standar ini
• Kartu suara (sound card) yang kompatible sama ALSA
• RAM paling dikit 64 MB
• CD-ROM atw DVDROM
• Motherboard yang bisa memboot dari CDROM ^_^
• Lengkapnya bisa diliat aja sendiri di http://www.lirc.org

Klw pingin… sekali lagi klo pingin mengubah, mengkompilasi atau melakukan kustomisasi untuk membuat geexbox itu sendiri, maka beberapa perangkat lunak berikut dibutuhkan:

• gcc : the GNU compiler collection, digunakan untuk mengembangkan projek secara keseluruhan. avoid to use GCC 2.96 karena ga kompatibel untuk mengkompilasi mplayer
• make: GNU make, program untuk menentukan bagian mana dari program besar yang harus di kompilasi dan perintah apa yang diberikan utnuk melakukan kompilasi ulang bila perlu.
• patch: digunakan untuk menambah (patch) beberapa paket untuk menyesuaikan agar sesuai denagn lingkungan geexbox dan menambah beberapa fitur.
• wget: buat ngedonlot berkas dari web
• nasm: program assembler gitu, digunakan untuk melakukan kompilasi uClibc di geexbox
• dosfstools: untuk membuat dan menguji file dalam format FAT MS-DOS
• mkisofs: membuat image file untuk CDROM sesuai dengan format CDROM ISO-9660
• mkzftree: membuat iso image yang terkompress
• cdrecord: merekam atau membakar CD

GeexBox bisa di download di sini

Klo geexboxnya dah di bakar maka untuk menjalankan geexbox tidaklah sulit, langkah pertama, aturlah BIOS sehingga memboot dari CDROM. Habis tu masukin deh CDnya.

klo udah, maka boot prompt si geexbox akan muncul. Akan muncul 3 pilihan: Install, Debug, dan defaultnya Menjalankan.

Setelah itu, akan muncul layar yang menunjukan proses boot dari Geexbox, tunggu aja sampe batang penunjuk kemajuan proses penuh atau berada di kanan.

Geexbox sangat mudah untuk dioperasikan melalui menu yang dapat dipilih dengan menggunakan tombol naik dan turun untuk memilih menu, sedangkan untuk memilih submenu bisa pake tombol panah kanan dan tombol panah kiri untuk kembali ke menu sebelumnya.

• Open
  • open file -> menjalankan berkas multimedia (audio atau video)
  • open playlist -> menjalankan daftar lagu (playlist) yang kompatibel denagn MPlayer
  • play DVD -> menjalankan bagian pertama DVD dan judul
  • Play VCD -> memainkan super VCD atau VCD track eprtama
  • play Audio CD -> memainkan Cd audio
• Controls
  • Pause -> menghentikan sementara atau melanjutkan kembali (resume)
  • Stop -> menghentikan
  • Eject -> Mengeluarkan cd dari drive
  • Chapter selection -> memilih bagian DVD
  • Prev/Next -> melompat ke bagian berikutnya (next) atau sebelumnya (prev)
  • Jump to -> melompat ke trak vcd lain, atau kebagian dvd lain
• Options
  • Aspect -> menentukan ratio gambar, dengan pilihan
    • Original -> mereset ratio gambar ke nilai asli
    • 4:3 -> mengganti ratio tinggi/lebar gambar ke 4:3
    • 16:9 -> mengganti ratio tinggi/lebar gambar ke 16:9 -> untuk widescreen pake yang ini jd ga ada garis item di pinggir kiri dan kanan
    • Cinemascope -> mengganti ratio gambar ke 2:35
  • Audio Channel -> mengganti audio channel (bahasa indonesianya apa sih???)
  • Subtitle selection -> mengganti pilihan teks terjemahan
  • Switch TV-out -> mengganti tampilan dari monitor ke TV-out
  • switch vertical sync -> on/off sinkronisasi vertikal
  • Help -> menampilkan keterangan bantu via On Screen Display
  • Quit -> menghentikan geexbox DAN mematikan kompie

Geexbox merupakan distro yang tergolong liveCD, which means suatu sistem linux yang dapat dijalankan langsung dari CDROM tanpa perlu diinstal ke harddisk terlebih dahulu. However, geexbox bisa juga diinstall di media lain, sehingga dengan mudah dapat diinstall di harddisk. Geexbox juga bisa diinstall di harddisk dengan partisi tersendiri, juga dapat diinstall di partisi kosong yang butuhkan hanyalah partisi dengna ukuran 8MB tapi klw mw nambah codec lainnya mendingan 16MB deh… ^_^

Jika geexbox nya sering dipake, maka akan sangat memudahkan bila diinstal di harddisk. cara nginstallnya ada 2:

• dari sistem GNU/linux yang ada di kompie
• ketika memboot geexbox melalui CDROM

langkah ke2 lebih mudah buat yang kurang menguasai command2 yang ada di linux. Caranya adalaaaaaaaaaaahh:

pada waktu prompt isolinux awal sebelum booting ketik install

boot: install

geexbox akan mulai dijalankan. Pertama kali akan mendeteksi hardware secara otomatis, kemudian menentukan harddisk mana yang mau di instalin geexbox. Program Geexbox akan mendeteksi secara otomatis harddisk yang ada dan menampilkannya, ikutin aja instruksinya trs pilih harddisk mana yang mw diinstall..

setelah menentukan harddisk yang mana, maka program penginstal geexbox akan melakukan pekerjaan pembuatan partisi. Gunakan tanda panah untuk memilih partisi yang masih kosong, dan tekan tombol NEW, tentukan ukuran yang diperluin, yaaa 10 MB lah dah cukup bwt nginstall geexbox.

lalu… pilih jenis partisi yang ingin digunakan. File sistem yang didukung adalah FAT 16/32 dan EXT 2/3. Pilih type 0B utnuk FAT 32 (disarankan bila ingin melihat adan mengedit dari MS Windows) atau type 83 untuk EXT (Linux). Selesaikan dengan menekan finish, lalu write dan finish.

Setelah itu, tentuin deh apakah partisi tersebut bootable apa engga, caranya dengan memilih flag bootable.

Habis itu, pilih jenis partisi yang dibuat, dengan memilih anga dari daftar partisi tersebut. Untuk partisi FAT16 gunakan 06

kemudian tentukan apakah partisi yang dibuat merupakan partisi primari atau logikal. Pada linux biasanya partisi primari akan ditandai dengan hdx1, hdx2, hdx3, dan hdx4 (x adalah tanda partisi misal hda, hdb). Sedangkan partisi logical adalah hdx5 dan seterusnya

klo dah selesai, cfdisk akan bertanya untuk memastikan pilihan yang udah dilakukan, cek lagi apa udah sesuai dengan yang kita inginkan… karena setelah partisi tertulis akan sulit untuk melakukan perbaikan dari pilihan yang telah dilakukan, apalagi klo di dalam harddisk tersebut ada partisi lain yang ada datanya…

setelah proses penulisan selesai, maka geexbox akan nanyain di partisi manakah yang akan diinstal, tekan saja OK jika ingin melanjutkan proses instalasi.

Pada proses instalasi, pertama kali partisi yang dipilih akan diformat dan file system dibuat di partisi tersebut. Setelah itu, berkas2 geexbox akan disalin ke dalam partisi tersebut, dan tahapan selanjutnya adalah geexbox akan menginstal bootloader di MBR.

bootloader itu adalah program yang memungkinkan untuk memboot suatu partisi, dikenal bootloader GRUB atau SysLinux. Geexbox sendiri menggunakan GRUB sebagai bootloader. Tapi klo ingin memboot dari USB maka pilih lah SysLinux.

Klo di harddisk udah ada bootloader, maka ga perlu nginstal bootloader baru. Caranya:

dari GeeXboX CD, simply copy the GEEXBOX folder into your Linux / partition (we suppose it to be /dev/sda1 here). Modify the /boot/grub/menu.lst file to add:

title GeeXboX
root (hd0,1)
kernel /GEEXBOX/boot/vmlinuz root=/dev/ram0 rw rdinit=linuxrc boot=UUID=$my_uuid lang=en keymap=qwerty splash …
initrd /GEEXBOX/boot/initrd.gz
quiet

Just take are about two things:
- the field root (hd0,1) is to be adapted according to the rest of your GRUB’s configuration.
- the $my_uuid value is the unique ID of your partition. Check within your GRUB config file, which value is set for other OS on the same partition or use ls -l /dev/disk/by-uuid/ to see which uuid matches your partition.

tapi klo di kompie belum ada OS yang memiliki kemampuan multiboot maka disarankan untuk menginstal bootloader di harddisk. Program installer Geexbox akan menscan harddisk untuk membaca sistem operasi yang telahada dan membuat sustem multiboot yang akan memungkinkan kita untuk memilih memboot sistem operasi yang lama, ata u memboot geexbox.

Instalasi selesai, kita bisa memboot Geexbox dari harddisk seperti halnya sistem linux pada umumnya. Ketika sistem diboot maka GRUB akan menampilkan pilihan boot. Minimal adalah Geexbox dan Geexbox (Debug). Yang pertama adalah sistem geexbox dan yang kedua adalah untuk keperluan debug bila sistem tidak berfungsi atau tidak bisa memboot.

Hello,

depuis peu, les modifications évoquées dans le billet précédent ont été réalisées. L’API a été modifiée pour toutes les fonctions qui permettent d’effectuer des sélections sur la base de donnée. Ce blog étant aussi en quelque sorte un carnet de laboratoire, je vais donc y expliquer le fonctionnement de ces fonctions ainsi que la manière de les utiliser. A terme, ces informations figureront directement dans la documentation (en anglais) de libvalhalla. Il est judicieux de consulter la documentation Doxygen déjà présente dans l’en-tête public (valhalla.h) qui peut être généré via un paramètre du script “configure”.

Cet article est long et très spécifique à libvalhalla du côté développeur uniquement. Si vous êtes un simple utilisateur d’Enna, vous ne verrez pas vraiment de différence par rapport à avant car les modifications sont majoritairement internes.

Il y a trois fonctions publiques et chacune est complémentaire aux autres.

int valhalla_db_metalist_get (
  valhalla_t *handle,
  valhalla_db_item_t *search,
  valhalla_db_restrict_t *restriction,
  int (*result_cb) (void *data,
                    valhalla_db_metares_t *res),
  void *data);

int valhalla_db_filelist_get (
  valhalla_t *handle,
  valhalla_file_type_t filetype,
  valhalla_db_restrict_t *restriction,
  int (*result_cb) (void *data,
                    valhalla_db_fileres_t *res),
  void *data);

int valhalla_db_file_get (
  valhalla_t *handle,
  int64_t id, const char *path,
  valhalla_db_restrict_t *restriction,
  valhalla_db_filemeta_t **res);

valhalla_db_metalist_get

Utilisation simple

Elle permet de récupérer une liste de metadata. Cela veut dire, par exemple une liste d’albums, d’auteurs, d’artistes, de genres; peu importe le nom, vous pouvez récupérer n’importe quelle liste. Le résultat se présente toujours sous la forme du nom du champ (comme “author”) avec une valeur et un groupe. Sous la forme d’un tableau, cela donnerait quelque chose comme:

Dans cet exemple, uniquement les auteurs sont présents, mais il est également possible de demander une liste de metadata selon un groupe et non selon un nom de meta ou un id. Vous pouvez typiquement demander la liste de toutes les metadata qui appartiennent au group ENTITIES. De ce fait, vous trouverez la liste de tous les auteurs, artistes, compositeurs, studios, etc,…

Sans rentrer encore dans les détails du code, une telle liste se récupère de cette manière:

valhalla_db_item_t s = VALHALLA_DB_SEARCH_TEXT ("author", ENTITIES);
valhalla_db_metalist_get (handle, &s, NULL, callback, NULL);

Et sans expliquer en détail la fonction, l’argument “handle” correspond au pointeur sur votre instance de valhalla, “s”  (pour search) défini ce que vous cherchez, le troisième argument permet de spécifier des restrictions (qui sont expliquées dans le chapitre suivant), le callback est la fonction dans laquelle chaque ligne du résultat est envoyée et le dernier argument est un pointeur void qui peut être récupéré dans le callback.

Les macros  VALHALLA_DB_SEARCH_XXX sont présentes pour simplifier l’utilisation de libvalhalla. Elles ne sont pas indispensables. En réalité, elle ne font qu’attribuer les valeurs au bon endroit dans la structure valhalla_db_item_t. Actuellement il existe trois macros différentes:

VALHALLA_DB_SEARCH_ID(meta_id, group)
VALHALLA_DB_SEARCH_TEXT(meta_text, group)
VALHALLA_DB_SEARCH_GRP(group)

Vous pouvez donc chercher une liste de meta en fonction de l’id, du texte, ou alors vous pouvez récupérer plusieurs noms de metadata différents dans le cas d’une recherche selon un groupe.

Utilisation étendue

Récupérer une liste comme expliqué dans le chapitre précédent est la fonctionnalité la plus simple offerte par cette fonction. Il va de soit qu’il faut pouvoir donner quelques restrictions sur la liste retournée. Il est courant de ne pas vouloir une liste complète. Un exemple parlant concerne la metadata “album”. Il est intéressant de pouvoir récupérer tous les albums d’un auteur en particulier. Et c’est ici qu’interviennent les restrictions. Elles permettent d’inclure ou d’exclure certains résultats. D’un point de vue SQL, se sont des sous-requêtes qui limitent les résultats à leur ensemble, ou alors à tous les résultats différents de leur ensemble.

Voici un premier exemple. Vous voulez tous les albums de Dido:

valhalla_db_item_t s = VALHALLA_DB_SEARCH_TEXT ("album", TITLES);
valhalla_db_restrict_t r1 = VALHALLA_DB_RESTRICT_STR (IN, "author", "Dido");
valhalla_db_metalist_get (handle, &s, &r1, callback, NULL);

Le résultat sera un tableau de la même forme que vue précédemment, mais qui contiendra uniquement les albums de Dido.

Cette requête est déjà bien plus sophistiquée, car vous pouvez imaginer de donner ce genre de restriction pour n’importe quel metadata. Un autre exemple, vous pourriez lister tous les albums d’une certaine année. Il n’y a aucune limite sur les choix des restrictions. Mais ceci n’est pas suffisant, et il y a donc des possibilités un peu plus complexes afin d’avoir des résultats plus spécifiques.

Tout d’abord, dans l’exemple précédent, la macro VALHALLA_DB_RESTRICT est utilisée avec un premier argument “IN”. Il est possible d’inverser la logique en y inscrivant “NOTIN” à la place. Le résultat deviendrait alors la liste de tous les albums qui existent dans la base de donnée, sauf ceux de Dido.

Utilisation avancée

L’utilisation étendue permet déjà d’effectuer de nombreuse recherches intéressantes. Néanmoins pour les cas les plus précis, elle ne suffit pas. Il est nécessaire parfois de cumuler les restrictions pour affiner le résultats, ou tout simplement, pour avoir des résultats un peu plus exotiques. Ainsi les restrictions sont des listes chaînées, et il est possible de les lier très facilement. Commençons par un exemple, nous désirons la liste de tous les albums de Dido qui ne sont pas de 2003.

valhalla_db_item_t s = VALHALLA_DB_SEARCH_TEXT ("album", TITLES);
valhalla_db_restrict_t r1 = VALHALLA_DB_RESTRICT_STR (IN, "author", "Dido");
valhalla_db_restrict_t r2 = VALHALLA_DB_RESTRICT_STR (NOTIN, "year", "2003");
VALHALLA_DB_RESTRICT_LINK (r2, r1);
valhalla_db_metalist_get (handle, &s, &r1, callback, NULL);

Une nouvelle macro est donc introduite. Elle permet de lier très simplement les restrictions ensemble. La macro doit être comprise de cette manière. “link from r2 to r1″, soit lier de r2 à r1. Ainsi c’est r1 qui doit être spécifié dans la fonction valhalla_db_metalist_get(). Il n’y a aucune limite sur le nombre de liens possibles (mise à part qu’une requête ne doit pas dépasser 4096 caractères), néanmoins il ne faut pas tenter de lier toutes les restrictions sur la même car seul le dernier lien sera considéré. Avec trois restrictions, la bonne manière de procéder est donc:

valhalla_db_item_t s = VALHALLA_DB_SEARCH_TEXT ("album", TITLES);
valhalla_db_restrict_t r1 = VALHALLA_DB_RESTRICT_STR (IN, "author", "Linkin Park");
valhalla_db_restrict_t r2 = VALHALLA_DB_RESTRICT_STR (NOTIN, "year", "2003");
valhalla_db_restrict_t r3 = VALHALLA_DB_RESTRICT_STR (NOTIN, "genre", "Alternative");
VALHALLA_DB_RESTRICT_LINK (r3, r2);
VALHALLA_DB_RESTRICT_LINK (r2, r1);
valhalla_db_metalist_get (handle, &s, &r1, callback, NULL);

Ici, la liste concernera donc tous les albums de Linkin Park, qui ne sont pas de 2003 et qui ne sont pas du rock/metal alternatif. Okay, la liste ne risque pas d’être bien longue avec cet exemple , mais ce qui compte c’est de montrer le principe. Les restrictions sont liées de la manière suivante: de r3 à r2 et de r2 à r1. En code ça donnerait donc:

r2.next = &r3;
r1.next = &r2;

Le code ci-dessus peut très bien remplacer la macro si vous préférez.

Il y a encore une macro que je n’ai pas vraiment présenté. Pour l’argument de recherche de la fonction, il est possible d’indiquer uniquement un groupe (comme je l’ai mentionné plus haut dans ce billet). Si le groupe est mit à NIL, il y aura toutes les metadata qui seront listées, autrement il n’y aura que les metadata liées au groupe.

Un dernier exemple qui retourne absolument toutes les metadata liées à Dido pour son album Life For Rent.

valhalla_db_item_t s = VALHALLA_DB_SEARCH_GRP (NIL);
valhalla_db_restrict_t r1 = VALHALLA_DB_RESTRICT_STR (IN, "author", "Dido");
valhalla_db_restrict_t r2 = VALHALLA_DB_RESTRICT_STR (IN, "album", "Life For Rent");
VALHALLA_DB_RESTRICT_LINK (r2, r1);
valhalla_db_metalist_get (handle, &s, &r1, callback, NULL);

Et d’un point de vue SQL

La requête SQL qui effectue les sélections est créée en fonction des arguments de la fonction. Elle se construit comme des lego qui s’imbriquent les uns dans les autres. D’une manière général, sa forme est:

SELECT meta.meta_id, data.data_id, meta.meta_name, data.data_value
FROM (
 data INNER JOIN assoc_file_metadata AS assoc
 ON data.data_id = assoc.data_id
) INNER JOIN meta
ON assoc.meta_id = meta.meta_id
-- Les conditions sont optionnelles
WHERE
  -- Une sous-requête apparait par le biais des restrictions.
  -- Il y a autant de sous-requêtes que de restrictions du type IN, NOT IN.
  assoc.file_id <IN|NOT IN> (
    SELECT assoc.file_id
    FROM (
      data INNER JOIN assoc_file_metadata AS assoc
      ON data.data_id = assoc.data_id
    ) INNER JOIN meta
    ON assoc.meta_id = meta.meta_id
    -- A choix, il peut y avoir un ID ou du texte.
    WHERE meta.<meta_id|meta_name> = <ID|"TEXT"> AND data.<data_id|data_value> = <ID|"TEXT">
  )
  -- L'argument search indique quel meta et/ou quel groupe doit être listé
  AND meta.<meta_id|meta_name> = <ID|"TEXT">
  AND assoc._grp_id = <ID>
GROUP BY assoc.meta_id, assoc.data_id
ORDER BY data.data_value;

Sa longueur varie fortement selon le nombre de conditions. Il est possible de visualiser les requêtes générées par Valhalla en utilisant la verbosité maximale de la bibliothèque.

valhalla_db_filelist_get

Utilisation simple

La récupération d’une liste de fichiers ressemble à celle pour les metadata. La différence vient principalement du deuxième argument qui fait référence au type de fichier (audio, video, etc, …). Ce qui limite ensuite la liste se sont les restrictions. L’utilisation étant exactement la même, je vais aller droit au but avec des exemples.

Pour lister la totalité des fichiers référencés dans la base de donnée, rien de plus simple:

valhalla_db_filelist_get (handle, VALHALLA_FILE_TYPE_NULL, NULL, callback, NULL);

Le fait d’indiquer un type de fichier NULL, permet d’ignorer le type. Le résultat de cette requête correspond à un tableau de ce genre qui contiendrait la totalité de l’arborescence:

Avec les restrictions

Il est ensuite facile de faire du tri avec les restrictions, de la même manière que pour la fonction précédente. Par exemple, pour lister tous les fichiers d’Ennio Morricone qui ne sont référencés dans aucun album.

valhalla_db_restrict_t r1 = VALHALLA_DB_RESTRICT_STR (IN, "author", "Ennio Morricone");
valhalla_db_restrict_t r2 = VALHALLA_DB_RESTRICT_STR (NOTIN, "album", NULL);
VALHALLA_DB_RESTRICT_LINK (r2, r1);
valhalla_db_filelist_get (handle, VALHALLA_FILE_TYPE_NULL, &r1, callback, NULL);

Et ci-dessous, un autre exemple qui correspond à la catégorie “Non Classé” dans Enna. Tous les fichiers qui ne sont ni dans un album, ni lié à un author et dont le genre est indéfini.

valhalla_db_restrict_t r1 = VALHALLA_DB_RESTRICT_STR (NOTIN, "album", NULL);
valhalla_db_restrict_t r2 = VALHALLA_DB_RESTRICT_STR (NOTIN, "author", NULL);
valhalla_db_restrict_t r3 = VALHALLA_DB_RESTRICT_STR (NOTIN, "genre", NULL);
VALHALLA_DB_RESTRICT_LINK (r3, r2);
VALHALLA_DB_RESTRICT_LINK (r2, r1);
valhalla_db_filelist_get (handle, VALHALLA_FILE_TYPE_NULL, &r1, callback, NULL);

Facile, non?

A noter que ce n’est pas encore totalement optimal, car le groupe ne peut pas être donné avec les restrictions. Ainsi n’importe quel metadata de n’importe quel groupe est considérée dans l’inclusion comme l’exclusion.

Et d’un point de vue SQL

La aussi, la requête ressemble beaucoup à la précédente avec des différences au niveau de ce qui est sélectionné et dans quelle table.

SELECT file_id, file_path, _type_id
FROM file AS assoc
-- Les conditions sont optionnelles
WHERE
  -- Une sous-requête apparait par le biais des restrictions.
  -- Il y a autant de sous-requêtes que de restrictions du type IN, NOT IN.
  assoc.file_id <IN|NOT IN> (
    SELECT assoc.file_id
    FROM (
      data INNER JOIN assoc_file_metadata AS assoc
      ON data.data_id = assoc.data_id
    ) INNER JOIN meta
    ON assoc.meta_id = meta.meta_id
    -- A choix, il peut y avoir un ID ou du texte.
    WHERE meta.<meta_id|meta_name> = <ID|"TEXT"> AND data.<data_id|data_value> = <ID|"TEXT">
  )
  -- Le type n'est pas inscrit dans la requête si la valeur est NULL.
  AND _type_id = <ID>
ORDER BY file_id;

Si dans la clause FROM, la table “file” créer un alias “assoc”, c’est uniquement pour une question de factorisation dans le code par rapport à la sous-requête.

valhalla_db_file_get

Maintenant que l’on a vu comment récupérer des listes de metadata ainsi que des listes de fichiers, il est important de pouvoir aussi récupérer des metadata en fonction d’un fichier spécifique. Cette possibilité n’existait pas avec l’ancien modèle car les fichiers étaient toujours retournés dans une liste. Ici il est question d’un seul fichier à la fois. Il faut également être conscient que cette fonction est liée uniquement à la base de donnée, si un fichier non référencé dans la base mais existant quelque part est donné en argument, aucun résultat ne sera retourné (cette possibilité existera quand j’implémenterai le “scan on-demand”).

Les arguments sont donc l’id du fichier, le chemin du fichier, des restrictions et le pointeur sur la structure de résultat. Il n’y a pas de callback pour l’utilisateur car le résultat est limité à un seul fichier (en réalité il y a un callback interne qui récupère toutes les metadata car le vrai résultat est sur plusieurs lignes).

Les metadata sont disponibles dans une structure chaînée. Je dois également introduire une nouvelle possibilité des restrictions. Mais tout d’abord, voici un exemple:

valhalla_db_filemeta_t *metadata = NULL;
valhalla_db_restrict_t r1 = VALHALLA_DB_RESTRICT_STR (EQUAL, "track", NULL);
valhalla_db_restrict_t r2 = VALHALLA_DB_RESTRICT_STR (EQUAL, "title", NULL);
VALHALLA_DB_RESTRICT_LINK (r2, r1);
valhalla_db_file_get (handle, 0, "/home/foo/bar/dido/life_for_rent/white_flag.m4a", &r1, &metadata);
/* ... */
VALHALLA_DB_FILEMETA_FREE (metadata);

L’argument EQUAL dans la macro VALHALLA_DB_RESTRICT sert à limiter les résultats à des metadata précises. Sans les restrictions, la structure metadata contiendrait absolument toutes les metadata. Mais dans cet exemple, la structure contient uniquement le track et le titre. A noter qu’utiliser IN ou NOTIN ici ça n’a aucun sens. De même qu’utiliser EQUAL pour les deux fonctions précédentes (voir la conclusion).

Il faut être conscient que plusieurs tracks et plusieurs titres peuvent être retournés pour un même fichier. Car rien n’exclus que certains noms de metadata n’existent pas dans différents groupes. Et comme je l’ai dis plus haut, il n’est pour le moment pas possible de limiter une restriction à un groupe. Néanmoins le groupe est un champ de la structure valhalla_db_filemeta_t, il est donc possible de faire un tri à postériori.

Après utilisation des metadata, il ne faut pas oublier de les libérer avec VALHALLA_DB_FILEMETA_FREE().

Et d’un point de vue SQL

SELECT file.file_id, assoc._grp_id, meta.meta_id, data.data_id, meta.meta_name, data.data_value
FROM ((
    file INNER JOIN assoc_file_metadata AS assoc
    ON file.file_id = assoc.file_id
  ) INNER JOIN data
  ON data.data_id = assoc.data_id
) INNER JOIN meta
ON assoc.meta_id = meta.meta_id
-- Les conditions sont optionnelles
WHERE
  -- Une condition apparait par le biais des restrictions.
  -- Il y a autant de conditions que de restrictions du type EQUAL.
  -- A choix, il peut y avoir un ID ou du texte. Chaque restriction
  -- est séparée par un OR.
  (
    (meta.<meta_id|meta_name> = <ID|"TEXT"> AND data.<data_id|data_value> = <ID|"TEXT">)
    <OR> ...
  )
  -- Il faut l'id d'un fichier ou un path
  AND file.<file_id|file_path> = <ID|"PATH">
;

Cette requête retourne autant de lignes qu’il y a de metadata. Mais pour l’utilisateur, tout est transparent car les résultats sont tous retournés dans une structure chaînée.

En conclusion

Les possibilités de ce nouveau système sont très larges par rapport à l’ancien. Bien qu’il y ait encore quelques manques pour pouvoir spécifier des groupes avec les restrictions, il est possible de retrouver les données avec peu de lignes de code et simplement, tout en ayant des requêtes relativement complexes qui se créer en interne. Il y aura forcément des modifications à l’avenir, je tâcherais de garder à jour cet article.

Et pour en revenir aux restrictions et à l’argument qui peut prendre la valeur IN, NOTIN ou EQUAL, il faut comprendre que c’est avant tout une question de factorisation en interne. IN et NOTIN devraient être utilisés uniquement avec les deux premières fonctions présentées qui récupèrent des listes, et EQUAL devrait être utilisé uniquement pour la récupération des metadata d’un fichier. Je vais continuer à travailler sur ces éléments dans les jours à venir afin d’éviter des confusions.

A bientôt,

Mathieu SCHROETER

Au pays du dieu Odin, il est temps de ne plus limiter l’entrée de la Valhalla uniquement aux guerriers valeureux. Mais soyons fous et acceptons tout le monde, et peu importe leurs caractéristiques (cf. Valhalla Scanner).

Je travail ainsi à la refonte complète de la structure de la base de donnée. Pour rappel, le problème majeur vient du manque de souplesse à l’insertion des méta-données. Il n’est pas possible d’y insérer des informations autres que le titre, l’année, le numéro de piste, l’auteur, l’album et le genre. De nombreux fichiers offrants bien d’autres informations il est donc indispensable de revoir le modèle complètement. Mais qui dit nouveau modèle, dit aussi nouveau code et nouvelle API. La conséquence de cette réécriture provoquera indéniablement une fracture avec le module actuellement présent dans Enna et avec les bases de données générées par le système actuel. En date de cet article, je n’ai pas encore écris les modifications mais j’ai néanmoins fais les réflexions nécessaires. Et se sont ces réflexions que je vais partager ici “en partie “.

Nouveau modèle

L’idée est de se détacher des noms donnés au méta-données. Tel que “genre”, “author” et “album” par exemple. Ce ne sont finalement que des noms et devraient donc être traités comme de simple donnée dans la base de donnée. Il n’y aura donc plus de table nommée “genre”, etc. Mais une table regroupant les noms, et une seconde table regroupant les valeurs et gardant indirectement une relation entre le nom et la valeur.

Un tel système permet d’insérer une infinité de noms différents de méta-données et d’éviter en même temps les duplications. Il est important d’assurer un minimum de redondance. Si un genre est inséré, il ne faudrait pas qu’il soit réinséré trois fois si trois nouvelles données nommées “genre” seraient envoyées par le scanner. De même pour les valeurs, la valeur “rock” par exemple devrait apparaitre qu’une seule fois dans la base de donnée. Ainsi tous les fichiers qui feraient référence à “genre”->”rock” seraient tous liés à la même information. Ce qui est le cas avec l’ancien modèle, et il est important de conserver cette caractéristique pour une question de bon-sens et de qualité.

Mais rendre le modèle complètement générique apporte un nouveau problème. Il devient difficile de retrouver les informations qui concernent un même thème. Imaginez un fichier qui utilise le nom “genre” et un autre type de fichier qui utilise le nom “style”. Peut être que ces deux fichiers sont de la musique et que les deux contiennent la valeur “rock”. Mais une fois nous avons “genre”->”rock” et une fois nous avons “style”->”rock”.
Pour y remédier, il peut être judicieux de créer une troisième table qui permettrait de regrouper les paires nom->valeur sous des noms d’ensemble. Cette table se nommerait donc “group” et contiendrait une liste (pouvant être étendue si nécessaire) de différents groupes possibles. Voici une première liste de groupes (qui va encore évoluer):

Miscellaneous, Entity, Title, Classification, Personal, Temporal, Spacial, Commercial, Legal, Technical, Identifier, Musical, Contact, Organizational

Typiquement, par rapport à l’exemple précédent pour “genre” et “style”, il serait judicieux de regrouper ces paires dans le groupe “Classification”. Ainsi il serait facile de ressortir toutes les paires par groupe pour créer des listes de genre et de style en étant sûr que le nom “genre” ne fait pas référence à autre chose. On pourrait très bien imaginer que pour certains formats de fichier, ce soit des noms français et que ça ferait référence au genre (sexe) et non au style de musique. Il faudrait donc pouvoir assigner un autre groupe pour ces particularités. Ainsi, lors de l’insertion des méta-données d’un fichier, il sera obligatoire de chaque fois spécifier le groupe. Mais dans les cas “inconnu”, il sera toujours possible d’utiliser le groupe “Miscellaneous”.

Ça sera donc aux parsers de dire quel paire va dans quel groupe. Cela peut paraître un peu contraignant, car ça demande quelques réflexions sur le fonctionnement des parsers. Mais afin de pouvoir récupérer de la manière la plus exhaustives possible des informations depuis l’extérieur (comme Enna), il est indispensable de les regrouper correctement. Avec l’ancien système, ce n’est pas possible et c’est donc un plus que j’estime intéressant. Sans oublier que le nom des méta-données pourra également être récupéré depuis l’extérieur, et donc un tri pourra se faire sur les “genre” et sur les “style”, etc,.. si nécessaire. Et bien sûr, il sera qu’en même possible de récupérer tous les “genre” sans tenir compte des groupes.
(Quand je parle de “l’extérieur”, je parle donc des accès effectués depuis l’API et des valeurs récupérées. Je parle également toujours du genre, mais c’est un exemple.. l’idée est la même pour toutes les méta-données.)

Diagramme Entité/Relation

Le diagramme E/R ci-dessous résume assez bien à quoi va ressembler la base de donnée. Il se peut qu’il évolue encore, mais la forme générale (les relations) ne devraient pas trop bouger.

D’habitude je préfère travailler avec des diagrammes MERISE, mais le logiciel Dia est mieux adapté pour du E/R. Pour les non-adeptes des E/R, le rectangle/losange “is defined by” correspond à une table d’allocation ayant pour clef primaire (file_id, meta_id et data_id).

But final

Cette petite analyse du modèle est un premier pas vers une future modification de Valhalla, dans laquelle il sera possible d’y introduire directement les grabbers d’Enna (les grabbers sont les modules qui permettent de récupérer des informations et des images via Allocine, IMdB, etc,..).

Il y a quelques indications dans ce document (voir aussi ici), mais j’en parlerais plus en détail dans un nouvel article, dès que j’en aurais terminé avec le nouveau modèle et son implémentation.

A bientôt,

Mathieu SCHROETER

Nerusin post yg kemaren. Begitu tahu permasalahannya terletak pada permission mounted folder yg di buat otomatis oleh ivman, ada 2 hal yg dpt saya pikirkan. Yang pertama, there’s gotta be some way to make ivman to set permission for every folder it’s created. So, saya cari settingnya pada file xml milik ivman di /etc/ivman. Ada satu setting yaitu ttg umask yang defaultnya bernilai ‘007′ yang mungkin berhubungan dgn masalah perijinan ini. Hmmm, ternyata dugaanku benar, umask mmg ada berhubungannya. Tanpa riset lebih lanjut lgs aku ganti aja menjadi ‘777′ dgn harapan semua user diijinkan untuk mengakses, perkiraaan saya setting umask=chmod. Ternyata tetep gak bs Sempet saya tanyakan ama temen2x Assistant Lab di kantor, ternyata mereka jg gak familiar. Googling bentar akhirnya semua jd jelas. Umask kebalikan dari chmod, jd nilai yg seharusnya adalah ‘000′. Reboot lagi tapi tetep gak bisa

Karena udah mulai bosan ama hal spt ini, saya putuskan melakukan cara kedua. Bikin autologinnya menjadi user root, jd apapun yg diset ivman pasti bisa dibaca. The problem is, taruh dimana setting autologin nya ? Akhirnya aku ubek2x yg namanya /etc, semua file yg sekiranya berhubungan autolgin saya baca semua. Mulai file inittab sampai file dan direktori rc dan temen2xnya. Tetep gak nemu akhirnya saya coba set autologin pake MCC dan ternyata malah paket autologin tdk terinstall. Heeeh, lha selama ini saya autologin pake apa ? Ok, saya turuti permintaanya, install paket autologin nya. Trus saya pilih user root kemudian reboot. Tp apa yg terjadi, tetep aja login pake user live And then I gave up, I don’t want to spend more time for something that should running out of the box…

Well, Saya tidak mengira hanya untuk sebuah Media Center dengan fitur yg sederhana saja menghabiskan waktu dan tenaga sebanyak ini. Udah gitu gagal pula Positifnya, saya skr jd lebih tahu proses internal booting Linux. Akhirnya saya putuskan untuk tetep memakai GeexBox dan istri saya harus bisa menerima tampilan UI GeexBox yang terlalu sederhana tersebut Using GeexBox everything work since the first time I installed it to CF.

Tapi terus terang saya masih penasaran mengenai Freevo. Maybe another time or another project…

Beberapa hari terakhir ini saya menghabiskan banyak waktu untuk melakukan riset mengenai software media center. Mulai yang berbasis Windows sampai dengan Linux (pengennya sih pake Haiku, hehehe)

Anyway berikut ini kriteria media center yang saya cari :

1. Lightweight

krn berjalan di pc memakai prosesor VIA C3 dgn Memory 256 MB

2. Running from Compact Flash
3. Support TV & FM Radio
4. Basic support : Video player, Music Player & Picture Viewer
5. WAF (Wife Accepted Factor)

Dengan kriteria diatas mestinya mudah bukan ? Well, I’m completely wrong about that

Pertama2x mengenai pemilihan OS. Karena saya ingin diinstall ke CF maka Windows XP bukan menjadi pilihan utama. Ya, saya tahu saya bisa melakukan kustomisasi dengan aplikasi seperti nlite atau xplite untuk mendietkan Windows menjadi lebih ramping. I’ve done that in the past. Actually I succeeded making under 300 MB Windows XP installation with everything working perfectly. Tapi masalahnya pada terletak pada software media center (MC) nya itu sendiri. Tidak ada MC di Windows yang cukup ringan untuk berjalan di prosesor VIA C3. Saya sudah mencoba XBMC, Media Portal, Elisa, Meebo dan ada satu lg yg saya lupa namanya. Bahkan saya mencoba interface untuk CarPC seperti FreeRunner dan FreeIce hanya untuk mencari interface yang ringan dan tidak bloat (coba pake FreeIce, it’s the favorite so far). Tp tidak ada yang berjalan lancar pada sistem saya. Jadi jalan terakhir harus memakai Linux.

Sebenarnya ada satu Distro Linux untuk MC yang sampe saat ini tetap saya pakai dan selalu menjadi favorite. Distro tersebut adalah GeexBox. In fact, tinggal install GeexBox ke CF maka selesai sudah. Hampit semua kriteria diatas terpenuhi dengan memakai Geexbox. Hanya pada 1 hal GeexBox gagal, which is WAF UI GeexBox terlalu sederhana yg menyebabkan Istri saya tidak tertarik memakainya

So the journey continue……

Untung ada site ini yang banyak membantu kondisi Open Source MC saat ini. Dari daftar tersebut ada 2 aplikasi yang menjadi perhatian saya, Freevo dan MyMediaSystem (MMS). I’ve tried MMS in the past too, try to compile it under Puppy Linux. Berhasil sih, cuman butuh proses yg lama untuk belajar dan compilasinya. Ditambah lagi pada versi terbaru 1.10 tidak support Radio lagi . Jadi satu2xnya harapan ada pada pundak Freevo

Freevo yang ada skr ini msh merupakan versi lama yaitu versi 1.83. Pengembangan untuk versi 2.x berjalan sangat lamban. Malah kl tdk salah mau direwrite ulang. GeexBox yg dulu berencana memakai Freevo 2.x sebagai basis MC terpaksa meninggalkan dan sekarang malah sedang membangun MC versi mereka sendiri (Enna).

Krn pengen cepet selesai maka saya berusaha menggunakan Distro Linux khusus Freevo yg ada, yaitu FreevoLive dan Piren. Pertama saya coba Piren karena lebih up2date (berbasis Debian Lenny). Sayangnya gagal ketika diinstall ke CF Karena berbasis Debian maka saya coba install Debian nya yg asli. Ternyata gagal juga . Kemudian saya menemukan dokumentasi mengenai installasi Freevo pada CF menggunakan Ubuntu Intrepid. Saya mencoba langkah demi langkah sesuai dokumentasi tp tetep gagal juga. Ternyata Debian dan Ubuntu hanya support CF dengan konverter CF to IDE yg menggunakan UDMA. Sayangnya yg saya punya hanya support PIO4. So back to zero again…

Akhirnya saya mencoba FreevoLive (berbasis Mandriva 2007.1 Spring), dan ternyata berhasil install ke CF Horay…. tp ternyata muncul permasalahan baru. Freevo yg dipakai ternyata versi 1.7.3, cukup lama karena versi terbaru utk Mandriva adalah versi 1.8.0 (lama juga sih, tp utk saat ini blm ada pilihan lain…).
Saya coba mengupdate Freevonya lebih dahulu. Berhubung ini pengalaman pertama saya mengoprek Mandriva maka saya sempet bingung jg melakukan automatic update. Karena udah tidak sabar (udah banyak waktu yg saya habiskan utk masalah MCE ini) maka saya update manual, yaitu download paket rpm nya satu persatu. Setelah melalui dependency hell akhirnya kelar juga updatenya (note to myself, don’t try to update Mandriva manually because it’s really exhausted). Tp ketika dijalankan memakai automatic login (user biasa, bukan root) jadi malah gagal ternyata harus mengetikkan perintah ‘freevo cache’ dahulu ketika selesai update. Akhirnya bisa jalan juga, hehehe….

Tp kok gak support automount untuk USB storage ya. Padahal ketika pake XFCE bisa lgs dimount ya terpaksa oprek2x lg Pertama saya coba pake setting plugin bawaan Freevo, gagal Browsing sebentar ternyata bisa dilakukan menggunakan usbmount. Cari usbmount utk Mandriva, tidak ada Googling lagi nemu pmount. Cari pmount untuk Mandriva ternyata ada Install pmount, sukses ! trus pmount nya hrs diapakan nih ? Googling lg, ternyata pmount tidak bisa otomatis, hrs diketikkan manual udah mulai nyerah nih… Coba googling sekali lg nemu ivman. ivman handler otomatis untuk even HAL yang kebetulan biasa dipake bareng pmount. Seep. Trus cari ivman for Mandrive, ketemu. Lgs aja install, sukses !. Coba jalankan ivman dan tancepin usb flashnya, sukses ! Akhirnya… skr restart menggunakan automatic login (bukan root), gagal user biasa tidak dpt ijin untuk mengakses folder hasil mount yg dibikin ivman. Googling lg, oops udah jam 7.00. Waktunya ngantor dulu Diterusin entar malem, tinggal dikit lg nih

Hello,

S’il y a bien quelque chose qui me dérange dans les codes sources se sont les mélanges entre les tabulations et les espaces avec l’indentation. Une des justification de ne pas utiliser les deux façons de faire en même temps, est tout simplement le résultat d’un `diff`. La première colonne du `diff –unified` est réservée à un espace, un ‘-’ ou alors un ‘+’. Ainsi lorsqu’un patch est lu et que les tabulations se mélangent avec les espaces, les éléments ne sont plus alignés comme dans cet exemple:

 void foobar (void)
 {
-        printf ("Hello ");
+	printf ("World!\n");
 }

Le premier printf utilisant 8 espaces et le second une tabulation. (à noter que l’affichage dans WordPress est faussé, à moins de regarder le code en cliquant sur le lien “view plain”)

Souvent dans les sources avec une indentation de 4 espaces, les tabulations sont utilisées pour chaque 8 espaces. Il y a donc régulièrement des lignes qui mélangent les deux en commençant par une tabulation, puis 4 espaces afin d’atteindre le 3ème niveau, et ainsi de suite.

Alors je n’ai rien contre les tabulations, mais seulement si elles sont utilisées pour représenter une indentation de 8 colonnes tel que c’est le cas dans le noyau Linux. Il y a même parfois pire. Certaines personnes changent la configuration du TAB afin qu’il fasse 4 colonnes au lieu de 8 (qui est la valeur par défaut). Ainsi pour les autres développeurs, la lecture du code est très difficile. Chose qui ne peut en aucun cas arriver avec des espaces.

Vim

Mon but n’est pas d’ouvrir un troll entre Vi(m) et Emacs. En ce qui me concerne, j’utilise Vim pour une raison “historique”. C’est tout simplement le premier éditeur de texte évolué que j’ai utilisé sous Linux et je n’ai jamais eu l’envie de changer mes habitudes, celui-ci me donne entière satisfaction.

Afin de pouvoir travailler dans de bonnes conditions pour le développement, voici ma configuration actuelle de Vim (~/.vimrc).

" Global settings
:set nocompatible
:syntax on
:set hlsearch
:set shiftwidth=2
:set background=dark
:set cursorline

" Show line number
:set number
:highlight LineNr term=bold ctermfg=darkgray guifg=darkgray

" Special configuration for development
:filetype on
:autocmd FileType c,cpp,cxx,h set cindent|set tabstop=8|set softtabstop=2|set expandtab
:autocmd FileType make setlocal noexpandtab

" Special highlighting for Doxygen
:let g:load_doxygen_syntax=1

" Show when a line exceeds 80 chars
:au BufWinEnter * let w:m1=matchadd('ErrorMsg', '\%>80v.\+', -1)

" Highlight Tabs and Spaces
:highlight Tab ctermbg=darkgray guibg=darkgray
:highlight Space ctermbg=darkblue guibg=darkblue
:au BufWinEnter * let w:m2=matchadd('Tab', '\t', -1)
:au BufWinEnter * let w:m3=matchadd('Space', '\s\+$\| \+\ze\t', -1)
:set list listchars=tab:»·,trail:·

En plus de la coloration syntaxique, il y a quelques paramètres pour éviter des bavures dans le code. L’un d’eux permet de montrer explicitement si une ligne dépasse les 80 caractères. Elles apparaissent en rouge mais ne sont pas coupées. Parfois il est voulu de dépasser cette limite. Deux autres paramètres mettent en évidence les espaces non désirés (à la fin d’une ligne par exemple), ainsi que les tabulations.

Il y a également des paramètres pour faciliter l’indentation. Celle-ci est définie pour 2 espaces tout en affichant les tabulations sur 8 colonnes. Il faut aussi être conscient que les “highlights” ont un prix et qu’ils ralentissent l’affichage de manière significative.

Vous pouvez voir ci-dessous un “screenshot” de Vim avec une tabulation et des espaces non-désirés (qui utilisent la configuration susmentionnée).

Vim (cliquez sur l'image pour la voir à sa taille original)

• Une doc complète sur Vim: www.swaroopch.com/notes/Vim_fr

A bientôt,

Mathieu SCHROETER

Hello,

Un petit nouveau a fait son entrée dans les dépôts de GeeXboX. C’est un projet qui est né suite à quelques expériences négatives avec une autre bibliothèque. Elle m’avait alors motivé à en écrire une afin d’y apporter une vision un peu différente. Le but de Valhalla (ou libvalhalla), est très simple, elle va scanner des emplacements sur votre disque dur (par exemple) afin d’y trouver des fichiers audio/video pour les référencer dans une base de données. Il est alors facile ensuite d’y effectuer des requêtes permettant de générer des listes d’artistes, d’albums, etc,…

Mais tout d’abord.. pourquoi Valhalla?

Dans la mythologie nordique, la Valhöll (ou Walhalla, Valhalla, Valhalle), demeure-des-occis, est le lieu où les guerriers valeureux sont amenés. C’est sur les champs de bataille que des vierges guerrières (pour les celts) ou des Valkyries (pour les germains), cherchent et récupèrent les hommes les plus braves et les plus valeureux afin de les ramener dans Ásgard, où Odin les attend pour les préparer à la bataille finale, le Ragnarök.
Dans la Valhöll(palais de Thor), les guerriers alors nommés Einherjar sont heureux : ils combattent, se tuent, renaissent pour encore se pourfendre dans un champ clos.

Valhöll. (2009, mars 10). Wikipédia, l’encyclopédie libre. Page consultée le 17:42, mars 12, 2009 à partir de http://fr.wikipedia.org/w/index.php?title=Valh%C3%B6ll&oldid=38802776.

Je cherchais un nom qui sort de l’ordinaire tout en gardant un sens par rapport à la fonctionnalité de cette bibliothèque. Si la définition de La Valhalla ci-dessus ne vous a pas convaincu, imaginez que les scanners sont les Valkyries, que les braves sont les fichiers audio/video, et qu’elles les emmènent à la Valhalla (dans la base de donnée). Ceux-ci mourant et renaissant sans cesse dans un champ clos (les fichiers pouvant être rescannés en boucle afin d’y repérer les modifications).

(A noter que Valgrind est la porte qui mène à La Valhalla)

Fonctionnement

Small. Fast. Reliable.

Valhalla se base sur deux bibliothèques principales. Tout d’abord il y a la libavformat (de FFmpeg) qui permet de récupérer les méta-données, puis SQLite qui s’occupe de gérer la base de donnée. Si ces libs ont été choisies c’est pour de bonnes raisons. Comme je l’ai dis plus haut, libvalhalla est née suit à des expériences avec une autre lib. En premier lieu, cela concerne le moyen pour récupérer les méta-données. Sans rentrer dans des détails inutiles, pour se faire il est nécessaire de passer par des démuxeurs et en créer peut avoir un avantage certain sur la rapidité. Néanmoins beaucoup de travail serait nécessaire pour gérer la plupart des formats de fichier, et c’est ici qu’intervient FFmpeg. Cette bibliothèque étant la plus aboutie, elle supporte énormément de formats. Il est donc facile de récupérer les méta-données sans se soucier du “comment”. La deuxième raison est purement technique. Certains aspects dans la construction de l’autre lib ne me plaisaient pas (à tord ou à raison).
Concernant SQLite, c’est un excellent outil (et très léger et rapide) de gestion de base de données.

Architecture

Avant d’aborder l’architecture en elle-même j’aimerais expliquer mes choix. Tout d’abord Valhalla repose sur les threads. Parce que j’aime travailler avec les threads même si de nombreuses personnes estiment que les “threads are evil”. Ensuite il y a une raison liée à l’aspect pratique et à l’aspect vitesse. D’un point de vue pratique, les threads sont un moyen facile de créer des tâches parallèles et aussi de créer des tâches de fond. Il est intéressant dans le cas d’Enna, de pouvoir l’utiliser sans être bloqué par Valhalla.

J’entends certaines personnes me parler des fork(), alors oui c’est également un moyen.. mais franchement, communiquer entre des sous-processus c’est pénible et nettement moins efficace que de le faire directement entre deux threads qui partagent le même espace mémoire. Les fork() doivent être utilisés si le contexte le demande. Tel que c’est le cas dans libplayer pour travailler avec MPlayer.

L’aspect vitesse est également intéressant car aujourd’hui il est courant de trouver des ordinateurs avec au moins 2 cores. Alors quitte à faire travailler les démuxeurs sur les deux (ou plus), je vous montrerais des petites statistiques plus loin.

La figure ci-dessous présente une vision simplifiée de l’architecture.

Il y a trois parties principales. En vert, le scanner s’occupe de chercher tous les fichiers qui respectent certains critères relatifs à leur nom. Puis chaque référence aux fichiers est envoyée à la partie jaune (Database) qui va vérifier si le fichier existe déjà dans la base de donnée ou s’il est nouveau. Si des modifications sont nécessaires, alors il est envoyé à la partie orange (Parser) afin que les méta-données soient récupérées. Le parser renvoit les données à la Database qui va alors insérer les modifications adéquates dans la base de données à travers SQLite. Chaque bloc représenté dans la figure est un thread. La partie orange peut contenir plusieurs parsers et donc plusieurs threads.

FFmpeg

A complete, cross-platform solution for audio and video.

Les parsers utilisent la bibliothèque libavformat d’FFmpeg pour réaliser l’extraction des méta-données. Il y a cependant un problème de vitesse. libavformat fait appel à des fonctions de “probe” afin d’identifier le format du fichier pour lui assigner le bon démuxeur. Et dans certains cas (fichiers altérés?), le “probe” prend beaucoup de temps car il y a beaucoup de démuxeurs et qu’il est parfois nécessaire de tester plusieurs fois un même fichier (en avançant dans les données) avant que la lib puisse deviner lequel est le bon.

L’idée est donc de proposer un format directement à libavformat au lieu de le laisser procéder tout seul à la détection. Le moyen utilisé est très simple et efficace. Il est rare que le suffixe d’un fichier ne correspond pas au bon format. La première étape est donc de récupérer le nom du format qui est lié au suffixe (à l’extension). Typiquement, si les fichiers sont des .mp3, le nom est tout simplement “mp3″. Voir les détails dans les sources.

name = suffix_fmt_guess (file);
if (name)
  fmt = av_find_input_format (name);

La deuxième étape est un petit peu plus compliquée. Bien que l’on a désormais une idée sur le démuxeur, il est exclus de l’utiliser tel quel. Si un format est forcé à l’ouverture du fichier, aucun test n’est réalisé par libavformat. Ainsi, une fonction de probe() a été écrite pour tester le démuxeur. L’avantage cette fois vient du fait qu’un seul démuxeur est testé, et non plus tous les démuxeurs de libavformat. Le gain en vitesse est impressionnant (j’ai constaté un gain de plus d’un facteur dix avec cette technique et un peu plus de 1000 MP3/OGG).

if (fmt)
{
  int score = parser_probe (fmt, file);
  if (!score) /* Bad score? */
    fmt = NULL;
}

Si vous êtes intéressé par la fonction parser_probe(), je vous invite à directement la consulter dans les sources. En résumé, la fonction est inspirée de libavformat/utils.c::av_open_input_file(), et dépend fortement de l’implémentation interne de libavformat en ce qui concerne les scores retournés par les fonctions de probe().

Les priorités

Si vous désirez définir des priorités non temps réelles à des threads, voici l’astuce:

#include <unistd.h>
#include <sys/resource.h>
#include <sys/syscall.h>

static inline void
my_setpriority (int prio)
{
  pid_t pid = syscall (__NR_gettid);
  setpriority (PRIO_PROCESS, pid, prio);
}

La fonction gettid() n’existe pas dans la glibc, il est donc obligatoire de passer par un appel système. Et sans utiliser setpriority(), il n’est pas possible à ma connaissance de baisser la priorité en étant un simple utilisateur.

Défaut de jeunesse

Malheureusement un défaut relativement important a été soulevé par Aurélien (un des leader du projet GeeXboX et développeur de FFmpeg). Les méta-données disponibles dans les fichiers audio/video peuvent être très différentes d’un format à l’autre. Valhalla est limité dans le nombre de meta-données supportées. Une future mise à jour majeure devrait apporter beaucoup plus de souplesse pour la gestion des méta-données. A priori cela ne semble pas si compliqué, mais si l’on considère le fait que la base de données suit un modèle relationnel, il est difficile d’être complètement générique.

Je n’ai pas encore pris le temps d’étudier toutes les possibilités pour y remédier. Mais ça fait partie de mes priorités pour Valhalla.

Enna

Mon but principal est d’utiliser Valhalla dans Enna. Ainsi un nouveau module à fait son apparition et permet de retrouver de manière thématique les albums, les artistes, les genres ainsi que les fichiers non-classés. Le module est également paramétrable depuis le fichier ~/.enna/enna.cfg pour surtout y indiquer les répertoires à scanner.

[valhalla]
path=file:///home/foo/music
path=file:///home/bar/music
verbosity=info
parser_number=2
commit_interval=128
# <=0 for infinite
scan_loop=-1
# time [sec] for sleeping between loops
scan_sleep=900
# 0: normal, -20: higher, 19 lower
scan_priority=19

Quelques paramètres méritent certaines explications. Tout d’abord vous pouvez indiquer autant de “path” que vous le désirez. Les paths ne sont pas scannés en parallèle, mais séquentiellement. Il n’y a pas beaucoup d’avantage de scanner  plusieurs répertoires en parallèle car les accès au disque ne seront pas plus rapide.
Vous pouvez bien sûr changer la verbosité de la bibliothèque. L’intérêt est limité pour de simples utilisateurs, mais ça peut être utile dans des cas de debuggage.

Nombre de parsers

L’option “parser_number” indique le nombre de parsers à créer. Par défaut, le nombre maximum est de 8. Ce chiffre peut être changé à la compilation de Valhalla en passant le define PARSER_NB_MAX=# dans le CFLAGS. Mais il faut garder à l’esprit qu’il est inutile de définir beaucoup de parsers car ça n’augmentera en rien la vitesse.

Intervalle entre les commits

L’option “commit_interval” permet de dire chaque combien de fichiers, les données sont réellement inscrites dans la base de données. Moins cette valeur est grande, et moins le scan sera rapide car SQLite augmentera le nombre d’écritures sur le disque dur. J’ai constaté un gain de ~20 en passant d’une valeur de 1 à une valeur de 128. Si vous définissez une valeur plus grande, le gain ne sera plus tellement visible et les données s’accumuleront dans la RAM. Le fait de mettre une petite valeur est également plus sûr, car en cas de plantage, plus de données seront écrites. C’est donc aussi une question de bon sens.

Bouclage du scan et temps entre les scans

L’option “scan_loop” indique le nombre de bouclage qui doivent être effectués pendant qu’Enna est exécuté. L’intérêt est de détecter les modifications et les nouveaux fichiers. En mettant une valeur de 1, le scan se fera uniquement au démarrage d’Enna. Par contre avec une valeur plus petite ou égale à 0, le scan se fera chaque “scan_sleep” secondes. Vous pouvez bien sûr donner une valeur supérieure tel que 2, 3, etc,.. pour définir exactement le nombre de bouclages désiré.

Priorité du scan

L’option “scan_priority” permet de garantir que le scanner, le gestionnaire de la base de données ainsi que les parsers, ne puissent pas monopoliser les ressources de votre système. Le fait de donner une valeur de 19, garanti que Valhalla aura la priorité la plus basse et son comportement sera bien une tâche de fond. Par défaut un utilisateur à une priorité de 0, et tous les programmes exécutés ont une priorité de 0 (vous ne pouvez donc donner que des priorités inférieures (valeurs positives ou égales)). Si vous n’avez pas les droits appropriés et que vous donnez une priorité de -1 à -20, Valhalla gardera une priorité de 0. Par contre, si vous êtes root, alors vous pouvez mettre n’importe quel priorité. (Il n’est pas recommandé de mettre une priorité supérieure ou égale à Enna à moins d’affecter directement la lecture des fichiers et l’interface.)

La suite

Comme je l’ai expliqué plus haut, il reste beaucoup de travail pour rendre la bibliothèque plus générique envers les méta-données. Mais il reste également du travail au niveau de l’API, en ce qui concerne les fonctions pour sélectionner les données dans la base de données, et ces fonctions dépendent directement des méta-données.

Bien sûr, il est possible d’effectuer des requêtes sur la base de données sans passer par Valhalla. Mais dans ce cas il faut être conscient qu’il peut y avoir des problèmes de parallélisme. SQLite utilise fcntl() pour bloquer l’accès au fichier le temps des modifications. Mais sur certains systèmes de fichier, cela est buggé (voir les explications  ici).

Quelques modifications mineures sont également prévues, comme l’ajout de filtres sur les paths, pour par exemple ignorer les fichiers et dossiers cachés. Et également un moyen de récupérer l’information si un fichier contient des flux audio, video ou audio+video.

Une mise à jour concernera également l’ajout d’informations sur la version du fichier de base de données et la version de Valhalla. Car actuellement, si des modifications structurelles sont effectuées sur la base de données, Valhalla ne fait aucun contrôle sur le fichier qui a été créé par une ancienne version. Ce qui peut provoquer des erreurs plus ou moins imprévisibles lors de l’exécution d’un scan. Le temps que j’implémente cette partie, il est judicieux d’effacer le fichier ~/.enna/valhalla_music.db lors d’une mise à jour de Valhalla.

Télécharger

Pour télécharger Valhalla, rien de plus simple:

hg clone http://hg.geexbox.org/libvalhalla

La compilation et l’installation se fait comme pour n’importe quel logiciel.

./configure && make && sudo make install

Pensez aussi à faire un `sudo ldconfig` pour être sûr que la lib soit référencée pour le chargeur de programme.

Il est également important (indispensable) d’utiliser une version récente d’FFmpeg!

Quelques statistiques

Comme promis, voici quelques statistiques liées à la vitesse du scan. Le premier scan est toujours le plus long. La vitesse dépend principalement de la vitesse d’accès du média sur lequel se trouve les fichiers. Puis en second lieu, elle dépend également du cache effectué par le système de fichier. Mes quelques tests ont été fait sur une partitions EXT3 avec principalement des fichiers MP3 (dont des corrompus), des fichiers OGG, WMA et M4A. (le fichier de base de données est bien sûr effacé entre chaque essai). Il y a 1090 fichiers et mon système est dual-core.

Premier scan (sans cache)

Run: parser=2 loop=1 wait=0 priority=19 commit-int=128
Time elapsing: 24675.591000 msec, 24.675591 sec

Quelques scans (même config + cache)

Time elapsing: 1049.802000 msec, 1.049802 sec
Time elapsing: 1183.110000 msec, 1.183110 sec
Time elapsing: 1066.583000 msec, 1.066583 sec

La vitesse a énormément changée et pourtant la bibliothèque à fait exactement le même job. Le cache du système de fichier a un effet très important.

Avec un seul parser (1 parser + cache)

Run: parser=1 loop=1 wait=0 priority=19 commit-int=128
Time elapsing: 1500.876000 msec, 1.500876 sec
Time elapsing: 1436.085000 msec, 1.436085 sec
Time elapsing: 1637.296000 msec, 1.637296 sec

On note en moyenne 1.10 sec pour 2 parsers et 1.53 sec pour 1 parser. Vous me direz que ça n’a rien d’exceptionnel et vous avez tout a fait raison. La différence est de 430 ms entre les deux moyennes. Mais en réfléchissant un peu, cela représente qu’en même un gain de ~40%.
Ces statistiques ne sont pas très exhaustives car 1090 fichiers ce n’est pas grand chose. Il faudrait également effectuer beaucoup plus de tests pour avoir une statistique relevante. Mon but était juste de vous montrer que le nombre de parsers ne fait pas de miracle. Et qu’avoir plus d’un parser lors du premier scan ne changera quasiment rien. Mais si vous avez beaucoup plus de fichiers que moi, (des dizaines de milliers) l’impacte sera bien plus grand.

Avec un commit-int à 1 (+ cache)

Run: parser=2 loop=1 wait=0 priority=19 commit-int=1
Time elapsing: 20299.520000 msec, 20.299520 sec
Time elapsing: 18831.318000 msec, 18.831318 sec
Time elapsing: 19063.652000 msec, 19.063652 sec

Voyez comme l’intervalle entre les commits effectués par SQLite sont très important. Passer de 1.5 sec à 20 sec n’est pas du tout négligeable.

Avec un commit-int à 1024 (+ cache)

Run: parser=2 loop=1 wait=0 priority=19 commit-int=1024
Time elapsing: 935.655000 msec, 0.935655 sec
Time elapsing: 1018.052000 msec, 1.018052 sec
Time elapsing: 953.042000 msec, 0.953042 sec

Il est intéressant de noter qu’avec un intervalle de 1024, Valhalla arrive à descendre en dessous de la seconde. Maintenant vous comprendrez qu’il est difficile de trouver une configuration parfaite pour tout le monde. Mais le gain entre un intervalle de 128 ou de 1024 n’a plus beaucoup d’impact. Sans compter que 128 est plus sûr dans le cas d’un crash.

(Tous les tests ont été effectué avec l’outil test-valhalla directement disponible depuis les sources.)

Conclusion

Il reste beaucoup de travail à faire, mais vous pouvez utiliser cette bibliothèque correctement dans l’état actuel. Les performances sont à mon avis très bonnes et le nombre de parsers sera sûrement plus significatif dans le futur, car certaines améliorations auront forcément un impact sur la vitesse de récupération des méta-données. Même sur un système mono-processeur (mono-core), il est judicieux de garder 2 parsers. Parfois certains fichiers sont relativement altérés et difficiles à parser. Le fait de garder un deuxième parser assure un bon enchaînement si l’un d’eux perd du temps.

A bientôt,

Mathieu SCHROETER

So, what happened in the GeeXboX world since FOSDEM and the beginning of 2009. As you all may have seen, the 1.2 (and even 1.2.1) release finally landed out. It was a big relief and seems to please a lot of people from now on. In the mean time, we’ve upgraded major GeeXboX components, namely Linux kernel and X.Org and the development tree is now a really big mess (a.k.a. everything crashes so bad we don’t even know where to look for). The Linux graphics parts is currently evolving quite fast and most of drivers are being completely rewritted, resulting in a lot of issues. Though, we’ll try to fix it ASAP, especially now that Enna has been included in GeeXboX as new default UI, in order to provide you very soon with the very first 2.0-alpha release.

For video decoding fans, it is good to know that MPlayer now natively supports VDPAU, the h/w video decoding framework from nVidia. When used with the adequate nVidia proprietary drivers for X.Org, it is now possible to make MPEG-1/2/4, H.264 and VC-1 video decoding done by your GPU. It is not yet included in GeeXboX, as it relies on the non-redistribuable  proprietary driver but we’re considering a way to optionally add it afterwards. In the mean time, an experimental branch of FFMpeg is available, which provides multi-threading support. This is a much more elegant solution that actually finally allows you to use more than 1 thread (or CPU core) at a time for video decoding. On my Intel Q6600, using the 4 cores actually provides a 3x faster decoding speed, which is simply awesome. This has not yet been included into GeeXboX but it’ll definitely be part of the next alpha release.

And now comes the most interesting part: news from Enna. Most of our time and resources are currently wasted on Enna, our next-gen UI. Nico recently did a lot of work on it in order to both simplify the code and fasten it quite a bit. On my side, I’ve just finished adding a new weather module, that makes use of Google Weather Web API to provide you weather forecast (up to 4 days). But the following screenshot is probably better for you to see the newly added stuff:

Davide, on his side has started working on Enna for the very first time and he already manage to create a new games module that looks for all games installed to your Linux desktop and allows you to start them out from Enna interface. Being our DVB/VDR guru, Davide is also working on a new TV module for Enna that would allow Enna to directly use VDR (VideoDisk Recorder) to grab and display DVB streams (with recording capabilities) but it’s a long time plan, and still far from being completed.

The major contribution from these last days probably comes from Mat, who introduces a new component called libvalhalla that actually is an ultra-fast multi-threaded media scanner library that extracts metadata from all of your audio files (through FFMpeg libs) and save them back to an SQLite database. He of course also wrote the Enna browser plugin that makes use of libvalhalla allowing user to browse his media library by different criterias such as artist, album and so on …

Pretty good, isn’t it ? Now I feel that you’re all eager to test out the alpha release :p So let’s get back to the code and try to fix it so that we can provide it to you whenever it’s possible

This is the first part of the article, you might like to read Part 2

Live CDs are unique un-putdownables that have the ability to run a complete, modern operating system on a computer lacking mutable secondary storage, such as a hard disk drive. Using Live CDs you can get the envirenment of your ever-loved OS on any computer even without ainstalling or altering any settings in that computer. Today we review Ten (10) live cds which, we feel are very good in terms of the functionality they provide. We have mentioned the unique feature and funcationalty of every Live CD distro. Go ahead, and try one today!

Puppy Linux: Puppy really is small, the live-CD typically being 85MB, yet there really is a complete set of GUI applications. Being so small, Puppy usually loads completely into RAM, which accounts for it’s incredible speed. Puppy Linux is extremely userfriendly and is highly recommended for Linux Newbies. It has all the applications required for daily use and can run multimedia out-of-the box (and they say playing videos on Linux is not easy). Puppy Linux is very low on system resources and will breathe new life into old PCs.

KNOPPIX is a bootable Live system on CD or DVD, consisting of a representative collection of Linux software. Knoppix boasts about automatic hardware detection, and support for many graphics cards, sound cards, SCSI and USB devices and other peripherals, the works. KNOPPIX can be used as a productive Linux system for the desktop, educational CD, rescue system, or adapted and used as a platform for commercial software product demos. It is not necessary to install anything on a hard disk. Due to Knoppix’s on-the-fly decompression, the CD can have up to 2 GB of executable software installed on it. The DVD “Maxi” edition has over 8GB of software.

Slax is a portable, small and fast Linux operating system with a modular approach and outstanding design. Despite its small size, Slax provides a wide collection of pre-installed software for daily use, including a well organized graphical user interface and useful recovery tools for system administrators. The modular approach gives you the ability to include any other software in Slax easily. Say, if you’re missing your favourite text editor, networking tool or game, simply download a module with the software and copy it to Slax. You don’t even need to install or configure anything.

UBCD for Windows is a bootable recovery CD that contains software used for repairing, restoring, or diagnosing almost any computer problem which has Windows Operating System installed on it. Almost all software included in UBCD4Win are freeware utilities for Windows. UBCD4Win is based on Bart’s PE. Bart’s PE builds a Windows “pre-install” environment CD, basically a simple Windows® XP booted from CD. UBCD4Win includes network support and allows you the ability to modify NTFS volumes, recover deleted files, create new NTFS volumes, scan hard drives for viruses, etc.

GeexBox is a standalone LiveCD-based distribution which aims at turning your computer into a so called HTPC (Home Theater PC) or Media Center. It’s a ready to boot operating system than works on any Pentium-class x86 computer or PowerPC Macintosh, implying no software requirement. You can even use it on a diskless computer, the whole system being loaded in RAM. Despite his tiny ISO image size (~20MB), the distribution comes with a complete and automatic hardware detection, not requiring any driver to be added. It supports playback of nearly any kind of audio/video and image files and all known codecs and containers are shipped in, allowing playing them through various physical supports, either being CD, DVD, HDD, LAN or Internet.

This article will be continued in it`s second part where we will tell you about five more awesome Live-CD based distributions. So keep watching till we author the Part 2. You can read our Linux related articles in the Linux Section.

This is the first part of the article, you might like to read Part 2

Technorati Tags: live cd, linux, windows, software

Esta es una nota de
Es excelente por lo cual la replico aqui como consulta.

En principio me autoplagio y actualizo este post que escribi hace tiempo:
Cosas a hacer despues de instar Ubuntu 8.04 Hardy Heron,
pero actualizando alguna cosilla con respecto a la nueva version.
De todas formas recomiendo leer el post anterior pues muy pocas cosas
cambian y ademas se completa bastante con los mas de 170 comentarios que vosotros
habeis ido dejando.

Aqui un “popurri” interesante de cosas que podemos hacer y aplicaciones que podemos
instalar justo despues de acabar la instalacion de Ubuntu 8.10 Intrepid Ibex.
Vamos al grano.

* Instalar software mas rapidamente.
Suele ocurrir (y especialmente) cuando sale una nueva version de Ubuntu, que los repositorios desde los
cuales nos solemos descargar software estan muy saturados.
Si queremos descargar e instalar el software mas rapidamente, tendremos que modificar la lista de repositorios.
Existe una opcion de Synaptic, que nos permite seleccionar un servidor mas cercano a nuestra region.
Para cambiar este servidor a uno mas cercano vamos a Sistema > Administracion > Origenes de software
y en la pestaña “Software de Ubuntu”, seleccionamos “descargar desde:” indicando la region mas cercana
a la nuestra.

* Instalar el software basico de compilacion
Si queremos compilar algun paquete del que solo tenemos el codigo fuente, tendremos que instalar los paquetes
basicos de compilacion. Lo instalamos con:

$ sudo aptitude install build-essential

y a partir de entonces ya podemos compilar.

* Instalar los extra restrictivos.

Hay ciertos paquetes que no vienen por defecto en Ubuntu por cuestiones legales.
Cuando se instala ubuntu, por defecto y debido a un tema de licencias no instala
todo ese software comercial que no ha liberado el codigo fuente, como por ejemplo puede ser
el plugin de flash, o los codecs para poder reproducir algunos formatos de video.
Existe un metapaquete (un paquete que agrupa e instala muchos mas paquetes)
llamado ubuntu-restricted-extras que nos permite
instalar todo este software que no es instalado por defecto.
Tras habilitar los repositorios universe y multiverse podemos instalar este metapaquete con:

$ sudo apt-get install ubuntu-restricted-extras

Los paquetes serian:

kubuntu-restricted-extras – Commonly used restricted packages
ubuntu-restricted-extras – Commonly used restricted packages
xubuntu-restricted-extras – Commonly used restricted packages

Para Instalar flash player, nos pueden interesar los siguientes paquetes:

flashplugin-nonfree – Instalador del complemento de Adobe Flash Player
flashplugin-nonfree-extrasound – Reproductor de Flash de Adobe compatible con las bibliotecas Esound y OSS

$ apt-get install flashplugin-nonfree libflashsupport flashplugin-nonfree-extrasound

Otra opcion es añadir:

* el repositorio mediubuntu para Intrepid:

mediubuntu es un repositorio donde podemos encontrar algunas aplicaciones y codecs que no son instalador por defecto en intrepid, Para instalarlo:

Agregamos el repositorio:
sudo wget http://www.medibuntu.org/sources.list.d/intrepid.list –output-document=/etc/apt/sources.list.d/medibuntu.list

Agregamos la llave GPG
sudo apt-get update && sudo apt-get install medibuntu-keyring && sudo apt-get update

y tras actualizar ya podriamos instalar software desde synaptic como:

* libdvdcss2 – Para la reproducción de DVD.
* non-free-codecs – Para el resto de codecs propietarios.
* acroread – Acrobat Reader
* mozilla-acroread – para ver pdf dentro de Linux

o

* skype – cliente de mensajeria

entonces ya podemos:

* Instalar Mplayer con todos los codecs y soporte de DVD
Si queremos reproducir peliculas con Mplayer ejecutamos:

$ sudo apt-get install mplayer

Para instalar una libreria que te permite ver los DVDs encriptados

sudo apt-get install libdvdcss2 libdvdread3

o algunos codecs windows:

Para i386:

$ sudo apt-get install w32codecs

Para amd64:

sudo apt-get install w64codecs

* Instalar Avant Window Navigator

AWN es un dock similar al de Mac, que nos permite lanzar aplicaciones desde una barra con iconos que se instala en nuestro escritorio. Lo instalariamos con:

apt-get install avant-window-navigator

una vez instalado accedemos al programa desde
Aplicaciones > Accesorios > Avant Window Navigator
podemos cambiar sus preferencias desde Sistema > Preferencias > Awn manager

para tener un dock similar al de Mac, puedes bajarte este tema para Awn.

* Instalar Sun Java Runtime Environment

Si queremos instalar java para poder ejecutar aplicaciones basadas en Java o tener el plugin de Java para el navegador,
ejecutamos:

$ sudo apt-get install sun-java6-fonts sun-java6-jre sun-java6-plugin

* Instalar Microsoft fonts package
Si queremos utilizar algunas de las fuentes de texto de Microsoft como por ejemplo son:

* Andale Mono
* Arial Black
* Arial (Bold, Italic, Bold Italic)
* Comic Sans MS (Bold)
* Courier New (Bold, Italic, Bold Italic)
* Georgia (Bold, Italic, Bold Italic)
* Impact
* Times New Roman (Bold, Italic, Bold Italic)
* Trebuchet (Bold, Italic, Bold Italic)
* Verdana (Bold, Italic, Bold Italic)
* Webdings

Ejecutamos:

$ sudo apt-get install msttcorefonts

y despues

$ sudo fc-cache

para reiniciar la cache de fuentes del sistema. a partir de ahora tenemos disponibles esas fuentes
de texto para poder usarlas con nuestros programas favoritos.

Si acaso no tuvieramos Firefox, podemos instalar la version 3.0 con:

$ sudo apt-get install firefox-3.0

* Instalar adobe reader
Para leer documentos PDF, si estamos mas acostumbrados a usar el Adobe reader,
y no queremos usar el visor interno del propio Gnome, podemos instalar este visor con:

$ sudo apt-get install acroread

* aMSN
Tienes amigos con los que quieres hablar mediante el Msn???. Podras seguir conversando con ellos
si instalas este cliente de mensajeria:

$ sudo apt-get install amsn

* amule
Emule, es uno de los programas P2P mas populares para descargar por internet. La version en Linux se
instala con:

$ sudo aptitude install amule

* reproducir videos, VLC
VideoLan VLC es uno de los mejores reproductores de video. Lo puedes instalar con:

$ sudo apt-get install vlc

* reproducir videos, Smplayer

Otra alternativa a VLC para visualizar videos:

$ sudo apt-get install smplayer

* Apagar el altavoz interno del PC
si te molesta una forma de hacerlo es deshabilitarlo con el comando:

$ sudo modprobe -r pcspkr

puede volver a activarse con:

$ sudo modprobe pcspkr

* Que no se muestren las unidades en el escritorio
Si quieres que no te aparezcan los iconos con las particiones que tienes en tus discos puedes
ocultar los iconos ejecutando:

$ gconf-editor

se abrira el editor del registro. entocnes debes buscar la cadena “volumes_visible” en
apps/nautilus/desktop Puedes activar o desactivar esta opcion para mostrar
los iconos de tus volumnes.

* Eliminar kernels antiguos
Ya se encarga de ello Intrepid. Genial.

* Instalar wine

Si tienes alguna aplicacion para Windows que uses y no esta disponible para Linux, es posible que
puedas ejecutarla con wine.

Ejecutas:

para obtener la version estable:
$ apt-get install wine

si quieres la mas nueva:

Añade el siguiente repositorio:

$ sudo wget http://wine.budgetdedicated.com/apt/sources.list.d/intrepid.list -O /etc/apt/sources.list.d/winehq.list

Actualizamos el sistema:

$ sudo apt-get update

y ya instalamos wine:

$ sudo apt-get install wine

Despues ejecutamos:

$ winecfg

Para configurar Wine.

Si ademas queremos una apariencia grafica de wine que este mas de acorde con Ubuntu hacemos:

$ gedit ~/.wine/user.reg

Y remplazamos la seccion [Control Panel\\Colors] con:

[Control Panel\\Colors] 1176981676
“ActiveBorder”=”239 235 231″
“ActiveTitle”=”203 133 61″
“AppWorkSpace”=”198 198 191″
“Background”=”93 77 52″
“ButtonAlternativeFace”=”200 0 0″
“ButtonDkShadow”=”85 85 82″
“ButtonFace”=”239 235 231″
“ButtonHilight”=”255 255 255″
“ButtonLight”=”255 255 255″
“ButtonShadow”=”198 198 191″
“ButtonText”=”0 0 0″
“GradientActiveTitle”=”239 235 231″
“GradientInactiveTitle”=”239 235 231″
“GrayText”=”198 198 191″
“Hilight”=”246 200 129″
“HilightText”=”0 0 0″
“InactiveBorder”=”239 235 231″
“InactiveTitle”=”239 235 231″
“InactiveTitleText”=”255 255 255″
“InfoText”=”0 0 0″
“InfoWindow”=”255 255 166″
“Menu”=”239 235 231″
“MenuBar”=”239 235 231″
“MenuHilight”=”246 200 129″
“MenuText”=”0 0 0″
“Scrollbar”=”239 235 231″
“TitleText”=”255 255 255″
“Window”=”255 255 255″
“WindowFrame”=”0 0 0″
“WindowText”=”0 0 0″

(original de http://www.ubuntumini.com/2008/10/installing-wine-in-ubuntu-810-intrepid.html)

Tambien podemos instalar winetricks para poder añadir muchas DLLs que usa Wine de manera
facil.

* Personalizar las animaciones y efectos de Compiz

Si quieres poder seleccionar de manera sencilla que animaciones y efectos deseas activar en compiz
nada mejor que instalar su administrador:

$ sudo apt-get install compizconfig-settings-manager emerald

y no te olvides de fusion-icon:

sudo apt-get install fusion-icon

Se añadira un icono al panel que te permitira acceder muy rapidamente a todas las opciones
de Compiz.

Entonces ya podremos acceder al administrador de Compiz desde: Sistema > Preferencias > Configuracion avanzada de los efectos de escritorio y al gestor Emerald desde Sistema > Preferencias > Gestor de Temas de Emerald

Cuando hagas esto y si usas Compiz y usas Emerald como decorador de ventanas, es posible que los bordes se vean mal o que no te cargue directamente Emerald cuando inicias sesion.
Para solucionarlo vas a “Configuracion avanzada de efectos de escritorio” y en el plugin “Window Decoration”
debemos cambiar el apartado “Command” por esta linea:

/usr/bin/emerald –replace

* Instalar Eclipse

Yo como desarrollador de Java tambien incluiria un editor como Eclipse para hacer mis programas:
$ apt-get install eclipse

o

$ apt-get install eclipse-gcj

si quiero ejecutar la version de Eclipse que corre con GCJ.
haz:

$ sudo apt-cache search eclipse
y podras ver todos los plugins adicionales que puedes instalar, p.ej para programar en python o Php
usando eclipse.

Tambien si te gusta mas, puedes usar netbeans:

$ apt-get install netbeans

Si tenemos problemas con la grafica:

* Envy para poder instalar tu tarjeta de video:

$ sudo apt-get install envyng-gtk envyng-core

y lo inicias con
$ envyng

Si queremos un buen capturador de pantallas:

$apt-get install gscrot

Si queremos poder ir cambiando el fondo de pantalla periodicamente:

$ sudo apt-get install drapes

Ir luego a sistema->preferencias->sesion y añadir drapes–tray.

* Si cuando inicias no tienes activo el teclado numérico y quieres que al arrancar esté por defecto activado:

$ sudo apt-get install numlockx
$ numlockx on

* Compresores/Descompresores adicionales

$ sudo apt-get install unrar rar p7zip-full unace unzip

Si queremos tener una maquina virtual para poder por ejemplo ejecutar Windows XP u otro
sistema operativo desde Ubuntu, instalariamos VirtualBox.

* Instalar VirtualBox:

$ sudo apt-get install virtualbox-ose vboxgtk virtualbox-ose-guest-utils

nos permite instalar el VirtualBox-OSE, o

$ apt-get install virtualbox-2.0

pero este ya no es “libre”.

Si queremos widgets en el escritorio, usamos screenlets:

* Instalar Screenlets:

sudo apt-get install screenlets
lo iniciamos con:
screenlets-manager

Ibex no incluye la ultima version de OpenOffice 3.0 sino la 2.4, pero podemos instalarlo y sustituir la actual.

* Instalar OpenOffice 3.0:

Solo tenemos que añadir estas líneas a los repositorios, editamos el /etc/apt/sources.list y añadimos:

#Openoffice
deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu intrepid main
deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu intrepid main

Actualizamos la informacion de los repositorios:

sudo aptitude update

Y deberán aparecer lista las nuevas actualizaciones.

Si por algún caso no aparecieran solo tenemos que ir hasta Sistema/administración/gestor de actualizaciones.

Se instalara en ingles, para traducirlo instalamos:

$ sudo aptitude install openoffice.org-l10n-es language-support-translations-es language-support-writing-es myspell-es

Incluso podemos cambiarle su pantalla de Splash:

copiariamos los archivos a /usr/lib/openoffice/program/intro.bmp
pero renombrandolos a:
openabout_ubuntu_sun.bmp y openintro_ubuntu_sun.bmp

* Si queremos cambiar el grub y el splash:

$ sudo apt-get install startupmanager

Podemos instalar un buscador y lanzador rapido de aplicaciones:

$ apt-get install gnome-do

Para descargarnos ficheros podemos usar:

JDownloader

y para videos de Youtube:

xviservicethief

Pero hay aun muchas mas y esta lista podria crecer. ¿Que mas incluirias tu?

The GeeXboX team members finally met at FOSDEM this weekend at Brussels, Belgium. It was a big pleasure finally meeting everyone IRL.

Attending members, from left to right: Aurélien Jacobs, Nicolas Aguirre, Guillaume Lecerf, Davide Cavalca and Benjamin Zores. Mat and Andrew were not able to join but it still was a very nice weekend.

Hello,

plusieurs grabbers ont intégrés Valhalla depuis le dernier article, merci à Benjamin pour son travail. Il reste cependant quelques lacunes à combler. Certaines des fonctionnalités manquantes sont mineurs et je ne vais donc pas les aborder ici. Même que je ne compte pas travailler dessus tant que les plus importantes ne seront pas implémentées.

Scan “on-demand”

C’est sûrement une des fonctionnalités la plus importante à faire avant l’intégration dans Enna. Son rôle est de permettre la récupération des méta-données en priorité (sur demande). L’idée est très simple, lorsque vous utilisez Enna et ciblez un fichier en particulier, le rôle du “on-demand” sera de fournir toutes les données le plus rapidement possible pour ce fichier. A moins que ces données soient déjà récupérées et sauvées dans la base de données (ainsi que les fichiers téléchargés tel que les couvertures).

Bien que l’idée soit simple, l’implémentation est bien plus complexe. Valhalla étant un scanner de répertoire, il n’y a actuellement aucun mécanisme pour donner une priorité plus importante à un fichier plutôt qu’un autre. Comme je l’explique dans l’article précédent, les tâches des threads de Valhalla fonctionnent selon le principe du premier arrivé, premier servi. Il faut donc implémenter un moyen de mettre “un paquet” selon un LIFO (Last In, First Out) à la place d’un FIFO. Par exemple un attribut indiquerait que le paquet est prioritaire et les queues seraient utilisées en LIFO.
Les queues dans Valhalla sont héritées de libplayer. Elles se nomment fifo_queue et n’ont pas du tout été prévues pour le LIFO comme le suggère leur nom. Il est peut être temps de les rendre plus polyvalentes. Je n’ai encore rien entrepris en ce sens, je ne fais que des réflexions sur une manière parmi d’autres de gérer le “on-demand”.

Donner plus de priorité dans les queues ce n’est pas l’unique chose à prendre en compte. Le “on-demand” doit aussi pouvoir se faire sur des fichiers qui ne sont pas disponibles avec les chemins scannés par Valhalla. Ce qui induit que ces entrées doivent avoir un statu particulier dans la base de donnée, afin que Valhalla ne les supprime pas lors du prochain scan, croyant que se sont des fichiers effacés car introuvables. Quoi qu’il en soit, avant d’écrire la moindre ligne de code, il est important de faire toutes les considérations nécessaires afin de ne pas introduire des modifications trop intrusives aussi bien au niveau interne de Valhalla qu’au niveau de la structure de la base de donnée.

Le “force-stop”

Depuis la première version de Valhalla, il est possible d’arrêter un scanner (et donc tous les threads en aval) même si le système est en train de travailler sur des fichiers à différents niveaux. Le fait d’avoir ajouté les grabbers à fortement compliqué cette fonctionnalité de “force-stop” qui n’est actuellement pas optimale. J’ai du faire un choix afin de pouvoir commiter le code sur les grabbers même si je n’ai pas terminé cette part du travail.

Mais tout d’abord, pourquoi le “force-stop”? Lorsque vous êtes dans Enna, Valhalla tourne en arrière plan avec une priorité très basse afin de ne pas influencer l’interface et les lectures des fichiers. Si vous quittez Enna, vous voulez le faire immédiatement ce qui semble logique. Par contre pour Valhalla c’est plus compliqué. L’arrêter en plein au milieu de tâches l’oblige à ne pas pouvoir vider les queues des threads. Toutes les données dans ces queues sont donc libérées et perdues. Avant l’ajout des grabbers ce n’était pas du tout un problème, car le système se limitait à une seule étape; le parser. Un thread n’est pas tué avec le “force-stop”, mais sa dernière tâche est terminée normalement. La différence est que les tâches suivantes sont ignorées et le thread se termine comme s’il n’y avait rien de plus à faire. Ainsi avant l’ajout des grabbers, au pire les fichiers restant dans les queues n’étaient pas insérés/actualisés dans la base de donnée. Les fichiers qui étaient déjà insérés l’étaient au complet. Ceux qui ne l’étaient pas, ne l’étaient pas du tout. C’était du tout ou rien. Le prochain scan (démarrage d’Enna) permettait de continuer le travail très simplement. Les queues se repeuplaient par le scanner qui ne trouvait pas les fichiers dans la base de données, et ignorait ceux qui existaient déjà (c’est toujours le cas “plus-ou-moins” si vous compilez Valhalla sans les grabbers).

Depuis que les grabbers sont présents, la complexité du “force-stop” a augmenté pour deux raisons. Un fichier peut exister dans plusieurs queues en même temps, et un fichier doit passer par plusieurs étapes avant d’être terminé. Les données d’un fichier dans la base de donnée ne peuvent plus être considérées comme du tout ou rien. Un fichier se retrouve complètement fragmenté quand les threads sont tous terminés en plein au milieu des tâches.

Fonctionnement actuel

J’ai donc fais un choix intermédiaire pour que Valhalla fonctionne aussi en “force-stop” bien que le problème de fragmentation ne soit pas réglé. J’ai décidé de traiter un fichier comme c’est le cas sans le support des grabbers mais à une différence près. Un fichier est considéré comme interrompu tant qu’il n’a pas atteint l’étape ENDING (voir l’article précédent). Donc au prochain scan (redémarrage de Valhalla), ce fichier repassera absolument par toutes les étapes. Le problème est donc que les données déjà grabbées (et sauvées dans la DB) sont re-grabbées ce qui prend beaucoup de temps inutile. Avec des milliers de fichiers et beaucoup de grabbers, il se trouve que Valhalla passe son temps à refaire encore et encore le même travail si on ne le laisse pas se terminer de lui même. Car pour qu’un fichier puisse atteindre l’étape ENDING quand il y a 5-6 grabbers, il faut se lever tôt .
Ce système est provisoire! Il est là en attendant que j’y travail. Et c’est une des raisons qui fait que Valhalla ne doit pas encore être utilisé avec les grabbers dans Enna.

Pourquoi de la fragmentation? Alors ça n’a rien à voir avec votre disque dur, quand je parle de fragmentation c’est dans le sens où toutes les informations qui devraient l’être ne sont pas disponibles dans la base de donnée. Par exemple un fichier est passé par l’étape PARSING et GRABBING (le premier grabber). Les méta-données du parser ont été sauvées dans la DB, ainsi que celle du premier grabber par exemple. Néanmoins il y a peut être encore 4 grabbers avant le downloader et l’ENDING. Le “force-stop” arrête tout, vide les queues, quitte Valhalla. Il se trouve que le fichier en question a une partie des méta-données dans la base de donnée, mais on a aucune certitude qu’elle soient toutes disponibles car ce fichier est indiqué comme étant interrompu.

Fonctionnement futur

Je suis en train de réfléchir à ce problème (sur papier pour le moment). Ce qu’il faut arriver à faire, c’est de sauver le contexte des fichiers interrompus pour pouvoir restaurer leur contexte à la prochaine exécution de Valhalla. Il n’y a donc pas 50 manières de faire. La sauvegarde du contexte doit être réalisée dans la base de donnée. Un mécanisme à l’exécution de Valhalla devra chercher les contextes, les restaurer puis les effacer de la base de données.

Un contexte devra contenir les informations sur quels grabbers ont été traités en entier (ceux où les données sont vraiment sauvées) ainsi que la liste des fichiers qui doivent être téléchargés. Il faut aussi considérer les cas où des contextes ont été sauvés mais que certains grabbers ne sont plus disponibles avec Valhalla, ou même qu’un Valhalla sans le support des grabbers essaient d’utiliser la base de données qui contient ces contextes.

Concernant le downloader c’est un peu différent par rapport aux autres threads. Comme je l’ai dis précédemment, un thread termine sa tâche en cours puis quitte. Pour le downloader une tâche peut être interrompue en plein au mieux. Cela veut simplement dire que pour un fichier en particulier, il y a par exemple un “cover”, un “backdrop” et peut être encore autre chose à télécharger. Il se peut que le “cover” soit téléchargé, que le “force-stop” se manifeste et donc le “backdrop” est ignoré. La tâche est à moitié réalisée. Il est donc nécessaire de sauvegarder l’état de cette tâche avant de quitter le thread du downloader.

Finalement ça représente des ajouts de tables dans la base de données pour sauvegarder les contextes, des mécanismes pour gérer les contextes (sauvegarde, restauration et effacement), puis ensuite on pourra réfléchir sérieusement à l’intégration dans Enna.

Les évènements

Le dernier point relativement important est la gestion des évènements pour un scan “on-demand”. Les données étant insérées au fur et à mesure dans la base de donnée, il est intéressant de recevoir une information sur ce qui est disponible afin de savoir quand aller les lire. Simplement, lorsque vous êtes sur un fichier en particulier avec Enna, un “backdrop” va se télécharger à un moment indéterminé. Un évènement sera envoyé par Valhalla à Enna quand le fichier sera sauvé et le “backdrop” s’affichera.

C’est avant tout une question de confort que d’avoir cette fonctionnalité. Dans le cas contraire il serait nécessaire d’aller lire les données que lors de l’accès au fichier, et les images par exemple ne s’afficheraient qu’en changeant de fichier, puis en revenant sur le précédent (pour autant que quelque chose s’est téléchargé entre temps).

…

Il y a d’autres points mais moins prioritaires. Je compte travailler spécialement sur les trois problèmes présentés dans cet article. J’ai déjà fais un peu de travail sur le “force-stop”. Après je pense régler le “on-demand” puis les évènements.

A bientôt,

Mathieu SCHROETER

Les feuilles d’Yggdrasil ne sont plus si inaccessibles pour les braves de la Valhalla. Les “grabbers” auraient pu s’appeler Heidrun mais on se contentera d’un nom plus technique.

Les “grabbers” sont donc enfin supportés dans libvalhalla. Il y a encore du travail avant de pouvoir les utiliser correctement depuis Enna, mais l’essentiel est là. Pour ceux qui n’ont aucune idée de ce qui se cache derrière ce mot barbare “grabber”, on pourrait le définir simplement comme étant une manière de s’accaparer (si on traduit directement du mot anglais) ou alors de récupérer des données depuis des moyens extérieurs.
Par exemple, libvalhalla peut récupérer des méta-données provenant directement des fichiers scannés, à l’aide d’FFmpeg (le parser). Mais si on désire retrouver la couverture CD/DVD il n’était pas possible de le faire jusqu’ici. C’est là qu’intervient le “grabber” tel que celui pour Amazon. On peut imaginer plein d’autres types de “grabbers”, mais celui d’Amazon est le seul porté sous Valhalla au moment où j’écris ce billet et il permet de “rapatrier” les couvertures CD/DVD.

Architecture

L’architecture de la bibliothèque à été profondément changée. Trois nouveaux threads ont fait leur apparition et sont visibles dans l’image ci-dessous en tant que “Dispatcher”, “Grabber” et “Downloader”.

L’image correspond au code, néanmoins elle est un petit peu simplifiée afin d’être suffisamment lisible et compréhensible. Le Dispatcher peut être vu comme un switch réseau. Son but et d’être très réactif (il ne fait donc pas grand chose) et de transmettre les “paquets” au bon endroit en fonction de l’état de celui-ci. Un “paquet” est une analogie au réseau, mais finalement dans le cas de libvalhalla, ce n’est rien de plus qu’une structure qui défini un fichier.

Afin de bien comprendre l’architecture, je vais détailler le chemin effectué par un paquet. Lorsque le scanner trouve un fichier sur le disque, il “l’empacte” et le transmet au DBManager. Le DBManager va interroger la base de donnée pour savoir si ce fichier existe déjà, si oui il vérifie la date de dernière modification et ignore ce paquet si cette date n’a pas changée, autrement (ou si le fichier n’existe pas dans la base), il transmet le paquet au Dispatcher. Un paquet doit suivre 4 étapes avant d’être détruit.

• Étape 0: PARSING
  Récupération des méta-données à l’aide d’FFmpeg
• Étape 1: GRABBING
  Récupération de nouvelles données et (ou) fichiers texts (XML) à l’aide d’un ou de plusieurs grabbers
• Étape 2: DOWNLOADING
  Téléchargement des fichiers indiqués par le(s) grabber(s) (couvertures CD par exemple)
• Étape 3: ENDING
  Finalisation et destruction du paquet

Le processus pour un paquet se résume donc en:

Scanner -> DBManager -> Dispatcher -> Parser -> Dispatcher -> Grabber -> Dispatcher -> Downloader -> Dispatcher -> DBManager -> Scanner.

Ce qui est faux en réalité, mais l’idée est correcte. L’intérêt de présenter le processus aussi simplement est uniquement là pour permettre de comprendre par la suite comment valhalla fonctionne. Si un paquet suivrait vraiment le processus ci-dessus, le système serait extrêmement lent (j’exagère peut être sur le mot “extrême”) mais il faut garder en tête que travailler avec des grabbers ça ne peut que ralentir, surtout s’il y a beaucoup de grabbers et s’ils font des accès sur internet.

Comme un pipeline

Si le Dispatcher, le Parser, le Grabber et le Downloader sont sur des threads différents ce n’est pas juste pour pouvoir traiter plusieurs paquets en parallèles, mais aussi pour pouvoir traiter un même paquet à plusieurs endroits en même temps. L’idée est donc de récupérer les données “parsées” et “grabbées” aussi vite que possible dans la base de donnée. Ainsi même si un paquet n’a pas finit de suivre toutes les étapes du processus, il est qu’en même possible d’aller chercher les informations dans la base de données.

Pour ceux qui connaissent un peu les architectures des processeurs, ils connaissent également la représentation en pipeline du cycle d’exécution des instructions. J’ai vais donc expliquer le système par un dessin selon ce principe.

Ce pipeline présente 4 fichiers traités par deux parsers parallélisés. Il y a chaque fois deux grabbers en série pour chaque fichier, avec un downloader à la fin du processus.

Les tâches des threads de Valhalla fonctionnent en tant que FIFO (à ne pas confondre avec l’ordonnanceur du noyau). Le premier arrivé est donc le premier servi. Chaque fichier de ce pipeline peut être séparé en deux lignes. C’est ce qui arrive lorsqu’un grabber est en marche et que des méta-données doivent être sauvées dans la base de donnée. C’est cela qui permet d’avoir un temps de réaction intéressant. Il est inutile d’attendre que le processus soit terminé pour avoir les méta-données. Par exemple avec le “FILE 0″, le Scanner (jaune) transmet le paquet au DBManager (rose pâle), qui va le transmettre au Dispatcher (gris) afin d’être “parsé” (rose). Puis le paquet revient au Dispatcher et se voit transféré dans deux threads, le grabber (vert) et le DBManager. A ce moment là il se passe deux choses, le DBManager va insérer les méta-données du Parser dans la base de donnée et en même temps le grabber va commencer à traiter les nouvelles méta-données. Puis au “grabbing” suivant, c’est les méta-données du grabber précédent qui sont sauvées quand le deuxième grabber s’apprête à traiter les nouvelles méta-données. Au final c’est lors de l’étape du downloading que les dernières méta-données sont sauvées.
En résumé, chaque case DBManager (de demi-hauteur) correspond à une insertion dans la base de donnée. Dans le cadre de cet exemple, il y a donc trois insertions par fichier (le parser + les deux grabbers).

J’ai omis quelques informations sinon cet article serait 5 fois plus long.

Il faut également prendre le diagramme avec des pincettes car il est impossible de prédire la forme exacte pour plusieurs raisons. Les cases “parser”, “grabber” et “downloader” en particulier sont très disproportionnées. Leur temps est une question de plusieurs dizaines de millisecondes à plusieurs secondes. Tout dépend de la taille des fichiers, du demuxer utilisé par FFmpeg, de la vitesse de votre connexion internet, du temps sur les accès aux disque dur, etc, … Le dispatcher se contente de quelques microsecondes, et dans le diagramme il prend autant de temps que le DBManager ce qui est absurde.
Au premier abord on pourrait penser qu’il y a beaucoup de trous dans ce pipeline, mais en réalité les trous sont bien plus grand que ça si vous considérez qu’un parser prend 3 secondes pour un fichier. Néanmoins ce n’est pas du tout un problème (d’ailleurs s’il n’y avait pas de trous alors tous vos CPU seraient constamment à 100%; il ne faut pas oublier non plus que dans certaines étapes il y a des temps morts tel que les accès au disque dur et sur internet).

Si vous regardez bien le diagramme, vous voyez des trous importants après les étapes “parser”. En fait, le scan du disque, le parsing et l’insertion des méta-données des parsers vont se faire très vite. A la même vitesse qu’avant l’ajout des grabbers dans Valhalla. Les grabbers ont aucun impacte sur les parsers car ils sont exécutés après eux. Ce n’est pas plus compliqué que ça.

Il faut également interpréter ce diagramme d’un point de vue plus large. Imaginez le avec plus de 100 lignes (ou plus), ce qui peut arriver sans problème lorsqu’un scanner passe sur un de vos dossiers de musique. Cela donnerait visuellement tous les parsers qui descendraient à gauche en un escalier serré, et les grabbers seraient parsemés (avec des trous importants dans toutes les lignes). Néanmoins il peut y avoir des grabbers non utilisés par certains fichiers, voir même aucun grabber, ce qui complique fortement le diagramme.

Quelques précisions

Il y a de la documentation avec les en-têtes de libvalhalla afin de savoir comment implémenter un grabber, mais je donerais des informations sur ce blog un de ces 4.

L’application test-valhalla permet de tester les grabbers. Il suffit de lire l’aide de la commande.

Valhalla peut être compilé sans le support des grabbers, ainsi les fichiers passent de l’étape 0 PARSING à l’étape 3 ENDING. La bibliothèque réagira exactement comme avant l’ajout des grabbers.

Il manque également  des éléments pour une utilisation dans Enna, le fichier TODO vous en dira plus.

Voilà, je n’ai pas la motivation d’en dire plus aujourd’hui, rien que de dessiner le pipeline ça m’a pris pas mal de temps. Je reviendrais donc sur certains aspects dans un prochain billet.

A bientôt,

Mathieu SCHROETER

Hello,

cet été j’ai bossé un peu sur libvalhalla pour ajouter le support des grabbers. Le travail n’est pas terminé et rien n’a encore été commité car les modifications sont très intrusives et forment un tout. Je n’ai encore rien à présenter de concret mais j’espère en terminer avec ça les deux premières semaines d’août. Soit mes deux dernière semaines de congé.

La liste de lecture

Mais ce n’est pas de Valhalla que je désire parler. Mais plutôt de libplayer et de quelques fonctionnalités qui existent depuis bien longtemps et qui ne sont pas forcément connues et qui ne seront même jamais utilisées par Enna. Avant l’entrée en jeu d’Enna dans le monde de GeeXboX il y a eu quelques tentatives de nouveaux GUI tel que MPUI, OMCv1, OMC-SDL puis OMCv2. Aucun de ces projets n’a abouti mais libplayer a été créé en parallèle à OMCv1 (je précise v1 et v2 car il y a eu deux tentatives différentes de créer un GUI basé sur les EFL). Pendant une période, il avait été proposé de laisser la gestion des listes de lecture à libplayer. Au début cette gestion était très rudimentaire et ne permettait que d’ajouter des fichiers dans la liste. J’ai donc pris l’initiative d’étendre la gestion de ces listes, et spécialement avec l’ajout du superviseur (cf. libplayer-et-le-multi-threading) qui date d’une année.

Libplayer contient une playlist interne. Elle n’est pas accessible depuis l’API publique et uniquement une playlist peut exister dans un player à la fois. Cette liste se présente en une structure chaînée dans laquelle il est possible de progresser en avant ou en arrière. Cela implique que l’ordre d’insertion des fichiers défini l’ordre de lecture. Ainsi il existe deux manières de lire la liste. Pour cela il m’est nécessaire de présenter quelques fonctions de l’API publique, ainsi qu’une fonction interne un peu différente.

Chaque entrée dans la playlist est un morceau de la structure chaînée, visible en tant que type opaque nommé mrl_t. Il y a quelques fonctions de base pour travailler avec ces type, tel que mrl_new(), mrl_free() et différents accesseurs. Mais il y a également des fonctions pour assigner un mrl_t à la playlist. Tel que player_mrl_set() et player_mrl_append() qui permettent d’insérer un mrl à l’emplacement courant, respectivement à la suite du mrl courant. Ainsi une série de player_mrl_append() vont permettre de remplir la liste de lecture. L’ordre d’insertion étant directement lié à l’ordre de lecture. Il existe également des fonctions pour supprimer des mrls tel que player_mrl_remove() et player_mrl_remove_all().
Tout ceci n’est qu’une présentation rapide de quelques fonctions de base. Certaines d’entre elles sont utilisées par Enna car il faut bien au moins assigner un mrl_t à libplayer pour qu’un fichier (url, dvd, …) puisse être lu. Mais il existe d’autres fonctionnalités pour effectuer des lectures automatisées de la liste de lecture. Ces fonctions n’ont aucun intérêt pour Enna qui gère déjà ses propres listes de lecture.

Les fonctions de playback

Il y a trois fonctions de playback intéressantes pour la liste de lecture de libplayer.

• player_set_playback()
  Deux modes peuvent être défini, soit PLAYER_PB_SINGLE ou PLAYER_PB_AUTO. Dans le cas de “single”, seul le mrl en cours sera lu lors d’un appel à player_playback_start(). Le mode “auto” va permettre à libplayer de lire toute la liste de lecture sans une intervention de l’extérieur. A chaque morceau qui se termine, libplayer va passer au suivant jusqu’à atteindre la fin de la liste.

Le fait de lire la liste depuis la position courante jusqu’à la fin n’est pas toujours très intéressant, il existe donc deux fonctions qui sont très souvent présentes dans ce type de logiciel.

• player_set_loop()
  Pour autant que le mode est en “auto”, il est possible de dire à libplayer de répéter le même morceau un certain nombre de fois avec PLAYER_LOOP_ELEMENT, ou alors de répéter la liste de lecture avec PLAYER_LOOP_PLAYLIST. Un paramètre de cette fonction permet de dire combien de fois et si ce paramètre est négatif, le bouclage est infini.

• player_set_shuffle()
  Ici aussi, le mode de playback doit être “auto”. Ainsi la liste de lecture sera mélangée et le morceau lu suivant sera différent de l’ordre d’insertion des morceaux dans la liste de lecture. Chaque activation et désactivation du “shuffle” va réinitialiser la liste de lecture et donc mélanger l’ordre.

Bien sûr il est possible de combiner les fonctionnalités. Si le “loop” est indiqué sur PLAYER_LOOP_PLAYLIST et que le “shuffle” est activé, chaque fois que libplayer arrive à la fin de la liste de lecture, il la mélangera à nouveau et recommencera autant de fois qu’il a été spécifié avec player_set_loop().
Vous vous dites qu’il n’y a rien d’exceptionnel la dedans, vous avez tout à fait raison. Mon but est uniquement de présenter quelques fonctionnalités exploitables partiellement que par un seul outil “test-player” et forcément ignorées d’Enna. Lorsque test-player est lancé, il suffit d’utiliser [#] pour changer de mode, [.] pour changer le bouclage (il y a quelques valeurs prédéfinies) et [,] pour mélanger la liste.

L’automatisation de la lecture

J’ai parlé au début d’une fonction un peu différente. Cette fonction permet de rendre possible la lecture bouclée et mélangée. Mais avant ça un petit peu de théorie sur libplayer. Bien qu’il n’y a à priori rien d’exceptionnel d’automatiser la lecture dans libplayer, il faut qu’en même se poser une question. Le fait d’automatiser la lecture présage l’existence d’une boucle. Ainsi lorsqu’un fichier est lu en entier (donc un événement du type EOF est généré) il faut forcer le passage au morceau suivant d’une manière ou d’une autre.

Imaginons que le playback a été défini en “auto” et que la lecture a été amorcée via player_playback_start(). Cette fonction de start ne doit en aucun cas être bloquée jusqu’à la fin de la lecture. La chaîne d’exécution peut se visualiser ainsi:

démarrage de la lecture -> sélection du morceau -> lecture -> événement de fin de lecture -> sélection du morceau suivant -> lecture -> etc, …

Il y a une rétroaction et ça complique grandement les choses. Le premier démarrage de la lecture est amorcé à l’extérieur via l’utilisateur et cette fonction n’est pas bloquée jusqu’à l’EOF (en réalité elle bloque jusqu’à ce que la lecture soit réellement lancée). Donc le programme qui utilise libplayer peut faire autre chose en même tant que le média se lit. Il est donc nécessaire d’intercepter la fin de la lecture à l’intérieur de libplayer pour que se sois la bibliothèque qui passe au morceau suivant. Le problème n’est peut être pas tout de suite évident, alors détaillons la chaîne.

Lorsque la lecture se termine un événement est créé, il est ensuite envoyé dans un callback interne (pour que libplayer sache que la lecture est terminée) et se callback envoi l’événement à un callback externe (pour que l’utilisateur de la lib soit aussi informé). Si depuis ce callback interne, un nouveau player_playback_start() serait amorcé, le callback serait bloqué tant que la lecture n’a pas réellement commencé. Et dès que celle-ci démarre vraiment, la fonction est relâchée. De ce fait, le callback interne resterait bloqué par le player_playback_start() pendant tout ce temps (si c’est un flux réseau, ça peut prendre quelques secondes). Les événements qui arriveraient entre le EOF et la fin du nouveau start s’empileraient et ne seraient pas envoyés. Ainsi des événements périmés arriveraient à l’utilisateur après le start et ce n’est pas acceptable.

En réalité c’est encore un peu plus compliqué que ça, mais il est inutile d’aller dans les détails.

Le superviseur et le gestionnaire d’événement de libplayer permettent donc de gérer se problème. Lorsqu’un événement est envoyé, il est empilé dans un FIFO. Les événements sont prioritaires et le superviseur est désactivé lorsque l’un d’eux survient. Ainsi il ne peut jamais y avoir d’événements périmés. La deuxième chose concerne le superviseur en lui même. Il met à disposition deux moyens pour exécuter une commande tel que le player_playback_start() par exemple. Le premier est le mode WAIT, et le second NO_WAIT. La différence est que le premier est utilisé pour toutes les fonctions publiques. Cela veut dire que tant que la fonction n’est pas terminée (par exemple tant que le start n’a pas réellement commencé), l’utilisateur est bloqué. Le second mode permet de lancer une fonction mais sans aucune attente. Par exemple le start serait empilé dans le FIFO du superviseur mais n’attendrait pas. Ce mode n’est pas autorisé depuis l’API publique pour plusieurs raisons, dont une très importante. Lorsque l’utilisateur utilise la bibliothèque il doit être sûr que la commande soit effectivement exécutée afin d’avoir un comportement “normal” donc comme s’il n’y avait pas de parallélisme. Quand vous faites par exemple un printf(), vous voulez que celui-ci s’exécute à ce moment là et pas 2 secondes plus tard. Sinon dans le cas de libplayer, vous feriez un start, puis autre chose, un stop, get_property, etc,..  Sans savoir quand est-ce que les fonctions seront réellement exécutées. Dit autrement, les fonctions de l’API publique sont toutes synchrones. L’autre mode est asynchrone et demande quelques considérations. Pour les fonctions qui retournent des valeurs par exemple, si l’API publique était asynchrone, il faudrait pouvoir indiquer un callback pour chaque fonction afin d’avoir un moyen de récupérer les valeurs. Cette fonctionnalité n’est pas disponible actuellement.

Mais revenons en à l’automatisation de la lecture. Pour que libplayer puisse passer au morceau suivant sans bloquer le callback du gestionnaire d’événement il doit travailler de manière asynchrone. C’est donc (à l’heure où j’écris ces lignes) le seul endroit où une fonction est utilisée en NO_WAIT (en vérité ce n’est pas tout à fait vrai, mais je vous épargne les autres cas particuliers). Cette fonction se nomme:

• player_mrl_next_play()
  Les fonctions player_mrl_next() et player_mrl_previous() à disposition dans l’API publique permettent de progresser dans la liste de lecture par rapport à l’ordre d’insertion des mrls. La fonction next_play est bien différente. Elle va tenir compte du “loop” et du “shuffle” et est donc un peu plus sophistiquée.

Je n’ai pas rendu accessible cette fonction depuis l’API publique pour aucune bonne raison. Elle peut très bien être utilisée de manière synchrone. Elle est utilisée en asynchrone dans libplayer pour libérer le callback le plus vite possible et donc pour respecter la bonne marche des événements. Le fait que les événements sont prioritaires au superviseur indique aussi que la fonction ne pourra jamais se terminer tant que le gestionnaire d’événement ne redonne pas la main au superviseur. Une fonction forcée en WAIT provoquerait irrémédiablement un deadlock. Autrement dit ce serait le serpent qui se mort la queue (ou qui se mort le FIFO).

Conclusion

Le but de cet article est de montrer une facette peu connue de libplayer. Et que cette bibliothèque est bien plus qu’une simple couche d’abstraction sur MPlayer, xine, VLC et GStreamer. Les rôles du superviseur et du gestionnaire d’événement ne se limitent pas qu’aux cas d’utilisations exprimés précédemment. Il y a de nombreuses autres raisons mais ce n’est pas l’objectif de cet article que d’en parler en détail ici.

A bientôt,

Mathieu SCHROETER