Skywalker13

Diary of an ex-GeeXboX developer…

Force-stop, on demand, events, 
 ~ đŸ‡«đŸ‡·

Posted at — Oct 11, 2009

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