search for: recollindex

A Recoll user gets the following message while indexing: "Attempted to delete or modify an entry in a non-existent posting list for #bannerholder" The exception happens during a commit call. Xapian version 1.4.11, Debian Buster A little more detail here: https://opensourceprojects.eu/p/recoll1/tickets/108/ I asked if this was reproducible, and to run the indexing in single-thread

Dear all, > I hav installed recoll based on xapian. > when i run recollindex command it throws following error: > > "mh_mail.cpp: 162: decodeBody: base64 decoding failed !" > > Anybody has any idea? > > > > -- > ../tushar

Hi everybody, I'm the author of a small C++11 program called XDGSearch. The source code is hosted on Github, for a quick overview you can visit this link https://github.com/frank67/XDGSearch/blob/master/README.md I'm writing to the mailing list because I'd like to make the database build process splitted in more thread. Is it possible? If you are a C++ programmer you can take a look at

On 14/09/2018 at 09:30, Jean-Francois Dockes wrote: > Hi, > > You may be interested by how Recoll does it: > > https://www.lesbonscomptes.com/recoll/idxthreads/threadingRecoll.html > > A few things in the document are slightly obsolete (esp. the last > paragraph: recollindex now does use vfork()), but it's overall quite close > to how the current indexer works. > > jfd > Thank for your answer, briefly it's No: > The Xapian library index updating code is not designed for multi-threading and must stay protected from multiple accesses. just for...

...ment :) > Thanks in advance for any answer, best regards > > -- > Franco Martelli Hi, You may be interested by how Recoll does it: https://www.lesbonscomptes.com/recoll/idxthreads/threadingRecoll.html A few things in the document are slightly obsolete (esp. the last paragraph: recollindex now does use vfork()), but it's overall quite close to how the current indexer works. jfd

I seem to be seeing cases where I call db.delete_document(somedocid) with no error, then flush() and delete the database object, but the document is still there after process exit. The write lock is normally deleted, so it appears that the database close finished normally. If I then then call delete_document(somedocid) from another command/process, this time it goes away. I've been seeing