Skywalker13

Diary of an ex-GeeXboX developer…

Avancement pour les "grabbers" ~ 🇫🇷

Posted at — Aug 23, 2009

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