un excellent indexeur de fichiers: Recoll

Mobidique · Le 03/10/2011, à 11:59

Contenu de mon recolltrace :

gzip: /tmp/rcltmpUtqclC/.RDataTmp: unknown suffix -- ignored
Killed
RCLMFILT: rclzip : : EOF on input
rclzip : : EOF on input

medoc · Le 03/10/2011, à 12:01

Mobidique a écrit :

medoc a écrit :
J'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 écrit :

Je 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 écrit :

J'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

medoc · Le 03/10/2011, à 12:03

Mobidique a écrit :

Contenu de mon recolltrace :

gzip: /tmp/rcltmpUtqclC/.RDataTmp: unknown suffix -- ignored
Killed
RCLMFILT: rclzip : : EOF on input
rclzip : : EOF on input

On s'est croises...

Il n'y a pas grand chose dans cette trace. Dans l'interface de configuration (parametres indexation), il faudrait positionner un nom de fichier trace, et mettre le niveau au moins a 4.

jf

Mobidique · Le 03/10/2011, à 12:57

medoc a écrit :

Essayer "recollindex -i /le/chemin/du/fichier/Diaporama.pdf"

Ayez, une fois cette commande passée, recoll me le retrouve et me le met même en tête de liste.

Or donc ... s'il ne me le trouvait pas c'est qu'il ne me l'avait pas indexé ? S'il ne me l'avait pas indexé c'est qu'il est arrivé après l'indexation initiale ? Et que les process d'indexation ultérieurs se sont mal passés par exemple ? Je suis tout prêt à confesser des arrêts brutaux à coups de "tuer le processus" aka "kill -9" du fait de mes petits soucis évoqués ci-avant ...

Je refais une indexation à partir de 0 pour partir sur des bases saines ?
Il faudrait ensuite que je trouve un truc pour la mise à jour, soit en temps réel avec ionice soit en périodique.

Merci.

PS : j'ai passé la verbosité à 4.

Dernière modification par Mobidique (Le 03/10/2011, à 12:57)

medoc · Le 03/10/2011, à 13:38

Mobidique a écrit :

medoc a écrit :
Essayer "recollindex -i /le/chemin/du/fichier/Diaporama.pdf"
Ayez, une fois cette commande passée, recoll me le retrouve et me le met même en tête de liste.
Or donc ... s'il ne me le trouvait pas c'est qu'il ne me l'avait pas indexé ? S'il ne me l'avait pas indexé c'est qu'il est arrivé après l'indexation initiale ? Et que les process d'indexation ultérieurs se sont mal passés par exemple ? Je suis tout prêt à confesser des arrêts brutaux à coups de "tuer le processus" aka "kill -9" du fait de mes petits soucis évoqués ci-avant ...

