Après mise au propre de certaines parties de gestion de la base de données qui pouvaient poser problème, nous avons relancé la collecte de fichiers, en vérifiant régulièrement l'intégrité des bases de données, ainsi que les rapports dans les fichiers-journaux. Aucun problème sur environ 6000 fichiers, jusqu'à ce que le plantage de base se reproduise à nouveau. Nous avons pu, cette fois, grâce au compte-rendu détaillé des opérations, comprendre ce qui s'était passé : Notre serveur Web est muni de protections pour éviter qu'un ou plusieurs scripts puissent partir dans des boucles infinies et saturer la machine : aucun appel à un script ne peut durer plus de 5 minutes. Au-delà de ce délai, la tâche correspondant au script est automatiquement tuée. Or, un des fichiers que nous avions à traiter était un fichier ZIP, contenant plusieurs fichiers ABC, eux-même contenant chacun plusieurs centaines de morceaux. Cela faisait, dans un seul fichier, plusieurs milliers de morceaux de musique à analyser, indexer, et stocker dans les bases de données. Ce processus prenait plus de 5 minutes, et le script était alors terminé abruptement, alors qu'il était en plein dans l'écriture des divers fichiers des bases de données. Dans ce type de cas, il vaudrait mieux envoyer les morceaux un à un plutôt que tous d'un coup. Ainsi, chaque accès individuel ne serait que d'une fraction de secondes, aucun d'entre eux ne flirtant avec le temps limite attribué à la tâche. En attendant de modifier le programme dans ce sens, nous avons mis en place dans notre script une vérification du temps passé, permettant de quitter proprement lorsqu'on dépasse 3 mn (histoire d'avoir un peu de marge). Ainsi, tous les morceaux contenus dans le ZIP ne seront pas pris en compte, mais la base devrait rester intègre. Nous allons essayer de faire tourner l'indexation pendant ce week-end de trois jours, et voir si tout tient le choc. |
|
|
by Olivier Guillion | | | |
|
Nous avons passé une bonne partie de la journée à tenter de localiser le problème de corruption de la base de données de Kooplet. L'ennui, c'est que cela ne semble se produire que dans de rares cas, après une collecte de plusieurs milliers de fichiers. Nous avons essayé de créer un programme de "stress" de la base de données, avec des milliers de création, redimensionnement et suppression d'éléments, mais cela n'a pas permis de reproduire cette erreur. Nous avons donc relancé une collecte, après avoir truffé notre code de marquage des opérations dans un fichier-journal. Nous espérons ainsi que, si cela se reproduit, nous pourrons nous en servir pour comprendre d'où ça vient. En attendant, nous collectons donc à nouveau, tout en sachant qu'il faudra tout reprendre à zéro lorsque l'erreur aura été supprimée. |
|
|
by Olivier Guillion | | | |
|
Les appels à la lecture de pages et de fichier sur Internet par le crawler ont été rendus non bloquants, même sur Windows. Pour ce faire, un processus indépendant est lancé pour l'envoi de commande et la lecture du résultat sur Internet, et si ce processus ne répond pas au bout d'un délai imparti, il est automatiquement détruit par le processus "père". Malheureusement, un oubli de programmation nous a fait analyser incorrectement quelques centaines de fichiers. Ils seront récupérés au prochain balayage complet de chaque site. Sylvain, en examinant les logs d'accès à son site, nous a fait remarquer que notre robot ne tenait pas compte des indications du "robots.txt" en ce qui concerne les adresses à ne pas balayer. Cela a été corrigé. Il a également signalé que notre robot essayait d'accéder à des pages inexistantes, croyant à tort avoir trouvé des liens sur celles-ci dans les pages déjà visitées. Nous avons donc amélioré cette partie. Nous avons détecté quelques boucles de liens mal résolues (page A qui contient un lien sur page B, qui contient un lien sur page A...). Normalement, cela aurait dû être traité automatiquement par le robot, qui ne devrait jamais passer deux fois au même endroit. Il semble y avoir un problème dans certains cas... |
|
|
by Olivier Guillion | | | |
|
Nous avons terminé de vérifier le système de parcours des pages Web (crawler), repérage et analyse des fichiers musicaux, et conversion de ces derniers en données utilisables par le moteur de recherche. Nous avons reconstitué la liste d'une cinquantaine de sites Web qui avait servi à nos premiers essais, et lancé une indexation de ces sites. Pour l'instant, 4 instances du client d'indexation sont en cours sur un PC sous Windows, une autre est en test sur une machine Linux, et une ou plusieurs autres seront démarrées ce soir sur un PC personnel. Les 3 machines fonctionneront toute la nuit, et nous verrons demain matin ce que ça a donné. Par contre, il s'agit seulement de la collecte des données. Ces dernières sont simplement stockées dans une base de données temporaire, limitée arbitrairement à 10000 éléments (fichiers). Pour les transformer en quelque chose d'utilisable par le système de recherche, il faut extraire de ces données les informations musicales, ainsi que les divers textes. Ceci ne peut se faire pour l'instant qu'à l'aide de nos versions de développement d'Harmony Assistant et PDFtoMusic. Pour éviter que tout s'arrête lorsque 10000 fichiers sont en attente d'analyse, il faut donc théoriquement que suffisamment d'instances de ces versions d'Harmony et PDFtoMusic tournent pour analyser les données plus rapidement qu'elles sont collectées. Il va nous falloir évaluer à l'usage combien de machines devront être mobilisées, et pour combien d'heures par jour. |
|
|
by Olivier Guillion | | | |
|
La nouvelle version du robot d'indexation (crawler) de Kooplet a tourné ce week-end, sur un petit nombre de sites (moins d'une dizaine). Il a indexé ainsi un petit lot de 4000 fichiers. La partie client du crawler demande peu de ressources sur la machine sur laquelle elle tourne, et devrait même pouvoir être lancée depuis une clé USB ou un CD-ROM, car elle ne stocke aucun fichier sur le disque. Ceci nous a permis de vérifier les accès concurrentiels de plusieurs instances de ce client, ainsi que la bonne récupération des données des fichiers musicaux. Cependant, la vérification des doublons (même fichier musical disponible à des adresses différentes du même site) nécessitait des balayages assez longs, nous avons donc mis en place un index croisé pour une recherche plus rapide. Ceci nous a obligé à recommencer le processus d'indexation depuis le début. Cette semaine, nous devrions pouvoir relancer la création de la base définitive. |
|
|
by Olivier Guillion | | |
| |
|
Nous avançons toujours sur le système de balayage des sites. Nous nous sommes heurtés à un problème assez compliqué qui n'avait jamais été résolu convenablement dans la version précédente du "crawler" : certains sites, pour être parcourus correctement, nécessitent un enregistrement de l'utilisateur. C'est le cas notamment de CPDL. Afin d'économiser la bande passante, les visiteurs se voient redirigés aléatoirement vers des sites miroir, ce qui perturbait notre robot. Heureusement, le webmaster de CPDL est également utilisateur de nos produits, il nous a donc aimablement ouvert un compte privilégié afin que nous puissions indexer tous les fichiers à notre guise. Mais la phase de "login" nous a posé quelques problèmes. Le site est un wiki, donc pour éviter que des robots puissent s'enregistrer tout seuls et s'amuser sur les pages, des protections anti-robot ont été mises en place. L'analyse nous a montré qu'elles étaient similaires au système anti-spam de notre blog. Nous avons donc du gérer la prise en compte de cookies multiples, et récupérer des données générées dynamiquement sur les pages de log-in afin que notre robot puisse s'identifier correctement. Cela fonctionne maintenant. Dans un tout autre domaine, nous avons reçu ce matin un e-mail qui nous a fait beaucoup rire. Un utilisateur très soucieux de la confidentialité des échanges sur Internet s'est inscrit à notre liste de diffusion de la lettre d'information. Dans l'e-mail de confirmation de l'inscription, nous terminons par le petit paragraphe suivant : Quote:Note : Afin d'éviter les abus, l'adresse IP de la personne ayant demandé ce message vous est communiquée ici. Il s'agit de : xxx.xxx.xxx.xxx |
| Ceci permet d'éviter qu'un robot automatique, le voisin à qui vous avez rayé la voiture, ou un collègue de bureau un peu farceur n'inscrive votre adresse e-mail à votre insu juste pour rigoler. Avec l'adresse IP, vous pouvez vérifier que l'inscription provient bien de chez vous. Voici donc le mail que nous avons reçu en retour. Je me suis permis d'en modifier légèrement la syntaxe afin que son auteur ne considère pas que nous dévoilons en public des éléments de correspondance privée . Quote:A ma demande d'information concernant vos produits, vous me menacez en me précisant que vous avez mon adresse IP. Je me suis inscrit sans mauvaise intention et en retour, je suis agressé par vous. Pour quelle raison ? Clarifiez votre démarche, vous améliorerez ainsi votre image auprès de vos clients de bonne foi. |
| Si ce monsieur savait qu'à chaque consultation d'une page sur un site, le serveur voyait son adresse IP en clair, je crains qu'il n'en perde d'un coup le sommeil et l'appétit. Les campagnes médiatiques paranogènes sur les dangers d'Internet ont, il semble, fait croire à certains que l'adresse IP était une information secrête, au même titre que le code de carte bleue ou la combinaison de son coffre-fort... |
|
|
by Olivier Guillion | | |
| |
|
Le module serveur et le module client du "crawler" de kooplet sont écrits, et fonctionnels. Le module client est très léger, et consomme une puissance de calcul négligeable (jamais plus de 1% de la puissance CPU). Il devrait pouvoir tourner en tâche de fond sans effet notable. Avant de lancer l'exploration des sites musicaux, il faut d'abord vérifier ces modules en profondeur, afin de s'assurer qu'ils respectent bien les paramètres imposés par les sites visités (fichier robots.txt), et que cette exploration se passe bien. Il faut par exemple éviter les boucles de liens (la page A a un lien sur la page B, qui a un lien sur la page A), et s'assurer que le module client réagit bien lorsque le site qu'il explore n'est pas correctement accessible. La version Windows du Perl ne permet pas de définir un timeout sur les accès Internet, donc un site qui ne répond pas fait boucler le programme indéfiniment. Dans la version Linux, par contre, cela fonctionne... presque. Il arrive en effet que certains accès très lents finissent par bloquer le programme également. Nous n'avons pas pu déterminer exactement dans quel cas, mais c'est assez gênant, car cela nous obligerait à relancer le module client tous les deux ou trois jours en moyenne. Nous prévoyons donc de développer un module d'accès indépendant du corps principal du module, ce qui permettrait d'arrêter son exécution s'il ne répond pas au bout d'un certain temps. Ainsi, le module pourrait fonctionner sans nécessité d'intervention humaine sur n'importe laquelle des deux plateformes. |
|
|
by Olivier Guillion | | | |
|
Avant de relancer l'indexation des sites musicaux par Kooplet, nous avons décidé de reprendre à la base le "crawler", c'est-à-dire le programme qui se balade sur Internet pour repérer les fichiers intéressants. En effet, il avait été programmé assez à la va-vite, et dans sa version actuelle, ne permettait qu'à une seule machine de procéder à ces recherches. Nous lançions donc plusieurs instances du programme sur une seule machine dédiée (tournant sur Linux). La quantité de pages à balayer ne pouvant qu'augmenter au fur et à mesure que de nouveaux sites à indexer seraient découverts, nous avions peur qu'une seule machine, ce soit un peu juste. Nous avons donc repensé l'architecture du crawler : un serveur centralisé (sur kooplet.com) gèrera donc les sites en cours d'exploration, les pages à visiter, les fichiers découverts et en attente de traitement. L'intégralité de ces données sera gérée en utilisant notre système de base de données. Un client léger pourra être lancé sur autant d'ordinateurs que désiré, ces ordinateurs demandant au serveur la page à explorer et lui renvoyant soit les informations sur le contenu des fichier musicaux, soit les liens découverts dans la page Web. On pourrait ainsi envisager, lorsque le besoin s'en ferait sentir, de demander de l'aide à quelques-uns d'entre vous pour explorer l'arborescence des pages Web. Cela pourrait se faire soit au travers d'un petit programme indépendant, soit par une commande privée de MyrScript, directement dans Harmony Assistant. Nous avons également besoin des traitements d'Harmony Assistant, ou de PDFtoMusic, pour transformer les données des fichiers musicaux collectés par le "crawler" en données simplifiées pouvant être utilisées par le moteur de Kooplet lors d'une recherche. Là aussi, nous pourrions faire appel à des utilisateurs volontaires pour nous aider à traiter toutes ces données, par l'intermédiaire d'une commande privée cachée dans ces logiciels. |
|
|
by Olivier Guillion | | |
| |
|
Nous avons donc reçu notre microphone hier, et avons pu procéder à quelques tests. Voici comment nous avons procédé. Dans la pièce la moins résonnante du bâtiment (sous les toits, avec des tentures au plafond qui amortissent les échos), nous avons placé côte à côte: - Un microphone stéréo Sony ECM-MS907 connecté au Creative Nomad Jukebox 3, au travers d'un préampli mono Sound Professionals SP-PREAMP-10. - Le Microphone Blue Yeti, connecté en USB à un ASUS EEE PC équipé d'Audacity. Le sélecteur de type d'enregistrement du microphone est réglé, sauf mention contraire, sur "Stéréo". Nous avons ensuite joué de divers instruments, et avons enregistré simultanément sur les deux systèmes. Voici les résultats au format WAV non compressé, avec un peu de blanc avant et après chacun, afin de pouvoir juger du bruit de fond. On entend parfois quelques bruits de rue et des "cui cui" d'oiseaux. On entend aussi de temps en temps le bruit du disque dur du Nomad qui change de piste . Tout d'abord, trois notes à la flûte (un "tin whistle" irlandais en métal), jouées à 60cm Yeti --- Nomad Trois notes de Glockenspiel, jouées à 60cm Yeti --- Nomad Deux cordes à vide de guitare, jouées à 60cm Yeti --- Nomad Un accord de guitare, arpégé, joué à 30cm Yeti --- Nomad Enfin, nous avons un peu joué avec le Yeti, et notamment avec le sélecteur de type d'enregistrement. Nous avons joué la même chose trois fois, avec trois réglages différents : Yeti, réglage "Stéréo" Yeti, réglage "Omni" Yeti, réglage "Cardioïde" Nous n'avons pas testé la dernière position, destinée à l'enregistrement d'interviews. La position "Omni" (enregistrement d'ambiance) est très proche, dans nos tests, de la position "Cardioïde" (enregistrement d'instrument solo), probablement parce que nous avons joué un son fort, placé en face du micro. Il faudrait effectuer d'autres tests, avec une saisie réelle d'ambiance sonore. En conclusion, pour nos oreilles non expertes, le Yéti possède une bien meilleure dynamique, et un bruit de fond moindre, probablement dû à ses grandes membranes. Il reste assez lourd et encombrant, mais sa connexion directe en USB et l'utilisation d'un ordinateur portable permet un contrôle beaucoup plus fin de l'enregistrement, améliorant ainsi grandement la facilité générale d'utilisation. Pour les enregistrements sans possibilité d'espace ou de préparation, on privilégiera donc une solution légère telle que le Nomad et le petit micro Sony, mais pour les enregistrements d'instruments, où l'interprète est à notre disposition, il sera grandement préférable d'utiliser le Yeti. |
|
|
by Olivier Guillion | | | |
|
|