Here comes the feature description…
Preferences>Disable “Recreate the search index in the background on start”
Takes 10 min every start up and even between start ups. User should be able to control this. Thanks
Hi!
Thank you for your feedback. I am currently reworking some parts of the indexing so I am curious about your experience.
Indexing between starts (when a fulltext-index was built before), should not take very long. It iterates over linked files and re-indexes files that:
- JabRef did not see before (that were either missing or not-linked when JabRef was last used)
- are newer (file-timestamp) than when JabRef last indexed them (file update)
- unsure, need to check, but maybe also files where JabRef failed to index them the last time (IO-error). If this is the case, it needs to be fixed (also remember the timestamp and if that did not change then don’t bother re-indexing because the file will likely still be not-readable to JabRef).
The second could trigger re-indexing of all files if your file-timestamps are changed for some reason. This could be due to some synchronizing mechanism (maybe Dropbox?) that changes the time-stamp maybe? Are you using any such service or can think of another reason the timestamps may be wrong?
We are aware that (re-) indexing of a lot of files can take a while, but as it is done in the background, why does it bother you? Is JabRef slower for you during the indexing?
I can think of two preferences that we could implement:
- Do not do fulltext-indexing alltogether
- Do not re-index files just because their timestamp changed. I think this could be a sensible simplification, since I cannot think of many use-cases where you would update a linked file. Can you think of any?
One more thing. @Siedlerchr reminded me that we also rebuild the index when JabRef updates it’s search backend Apache Lucene or we change our interface to it. So if you frequently change between versions of JabRef, that could be a reason for frequent index re-builds as well.
Workaround for now:
You can disable indexing altogether and only enable it when it is really needed or desired:
Thanx v much for your detailed feedback. Sorry for the delay.
I have reduced load time of JabRef by disabling Fulltext index > Automatically index all linked files for fulltext search
I have a principal library, but also some files untidily scattered in different paths, including paths that don’t exist. I did some editing of the bib file, which has regularized many bad paths, but not all. This has vastly reduced the warnings in the log file
Now, JabRef loads in 1.5 min, instead of 10 min, at first . This is far more acceptable
Here is how I have configured my system now.
I selected “add time stamp to new entries” Y
“add timestamp to existing entries” N
Linked files > File directory > Main file directory N
Search and store files relative to library file location Y
Autolink files > Autolink files starting with the citation key Y
Autolink only files that match the citation key N
Use regular expression search N
Fulltext index > Automatically index all linked files for fulltext search N
Linked filename conventions > Filename format pattern - [bibtexkey] - [title]
File directory pattern -[Blank]
Name formatter -[all left blank]
Reading and writing annotated pdfs. Annotating a pdf might lead to different timestamps
Ah, so the long wait time comes from files that cannot be found? Interesting. What operating system are you using? Must be an enormous amount of files.
For the re-index on annotations: that is by-design, as annotations are indexed as well.
Thanx for your reply. Actually the indexing seems to be going faster than before. Partly, this is because, by editing the bib file, I have been gradually correcting paths that were outdated due to inheriting from past systems. This has shorted the log file, and speeded the opening of JabRef. Before indexing, wrong paths didn’t slow JabRef opening. Now I need to tidy up my files, which is no bad thing! I also appreciate various improvements to JabRef 5.7, that I find as I’m using it now as I write a new manuscript, using LibreOffice citation tool to manage the bibliography. I’m using LibreOffice v. 6.4.7.2. The jstyle files are very smart. Its very nice to have examples but editing their format is still a bit of a challenge! (Why oh why do journals all have different formats??) Please keep up the good work, and let me know if I can help as a humble “user”. Stuff on my system is: System: Kernel: 5.4.0-110-generic x86_64 bits: 64 compiler: gcc v: 9.4.0 Desktop: Cinnamon 4.8.6 wm: muffin dm: LightDM Distro: Linux Mint 20.1 Ulyssa base: Ubuntu 20.04 focal Machine: Type: Laptop System: Micro-Star product: CR61 2M/CX61 2OC/CX61 2OD v: REV:1.0 serial: Chassis: CR61 2M/CX61 2OC/CX61 2OD type: 10 serial: Mobo: Micro-Star model: MS-16GD v: REV:1.0 serial: BIOS: American Megatrends v: E16GDIMS.20I date: 11/10/2014 CPU: Topology: Dual Core model: Intel Pentium 3560M bits: 64 type: MCP arch: Haswell rev: 3 L2 cache: 2048 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 9578 Speed: 2395 MHz min/max: 800/2400 MHz Core speeds (MHz): 1: 2395 2: 2395
1 Like
For the jstyles format there is a kind of editor, and we have a repo of some example styles:
Editor:
Hi,
Whether I tick the box for "“automatically index all linked files fulltext search” or not, the system seems to spend time and slow or stop JabRef indexing files. It makes me think that maybe that checking the box is not correctly connecting to the backend. How can I disable “automatic index”, please?
Workaround for now:
You can disable indexing altogether and only enable it when it is really needed or desired:
Sorry, in my last reply, I should have said,
"Hi,
Whether I tick the box for ““automatically index all linked files fulltext search” or not, the system seems to spend time and slow or stop JabRef. It makes me think that maybe that checking the box is not correctly connecting to the backend. How can I disable “automatic index”, please?” [I deleted “indexing files”.]
Hi,
I can check again in the next days but I am quite sure the box does what it should.
What version are you running? We recently fixed an issue that may be related.