Normalement, il n'y a pas de problème à interrompre un processus recollindex, il reprend la fois suivante là où il s'était arrêté (au parcours de l'arbre près). Par contre, l'arrêt peut prendre un peu de temps, pour finir le fichier en cours, vider les buffers et fermer la base proprement. Avec un kill -9, il y a un risque de se retrouver avec une base Xapian corrompue. Dans votre cas cependant, ce qu'on voit clairement, c'est qu'aucune indexation précédente n'est arrivée jusqu'à ce fichier (puisque recollindex -i a marché). La raison n'est pas déterminée.

Mobidique a écrit :

Je refais une indexation à partir de 0 pour partir sur des bases saines ?
Il faudrait ensuite que je trouve un truc pour la mise à jour, soit en temps réel avec ionice soit en périodique.
Merci.
PS : j'ai passé la verbosité à 4.

Pour repartir, et en avoir le coeur net, et en raison des kill -9, je pense effectivement que le mieux serait de démarrer à zéro: "recollindex -z".

Positionner logfilename à un endroit où il y a de la place, et loglevel à 4, puis le laisser terminer. S'il y a un problème en cours de route, on le verra. Tant qu'on y est, l'exécuter dans un répertoire accessible en écriture, et faire un "ulimit -c 100000" avant de démarrer, pour récupérer un core au cas où il se planterait effectivement (je précise que c'est tout de même peu courant, mais on est peut-être sur la piste d'un vrai bug ).

Par la suite, le choix entre indexation temps réel et en batch est vraiment une question de goût. Personnellement je préfère le batch, et je fais mettre à jour mon "vrai" index une fois par jour par cron (ou équivalent). En parallèle, j'ai une indexation temps réel pour tester, mais elle ne fait jamais des siennes

L'indexation en batch n'est pas pratique pour les gens qui éteignent leur PC la nuit: dans ce cas l'indexation au fil de l'eau peut être mieux. Essayez avec ionice, cela corrigera peut-être le problème. En cas de perturbation, tuer le process, et essayer de lui laisser le temps de sortir (mettons 30 S) avant de l'éradiquer.

jf

piolet · Le 07/10/2011, à 16:50

bonjour à tous
j'utilise l'indexation en temps réel recollindex -m
j'ai téléchargé le fichier Diaporama.pdf avec firefox dans le dossier Téléchargement
recoll ne l'a pas indexé même après plusieurs heures (je recherche dans recoll le fichier Diaporama.pdf et il ne le trouve pas).
J'ai fait un touch du fichier et toujours pas d'indexation.
Ensuite cp Diaporama.pdf Diaporama2.pdf et là Diaporama2.pdf est indexé (Diaporama.pdf toujours pas).

voila pour ma contribution à la résolution du problème.
j'utilise fedora 15 gnome et la version 1.1.5.8 de recoll.

Dernière modification par piolet (Le 07/10/2011, à 16:54)

medoc · Le 07/10/2011, à 18:42

piolet a écrit :

bonjour à tous
j'utilise l'indexation en temps réel recollindex -m
j'ai téléchargé le fichier Diaporama.pdf avec firefox dans le dossier Téléchargement
recoll ne l'a pas indexé même après plusieurs heures (je recherche dans recoll le fichier Diaporama.pdf et il ne le trouve pas).

Ah, merci, ca a l'air d'un bug, je peux le reproduire. Je pense que c'est a cause de la sequence employee par mozilla
- Creer un Diaporama.pdf vide
- Telecharger dans Diaporama.pdf.part
- Probablement rename Diaporama.pdf.part Diaporama.pdf

recollindex n'a pas l'air de detecter le rename. Je vais regarder, et ca devrait etre corrige dans la prochaine version (mais c'est different du probleme de Mobidique et probablement sans lien).

piolet a écrit :

J'ai fait un touch du fichier et toujours pas d'indexation.

C'est normal, recollindex ne surveille pas les evenements qui ne touchent que l'inode, il faut une vraie modification du fichier (cela serait trop cher de reindexer juste parce que mtime a change). echo >> Diaporama.pdf devrait provoquer l'indexation (et peut etre pourrir un peu le fichier ...)

piolet a écrit :

JEnsuite cp Diaporama.pdf Diaporama2.pdf et là Diaporama2.pdf est indexé (Diaporama.pdf toujours pas).

Normal encore, ouf.

piolet a écrit :

voila pour ma contribution à la résolution du problème.
j'utilise fedora 15 gnome et la version 1.1.5.8 de recoll.

Merci, encore un bug pour la liste...
jf

Mobidique · Le 09/11/2011, à 14:56

Après quelques échanges privés avec medoc :

medoc a écrit :

Juste pour vous dire que très probablement le bug que vous constatez est due à une fuite de mémoire après une erreur iconv, qui est supposée être corrigée dans Recoll 1.16 (que vous pouvez éventuellement installer à partir du depot "backports") :
https://launchpad.net/~recoll-backports … ll-1.15-on
Le problème a été identifié chez un autre utilisateur (un patch pour la 1.15 existe), je ne suis pas certain à 100% que ce soit le même bug (puisque nous n'avions pas terminé l'analyse), mais les similarités sont telles que c'est presque certain.

je n'ai pas eu l'opportunité de revenir sur le sujet. C'est désormais chose faite : déclaration du backport dans les sources de logiciels, désinstallation de la version précédente de recoll (1.13), déclaration du backport de xapian dans les sources de logiciels (sinon recoll ne s'installait pas), nouvelle indexation : le process tourne jusqu'au bout et je trouve mon document contenant le mot "Descartes".

Merci encore pour le job !

Mob'.

Mobidique · Le 10/11/2011, à 13:46

La logithèque ubuntu aka Ubuntu software center marche plus Elle s'appuie aussi sur xapian, je pense que le problème vient de là.
Chuis maudit ...

Si kkun a une idée je suis preneur.

@+

EDIT00 :
j'ai essayé d'installer une version plus récente de la logithèque mais j'ai beaucoup de dépendances insatisfaites. Je garde recoll et je ferais sans la logithèque, en même temps depuis ~1 an j'ai tous les outils qu'il me faut.

EDIT01 :
Je peux faire avec synaptic : seule la recherche rapide est ici impactée. J'attends avril, la prochaine LTS ...

Dernière modification par Mobidique (Le 15/11/2011, à 18:09)

ratoune2008 · Le 04/06/2012, à 18:45

Bonjour !
Je me réjouis de voir que Recoll est ainsi largement adopté, quelque temps après mon premier post sur le sujet qui remonte, en fait, à plus d'un an maintenant !

C'est vraiment un outil plus que précieux dont je ne saurais me passer... GRAND merci à son concepteur !

kicekiubuntu · Le 01/08/2012, à 16:41

Bonjour,

Merci pour cet outil qui est efficace et rapide et qui fonctionne automatiquement pour l'indexation de mes fichiers réseaux présents sur /home/.gvfs

Un grand bravo.

mohican · Le 30/08/2012, à 15:54

Bonjour,
j'utilise recoll depuis quelques mois. Je trouve cet outil très efficace. Il comble vraiment un manque.

J'ai un souci de ralentissement avec l'indexation au fil de l'eau - qui d'ailleurs a déjà été signalé ici ou sur le site de recoll me semble-t-il. J'utilise Ubuntu 12.04 64 bits. Recoll à jour (1.17.3) puisqu'installé depuis le ppa.

Symptôme : quelques secondes de latences dans diverses applications (firefox, thunderbird, libreoffice), semble-t-il au moment où l'application fait un accès disque (ce qui fait qu'au départ j'ai pensé à un problème de disque dur). Latences imprévisibles (non systématiques) mais régulières (plusieurs fois par jour).

Ensuite j'ai pensé à recoll et j'ai supprimé l'indexation automatique au fil de l'eau ce qui a fait disparaître les symptômes. Maintenant je suis passé à l'indexation planifiée (une fois par jour à heure fixe, dure 5mn).

Ce pb n'est pas lié aux performances de la machine (Intel Core i7, 4 Go de RAM), l'indexation occupe au maximum 10% de la CPU.

Par ailleurs j'ai aussi installé recoll sur une autre machine (Ubuntu 12.04 32bits) beaucoup moins performante et là il n'y a pas de problème.

Haleth · Le 30/08/2012, à 15:55

Ben ouais, plus la base est grande, plus les temps d'accès sont long
Y'a pas grand chose à faire, si ce n'est supprimé la base (et encore .. j'imagine qu'elle dépend de la quantité de document, et sera donc régénérée intégralement au prochain passage)

mohican · Le 07/09/2012, à 15:47

Autre chose :
dans les préférences d'indexation, onglet paramètres locaux, Global, noms ignorés on trouve
Cache
cache*

néanmoins il semble que le dossier ~/.cache soit quand même indexé. J'ai du donc l'exclure nommément dans onglet paramètres globaux, chemins ignorés.
Une autre solution serait peut-être d'ajouter
.cache
à la liste onglet paramètres locaux, Global, noms ignorés.
A voir et si cela se confirme à ajouter par défaut.

Ou il y a quelque chose qui m'échappe.

medoc · Le 12/09/2012, à 17:29

mohican a écrit :

...
J'ai un souci de ralentissement avec l'indexation au fil de l'eau - qui d'ailleurs a déjà été signalé ici ou sur le site de recoll me semble-t-il. J'utilise Ubuntu 12.04 64 bits. Recoll à jour (1.17.3) puisqu'installé depuis le ppa.
Symptôme : quelques secondes de latences dans diverses applications (firefox, thunderbird, libreoffice), semble-t-il au moment où l'application fait un accès disque (ce qui fait qu'au départ j'ai pensé à un problème de disque dur). Latences imprévisibles (non systématiques) mais régulières (plusieurs fois par jour).
...

Bonjour,

Dans une situation comme celle-ci, il serait intéressant d'essayer de corréler le problème système avec l'activité de l'indexeur, en activant le journal de messages par exemple au niveau 3 dans un premier temps, et en le laissant défiler dans une fenêtre avec tail -f

Vous vous apercevrez peut-être que certains fichiers sont réindexés trop souvent (il y a des paramètres pour éviter cela), ou qu'un très gros fichier devrait être exclus de l'indexation.

Egalement peut-être, un petit coup de top pour vérifier que l'utilisation mémoire reste raisonnable.

Si vous repérez quelque chose, ca m'intéresserait de voir si on peut améliorer la situation: jfd@recoll.org

(et .cache sera dans la liste d'exclusion par défaut pour la prochaine version )
jf

Dernière modification par medoc (Le 12/09/2012, à 17:30)

h2ofranck · Le 30/10/2012, à 19:16

Big merci au(x) concepteur(s) et a ceux qui travaille sur cet excellent indexeur.

J'ai une question: il est possible d'ajouter d'autre base de donnée Xapian (menu de config "index externe").
Est-il possible d'ajouter une base se trouvant sur un serveur distant ? (en SSH de pref, sinon en ftp ?)

medoc · Le 30/10/2012, à 21:53

h2ofranck a écrit :

Big merci au(x) concepteur(s) et a ceux qui travaille sur cet excellent indexeur.
J'ai une question: il est possible d'ajouter d'autre base de donnée Xapian (menu de config "index externe").
Est-il possible d'ajouter une base se trouvant sur un serveur distant ? (en SSH de pref, sinon en ftp ?)

C'est possible à partir de la version 1.18 d'utiliser une base distante xapian comme index principal, en rusant un peu pour la configuration. On utilise la fonction Xapian standard de base distante accédée par ssh. Les performances sont abyssales à cause du grand nombre de requêtes Xapian effectuées par Recoll pour une recherche.

On ne peut pas utiliser une base distante facilement en index additionnel pour une simple raison d'interface (l'interface utilisateur actuelle insiste pour qu'on lui fournisse un répertoire local). Il y aurait probablement moyen de s'en tirer en éditant directement le fichier de configuration.

Par ailleurs si l'"autre base de données Xapian" n'est pas une base Recoll, rien ne marchera, les termes stockés sont largement incompatibles (méthodes différentes pour gérer le "stemming" en particulier).

À condition qu'on parle bien d'une base Recoll, je pense que la meilleure approche serait de monter la machine distante par NFS à travers un tunnel ssh ou autre. Je n'ai pas essayé et je ne sais pas quelles perfs on peut attendre. Mais à travers un NFS "local" ça marche très bien, donc je pense que ça ne dépend que des perfs du réseau.

jf

Christophe C · Le 22/12/2012, à 10:35

Merci à medoc pour ce soft, qui correspond ENFIN à mes besoins !

Je reste surpris que la recherche sous ubuntu soit par défaut aussi pauvre.
- Sous xubuntu, il n'y a rien de rien par défaut (il parait que la prochaine version de xfce embarquera un outil de recherche).
- Sous Unity ou GS, c'est le souk : un outil de recherche texte classique, accessible via nautilus, complet mais lent. Un outil de recherche dans le dash, rapide mais incomplet, puisque zeitgeist n'indexe que les fichiers ouverts (WTF !?). Et ces recherches ne sont mêmes pas accessibles par la même zone !
Idem pour les autres interfaces zeitgeist, comme Synpase.

Recoll comble ce manque. Ma seule réserve : l'interface est un peu chargée, et une interface type synapse (avec l'interface complète seulement en option) serait plus sympa. Mais je pinaille.

Une question, par contre : je n'ai pas compris (man recoll) comment lancer la recherche en terminal (en fait j'aimerais la lancer depuis mes "actions personnalisées" de xfce4-appfinder). Je parle d'une recherche qui lance l'interface graphique de recoll. Il y a quelque chose qui m'échappe dans le man, parce que je n'y arrive pas dans le terminal (je ne suis pas encore à l'étape xfce4-appfinder). Concrètement, je tape quoi, dans le terminal, pour rechercher un fichier toto.txt ?

Dernière modification par Christophe C (Le 22/12/2012, à 10:36)

medoc · Le 22/12/2012, à 10:55

Christophe C a écrit :

[...]
Recoll comble ce manque. Ma seule réserve : l'interface est un peu chargée, et une interface type synapse (avec l'interface complète seulement en option) serait plus sympa. Mais je pinaille.

