Mobidique a écritmedoc a écritJ'aimerai bien savoir pourquoi recoll ne trouve pas votre pdf.
Bonjour,
Moi aussi. Le document est en lien dans mon message initial ci-avant.
Désolé, je l'avais sous le nez et je ne le voyais pas... J'ai essayé, et sur ma machine de test, pas de problème, je trouve Descartes. Cela aurait été trop beau.
Mobidique a écrit
Au rayon des petits soucis, j'ai arrêté d'utiliser l'indexation temps réel après des pbs avec mon interface graphique (10.04 amd 64, gnome, macbuntu, indexation sur répertoires réseaux monté en gvfs via gigolo), freeze, perte du gestionnaire de fenêtre ... Je crois que quelque chose de ce type était signalé dans la documentation, je n'établis pas de lien de causalité mais ça ne me le fait plus depuis que j'ai arrêté l'indexation temps réel.
Moi j'établis tout à fait le lien! Ce n'est pas la première fois que le problème est signalé, et cela n'a en soit rien de surprenant: recollindex fait beaucoup d'entrées-sorties et consomme pas mal de mémoire, il est donc facile de comprendre qu'il puisse perturber un système.
Le problème c'est que cela ne le fait pas pour tout le monde, et qu'en particulier, je ne le vois jamais chez moi. j'en suis venu à la conclusion (provisoire j'espère) que cela dépendait de manière complexe d'un choix de facteurs parmi le matériel, la version système, ses paramètres (scheduler etc.), et peut-être les données indexées.
Il y a des gens qui ont signalé une amélioration de la situation en lancant le programme avec ionice pour diminuer sa priorité en I/O: "ionice -c 3 recollindex -m" La prochaine version de recoll fera cela toute seule.
Mobidique a écritJe suis passé en indexation planifiée via le "Planificateur de tâches de GNOME 2.1.1", plus simple que de la ligne de commande. Pendant les 15 min journalières il tire bien sur le proc, mais normalement je ne suis pas là. J'ai une log sur mon bureau que j'efface régulièrement, du coup j'ai pas celle de vendredi, mais cet aprem j'aurais celle d'aujourd'hui. Peut être qu'il ne trouve pas mon fichier pdf parce qu'il ne l'indexe pas, il se plante peut être avant ... Je peux vous fournir cette trace.
Oui, cela m'interesse beaucoup (
jfd@recoll.org).
Une des possibilites qui expliqueraient que le fichier soit indexé par tracker et pas par recoll serait l'absence de pdftotext (qui fait partie de poppler-utils), parce que tracker utilise je crois la librairie. Mais vous signalez par ailleurs que vous trouvez d'autres pdf, donc cela ne colle pas (sauf si les autres pdf sont trouvés par leur nom ?).
Mobidique a écritJ'ai refait des essais grep ne trouve pas la chaine de caractères. J'ai fait des essai avec d'autres chaines dans d'autre pdf et c'est OK. L'outil "Recherches des fichiers" est à la ramasse, il ne me trouve rien même quand grep trouve des choses ...
Dispo pour d'autres test ou info.
@+
Diaporama.pdf ne contient pas de texte "en clair" (essayer avec "strings"), donc grep n'a effectivement aucune chance.
En dehors du log du passage normal de l'indexation (qui nous indiquera si l'indexeur se plante avant la fin), on peut faire qq petits tests individuels sur le fichier.
Essayer "recollindex -i /le/chemin/du/fichier/Diaporama.pdf". La commande demande l'indexation individuelle du fichier, et devrait résoudre le probleme si l'indexeur se plante avant d'arriver là.
Essayer aussi "recollindex -e /chemin/dacces", qui efface le fichier de l'index, suivi du même "recollindex -i". Ceci pourrait corriger une indexation partielle qui ferait que l'indexation ne serait pas réessayée. Mais c'est tiré par les cheveux.
S'il y a des liens symboliques dans les paths du système (ex: /usr/home->/home), utiliser sur la ligne de commandes le même chemin que celui qui est listé dans le "topdirs" de recoll.conf, sinon les commandes "recollindex" ci-dessus ne marcheront pas.
Si possible, mettre le niveau de trace au moins a 4 (dans l'interface, parametres d'indexation) pour ces petits tests, et sauvegarder les traces.
Cordialement,
jf
