Skywalker13

Diary of an ex-GeeXboX developer…

Enna et les Metadata ~ ūüáęūüá∑

Posted at — Apr 3, 2010

Hello,

Depuis plusieurs semaines j’ai passablement baiss√© le rythme sur les projets. D’une part pour cause d’obligations qui ne me permettent pas de passer √©norm√©ment de temps sur GeeXboX et d’autre part parce que depuis octobre √† f√©vrier j’ai pass√© beaucoup de temps sur Enna, libplayer et libvalhalla, et √ßa commen√ßait un peu √† me saturer.

En principe je devrais me concentrer sur le g√©n√©rateur d’ISO. Depuis la branche 2 de GeeXboX, ce pauvre g√©n√©rateur est compl√®tement d√©pass√©. Que se sois les fichiers de configuration qui ont chang√©s, des variables renomm√©es, la disparition des th√®mes du bootsplash et du menu OSD. Bref plein de petites choses qui ensemble font un gros paquet. J’ai qu’en m√™me commenc√© gentiment son nettoyage de printemps. Reste √† trouver aussi la motivation n√©cessaire (comme d’habitude).

Enna et le “ondemand”

Au d√©but de la semaine, j’ai fais quelques petites modifications sur libvalhalla. Puis en re-testant sous Enna, un ancien “probl√®me” m’a ennuy√© plus que d’habitude. C’est un comportement bien connu depuis longtemps mais qui demandait peut √™tre un surplus de motivation pour en venir √† bout. Non pas que c’est difficile √† “corriger”, mais plut√īt que ce n’√©tait pas sp√©cialement int√©ressant √† faire. Du coup j’ai laiss√© train√© depuis des mois. Jusqu’√† cette semaine o√Ļ √ßa m’a particuli√®rement contrari√©. Peut √™tre √©tait-ce juste une mauvaise journ√©e, j’ai donc qu’en m√™me pris le temps de r√©gler cet “inconv√©nient”.

Comme vous le savez (j’esp√®re), Enna utilise libvalhalla pour les m√©ta-donn√©es. Si on ne se fie que sur ce que montre Enna, il y avait un comportement qui donnait l’impression que c’√©tait tr√®s lent √† afficher les m√©ta-donn√©es. Par exemple, vous s√©lectionnez un film et il n’y a pas de backdrop, de titre, etc,‚Ķ Vous pouviez laisser une heure la s√©lection sur le m√™me film, vous n’auriez rien vu s’afficher de plus. La premi√®re r√©action c’est que c’est lent. Mais en r√©alit√© ce n’est pas le cas. Il faut savoir que libvalhalla met √† disposition plus de fonctionnalit√©s qu’Enna en utilise. Une de ces fonctionnalit√© est le “ondemand”. Celle-ci √©tait (jusqu’√† hier) uniquement utilis√©e √† moiti√©.

Le principe (avant):

  1. Vous sélectionnez un film
  2. Enna envoie une requ√™te “ondemand” √† libvalhalla
  3. libvalhalla va faire un certain nombre de choses pour donner plus de priorité à cette demande que pour les fichiers trouvés par le scanner. Et
  4. c’est tout :-)

En fait Enna demandait √† libvalhalla de lui donner en priorit√© les metadata d’un fichier, mais sans aller consulter libvalhalla pour savoir si les metadata √©taient disponibles ou non. Du coup il √©tait n√©cessaire de changer de fichier, puis de revenir sur le pr√©c√©dent pour que √ßa commence √† afficher quelque chose. Bref, c’est √ßa qui m’a √©nerv√© en d√©but de semaine.

En fait libvalhalla peut signaler √† Enna o√Ļ en est le fichier dans les √©tapes que sont le “parsing”, “grabbing” et “downloading”. Mais Enna ignorait compl√®tement ces √©v√©nements.

Le principe (depuis hier):

  1. Vous sélectionnez un film
  2. Enna envoie une requ√™te “ondemand” √† libvalhalla
  3. libvalhalla va faire un certain nombre de choses pour donner plus de priorité à cette demande que pour les fichiers trouvés par le scanner.
  4. libvalhalla envoie l’√©v√©nement “parsed”
  5. Enna l’attrape et remet √† jour certaines metadata (comme le titre par exemple)
  6. libvalhalla envoie un √©v√©nement “grabbed” apr√®s chaque grabber.
  7. Enna l’attrape et remet √† jour certaines metadata (comme le synopsis par exemple)
  8. libvalhalla envoie un √©v√©nement “ended”
  9. Enna l’attrape et remet √† jour une fois pour toute.

Ainsi, on voit apparaitre au fur et √† mesure les informations (√©galement dans le panneau d’informations CTRL+I). C’est bien plus sympathique.

Le fait de s√©lectionner un fichier, indique √† Enna qu’une requ√™te “ondemand” doit √™tre envoy√©e √† libvalhalla, et ce m√©canisme a des effets importants. En passant d’un fichier √† l’autre vous envoyez chaque fois une nouvelle requ√™te “ondemand” (√† noter que la requ√™te n’a aucun impacte si le fichier demand√© est d√©j√† compl√®tement disponible dans la base de donn√©e).