Pour une interface plus legere, Il y a eventuellement le Lens Recoll (accessible en installant a partir du PPA:
https://launchpad.net/~recoll-backports … l-1.15-on)

Autrement, je le signale comme a chaque occasion, l'interface Python de Recoll, sur laquelle est base le Lens, donne un acces raisonablement complet aux fonctions de recherche. Si un programmeur a des envies d'interface de recherche legere, yaka Quelqu'un est en train de programmer une interface WEB avec.

Christophe C a écrit :

Une question, par contre : je n'ai pas compris (man recoll) comment lancer la recherche en terminal (en fait j'aimerais la lancer depuis mes "actions personnalisées" de xfce4-appfinder). Je parle d'une recherche qui lance l'interface graphique de recoll. Il y a quelque chose qui m'échappe dans le man, parce que je n'y arrive pas dans le terminal (je ne suis pas encore à l'étape xfce4-appfinder). Concrètement, je tape quoi, dans le terminal, pour rechercher un fichier toto.txt ?

recoll -f -q toto.txt

Le -f indique une recherche "nom de fichier", le -q est suivi de la requete.

Pour une recherche texte en mode langage ce serait "recoll -l -q des termes", ce qui est le defaut et peut donc s'abreger "recoll -q des termes"

recoll -h imprime un message d'usage.

Christophe C · Le 22/12/2012, à 12:32

Je testerais la lens, mais je suis sous xfce comme install par défaut. Cela ne me gène pas. Comme indiqué : je pinaille

Ok pour le "recoll -q quelque-chose". Merci, ça marche.

J'en ai profité pour créer une doc ubuntu sur recoll, puisqu'il n'y en avait pas. Il vaux peut-être mieux que tu la relise. http://doc.ubuntu-fr.org/recoll
C'est juste pour ubuntu, donc je ne parle pas des sources, etc...

Merci à toi pour ce travail, c'est vraiment super !!

Dernière modification par Christophe C (Le 22/12/2012, à 12:33)

medoc · Le 22/12/2012, à 16:20

Christophe C a écrit :

Je testerais la lens, mais je suis sous xfce comme install par défaut. Cela ne me gène pas. Comme indiqué : je pinaille

Oui, je n'avais pas bien lu dans les détails. En fait moi aussi je suis en xfce+ubuntu, mais j'ai tout de même tendance à faire comme si Ubuntu => Unity ...

Christophe C a écrit :

Ok pour le "recoll -q quelque-chose". Merci, ça marche.
J'en ai profité pour créer une doc ubuntu sur recoll, puisqu'il n'y en avait pas. Il vaux peut-être mieux que tu la relise. http://doc.ubuntu-fr.org/recoll
C'est juste pour ubuntu, donc je ne parle pas des sources, etc...
Merci à toi pour ce travail, c'est vraiment super !!

Merci beaucoup pour la doc en français, j'en ai écrit beaucoup en anglais, mais j'ai trop la flemme de traduire (surtout que je sais que cela va faire un truc de plus à tenir à jour).

Juste un petit détail: la sensibilité aux accents et majuscules est désactivée par défaut en 1.18, il faut positionner un paramètre dans la config pour l'avoir. Je considère que c'est encore un peu expérimental et il y a encore des petites choses qui marchent moins bien dans ce mode, je ne suis toujours pas totalement convaincu que ca vaille le coup (j'utilise recoll en mode "sensible" mais c'est plus pour tester que parce que je trouve ca vraiment utile...). Donc ce n'est peut-être pas la peine d'en parler dans une doc d'introduction.

Christophe C · Le 22/12/2012, à 16:58

ok, corrigé.

mohican · Le 11/03/2013, à 10:48

Bonjour, il y a quelques jours j'ai eu un phénomène bizarre.

J'étais sous LibreOffice, je venais d'ajouter une formule dans un texte lorsque la fenêtre s'est grisée. Comme elle ne revenais pas je suis allé manger. A mon retour elle était toujours grisée mais en plus j'avais un message système comme quoi ma partition /home était pleine.
Vérification faite c'était les fichiers position.DB et postlist.DB du dossier xapiandb de recoll qui avaient enflé démesurément jusqu'à remplir toute la partition (environ 4 Go - en fonctionnement normal le dossier fait moins de 500 Mo).
J'ai tué LibreOffice et relancé l'indexation dans recoll mais j'ai eu un message "indexation échouée", idem en essayant de reconstruire l'index.
J'ai alors supprimé manuellement le fichier position.DB. Puis j'ai redémarré le PC.

Après quoi j'ai pu faire la reconstruction de l'index dans recoll.
Au passage j'ai découvert l'option de la configuration de l'indexation qui permet d'arrêter l'indexation lorsque le taux de remplissage du disque est de tant de %.

Config : Recoll 1.18.1 - indexation au fil de l'eau, Ubuntu 12.04 32 bits.

Et encore merci pour cet outil très précieux.

medoc · Le 18/03/2013, à 10:04

Bonjour,

(À propos du remplissage de disque).

C'est difficile de dire ce qui a pu se passer sans plus d'informations.

Éventuellement, si cela se reproduit, il pourrait être bon d'activer le journal pour qu'on voie les fichiers que le démon indexait au moment du problème.

Le journal du mode "au fil de l'eau" peut se paramétrer en éditant ~/.recoll/recoll.conf, par exemple:

daemloglevel = 3
daemlogfilename = /tmp/daemrcltrace

Au niveau 3, on devrait voir les fichiers indexés, et le journal ne devrait pas devenir trop vite énorme (il faudra le surveiller un peu quand même si la machine redémarre peu).

Avec le paramètre de limitation d'occupation, le disque ne devrait plus se saturer, mais par contre l'indexation échouera si le niveau est atteint, et un coup d'oeil au journal permettra peut-être de savoir ce qui se passait à ce moment.

jf

mohican · Le 18/03/2013, à 14:19

Merci medoc, j'ai fait la modif du fichier conf.
On verra si cela se reproduit.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 03/10/2011, à 11:59

Re : un excellent indexeur de fichiers: Recoll

#27 Le 03/10/2011, à 12:01

Re : un excellent indexeur de fichiers: Recoll

#28 Le 03/10/2011, à 12:03

Re : un excellent indexeur de fichiers: Recoll

#29 Le 03/10/2011, à 12:57

Re : un excellent indexeur de fichiers: Recoll

#30 Le 03/10/2011, à 13:38

Re : un excellent indexeur de fichiers: Recoll

#31 Le 07/10/2011, à 16:50

Re : un excellent indexeur de fichiers: Recoll

#32 Le 07/10/2011, à 18:42

Re : un excellent indexeur de fichiers: Recoll

#33 Le 09/11/2011, à 14:56

Re : un excellent indexeur de fichiers: Recoll

#34 Le 10/11/2011, à 13:46

Re : un excellent indexeur de fichiers: Recoll

#35 Le 04/06/2012, à 18:45

Re : un excellent indexeur de fichiers: Recoll

#36 Le 01/08/2012, à 16:41

Re : un excellent indexeur de fichiers: Recoll

#37 Le 30/08/2012, à 15:54

Re : un excellent indexeur de fichiers: Recoll

#38 Le 30/08/2012, à 15:55

Re : un excellent indexeur de fichiers: Recoll

#39 Le 07/09/2012, à 15:47

Re : un excellent indexeur de fichiers: Recoll

#40 Le 12/09/2012, à 17:29

Re : un excellent indexeur de fichiers: Recoll

#41 Le 30/10/2012, à 19:16

Re : un excellent indexeur de fichiers: Recoll

#42 Le 30/10/2012, à 21:53

Re : un excellent indexeur de fichiers: Recoll

#43 Le 22/12/2012, à 10:35

Re : un excellent indexeur de fichiers: Recoll

#44 Le 22/12/2012, à 10:55

Re : un excellent indexeur de fichiers: Recoll

#45 Le 22/12/2012, à 12:32

Re : un excellent indexeur de fichiers: Recoll

#46 Le 22/12/2012, à 16:20

Re : un excellent indexeur de fichiers: Recoll

#47 Le 22/12/2012, à 16:58

Re : un excellent indexeur de fichiers: Recoll

#48 Le 11/03/2013, à 10:48

Re : un excellent indexeur de fichiers: Recoll

#49 Le 18/03/2013, à 10:04

Re : un excellent indexeur de fichiers: Recoll

#50 Le 18/03/2013, à 14:19

Re : un excellent indexeur de fichiers: Recoll

Pied de page des forums