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é :-P.

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,

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

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

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 :-P, 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

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