Rappel sur le “ondemand”

La fonction s’utilise tr√®s simplement.

valhalla_ondemand (valhalla_t * handle, const char * path);

On donne le chemin du fichier qui nous int√©resse (qu’il soit r√©f√©renc√© par le scanner ou non). Maintenant imaginons qu’on appel 10 fois cette fonction √† petit intervalle de temps avec des fichiers diff√©rents. Le but du “ondemand” c’est de donner une haute priorit√© √† un fichier ou quelques fichiers. Si vous appelez la fonction pour beaucoup de fichiers, finalement ils deviennent tous “haute priorit√©” et entre eux il n’y a plus de diff√©rence (trop de “ondemand”, tue le “ondemand”). Mais pour comprendre pourquoi, il m’est n√©cessaire de donner plus de d√©tails sur le fonctionnement de libvalhalla.

J’ai d√©j√† donn√© passablement d’explications dans d’autres billets de ce blog, ainsi je vais aller droit au but. Le fait qu’il y ait beaucoup de threads et qu’un “paquet” (donc une structure qui identifie un fichier) peut exister dans plusieurs threads √† la fois (des cas tr√®s particuliers que je ne vais pas expliquer ici); il est difficile de savoir o√Ļ se trouve un fichier √† un moment pr√©cis. Ainsi la requ√™te “ondemand” va endormir tous les threads concern√©s pour pouvoir chercher le fichier pour qui il faut donner une plus haute priorit√©. Et c’est cette action qui a un impacte non n√©gligeable sur libvalhalla. La plupart des threads sont rapidement endormis. Mais certains sont un peu plus r√©calcitrants. Je pense tout particuli√®rement aux grabbers. Il suffit qu’un webservice bloque (probl√®me de connexion), et donc il est n√©cessaire d’attendre le timeout de libcurl jusqu’au moment de pouvoir endormir ce fameux thread. Ce timeout je l’ai mis √† 20 sec. Mais je me t√Ęte presque √† le r√©duire encore un peu (√† noter qu’avec libvalhalla-1 et donc Enna-0.4 les timeouts sont pires car se sont ceux de l’OS et en principe ils sont bien sup√©rieurs √† 20 secondes).

Maintenant imaginez plusieurs “ondemand” √† des intervalles relativement proches et ce foutu webservice qui bloque. Il faut donc patienter sur libcurl. Ce ph√©nom√®ne est visible √©galement √† la fermeture d’Enna. Si les grabbers sont actifs, au moment du “force-stop”; au pire avec Enna-devel vous devez attendre 20 sec sur un grabber. Il serait peut √™tre bien que je permette de param√©trer ce temps directement depuis l’enna.cfg. Actuellement il est en dur dans la configuration pour libcurl de libvalhalla.

Je parle de “timeout”, mais en r√©alit√© c’est un petit peu diff√©rent. C’est le temps maximal autoris√© pour une transmission. Par exemple si un fichier prend plus de 20 secondes √† √™tre t√©l√©charg√©, libcurl va qu’en m√™me l’interrompre √† 20 secondes. Ainsi en utilisant un temps bien trop faible, vous risquez de faire √©chouer b√™tement la plupart des grabbers.

L’id√©al serait de pouvoir forcer libcurl √† interrompre une liaison ind√©pendamment de la valeur du “timeout”. Ca serait particuli√®rement utile lors du “force-stop”.
[EDIT: ce problème a été fixé!]

Autre phénomène

Les threads de libvalhalla communiquent par l’interm√©diaire de FIFO. La haute priorit√© est simplement d’utiliser le FIFO en tant que LIFO le temps du push. Dit autrement, au lieu de mettre le paquet au fond de la pile, on le met directement au-dessus. Ainsi s’il y a plusieurs requ√™tes “ondemand”, chacune d’elle va se remettre au-dessus. Peu importe que la requ√™te a √©t√© fait avant ou apr√®s. Chaque fois qu’un paquet change de thread il se remet au-dessus. C’est un peu comme si tous les paquets “ondemand” se battaient pour la premi√®re place.

Au final, tous les paquets “ondemand” seront trait√©s en priorit√© par rapport au scanner, tout en restant entre eux, sur le m√™me pied d’√©galit√©.

Il reste encore du travail

L’√©tat actuel n’est pas encore parfait. Dans l’activit√© musique, les requ√™tes “ondemand” se font uniquement lorsqu’un fichier est s√©lectionn√© (tout comme pour la vid√©o). Le passage d’un fichier √† l’autre par le biais des boutons pr√©c√©dent/suivant et via l’√©v√©nement EOS (End Of Stream) ne provoque aucun “ondemand”. La raison vient directement de l’impl√©mentation du “mediaplayer”. Les actions ne se font pas dans l’activit√©, mais directement en interne dans le mediaplayer. Et les metadata ne sont pas tout √† fait consid√©r√©es de la m√™me mani√®re entre l’activit√© vid√©o et musique. Pour avoir un “ondemand” plus homog√®ne, il faudrait revoir en profondeur le “mediaplayer” et √©liminer les particularit√©s (ennuyeuses) de chaque activit√©.

A bient√īt,
Mathieu SCHROETER