You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 27, 2020. It is now read-only.
With a lot of ebooks, the indexing operation at start can take a while. My collection of 6,955 books takes about 8 minutes on my system (notably faster than Calibre). On each start, indexing starts fresh and regenerates the same set of thumbnails for covers.
In other issues, you've indicated that your working on filesystem watching and dynamic indexes. It would be great to incorporate a persistent index along with that other work.
The text was updated successfully, but these errors were encountered:
I agree. I still have not decided on how I would store the info (probably boltdb), and still pick up new changes in books with the same filename. Maybe modtimes?
This would probably take a restructuring of the indexing code, which I won't have the time to do this month.
Modtimes could work. Seems like comparing the filesystem with the index at startup would identify any files changed since the modtime of (or in) the index, and would identify any new files to be indexed (or removed). Only modified or new files would incur unpacking and thumbnail generation.
That's certainly an invasive change, but should help greatly with large libraries.
With a lot of ebooks, the indexing operation at start can take a while. My collection of 6,955 books takes about 8 minutes on my system (notably faster than Calibre). On each start, indexing starts fresh and regenerates the same set of thumbnails for covers.
In other issues, you've indicated that your working on filesystem watching and dynamic indexes. It would be great to incorporate a persistent index along with that other work.
The text was updated successfully, but these errors were encountered: